All About Agile | Agile Development Made Easy!
What's Next?
Now that Agile has been around for more than a decade, I'm curious to know what's next in Agile?
Views: 9
Replies to This Discussion
-
Permalink Reply by Kelly Waters on -
Wow Sowmya, that's a big question! So many people haven't got their head round agile yet, and so many organisations haven't effectively implemented it. Personally I think it's too early to be searching for the next big thing - instead we should really seek to establish agile methods as an alternative to waterfall where it's appropriate. Looking at Google Insights, which tracks search demand, agile project management seems to be the up and coming term, suggesting that whilst the development community has been talking about agile for a long while, the traditional project management community is now taking more of an interest, presumably meaning agile will increasingly be used on larger projects. I suppose Lean is probably the next big thing, but in my mind this is still a (more extreme) flavour of agile - or vice versa depending on how you look at it!
Kelly.
-
Permalink Reply by Sowmya on -
Yes of course, I agree its a big question :) ..
Probably, I could have framed the question as , "what's the latest in agile?"
Neverthless, I've also been googling and asking experts about this. The general emphasis seems to be as you pointed out on Lean methods. One among them is Kanban .. and an emerging one based on this is ScrumBan.. Scrum /XP hybrid is one thing that we follow( am sure that's been around for a while)
Always used to wonder if there were teams which have devised their own unique ways of practising Agile... which could one day become the next big thing.. and hence the question
Sowmya
-
Permalink Reply by Don Wells on -
I think we need to ask what is next in software development. Waterfall was a big thing when I was younger. Agile is a big thing now that I am older.
When I look at the history of software development I see first an attempt to apply the wisdom of other domains. Computer programming was new and we didn’t understand it. That was waterfall and the whole structured programming movement.
We have borrowed plenty from other domains and finally discovered Agile works well with software. This is where we are at now.
I think the next big thing is to accept that software development is unique and should have its own unique body of knowledge. It will take another decade but eventually we will see an emergence of the idea that software development isn’t like building a sky scrapper or even manufacturing Toyotas either. The engineers will be looking at software development and asking how to adapt it to building a bridge.
-
Permalink Reply by Sowmya on
-
Good thought process and wish such a thing happens.
Not sure if you have read article The Agile Method and Other Fairy Tale By David Longstreet.
(URL:http://www.softwaremetrics.com/Agile/Agile%20Method%20and%20Other%2... )
It gives completely different perspective (may be annoying in some places)
Sowmya
-
Permalink Reply by Don Wells on
-
I call that the “always a coach syndrome.” Consultants who come to Agile after being structured development consultants for years don’t get to experience how Agile works from the inside. They are not likely to find themselves writing code on a single Agile project for a couple years to see first hand how it works over the long haul. Instead they find themselves called in to fix problems left behind by other consultants.
At an early Extreme Programming project we had a consultant who refused to do any of the XP practices. My most favorite excuse for not writing unit tests comes from him when he told us his code “tests itself.” He refused to pair program and went over the manager’s head to get it banned from the project. He left the project before he had a chance to learn what XP really was all about. For his very next project he took the job of being an XP coach. I am guessing some clean up was required.
That article was very interesting to me because it is a clear example of why big changes only come every couple decades. The basic idea that Agile is a codification of being sloppy is because that is what he has seen in practice. Anyone who has been on a true Agile project for a large portion of the life cycle knows that it takes plenty of discipline and rules to make it work. There is no room for sloppy on an Agile project. But you only come to know that after you try it. It takes a couple decades to clear out certain ways of thinking before something new can take root.
I do agree to some extent about his statement that programmers create their own trouble. I prefer to say “Challenge your team intellectually or they will challenge themselves in ways you wouldn't have chosen.” (http://www.agile-process.org/proverbs.html) Meaning that you need to watch your team and direct their energy into something useful. That means becoming very involved in the everyday tasks without actually micro-managing. Watching one’s team even when it is running smoothly is counter to many people’s ideas about management.
I worked on a point counter point article with a professor once. She cited a UK project that reported people died because of inadequate requirements documents. The truth was if you read the original report and not just the referencing materials you would find that the requirements were not the problem. The project actually had a good requirements document, but too small a budget. Several software companies turned down the project saying that the budget and spec didn’t match. The one and only company that said they would try were hired. If an Agile approach had been used a working subset of the project would have been delivered instead of a disastrous full version.
“How in the world does a software developer develop software for retirees when they have no knowledge of retirees?” Ask an expert to join the team and talk to you about it everyday. When you find that you are having communication problems the best thing you can do is stop and get everyone to look at what you have so far. If you have a requirements document in some odd language only engineers understand you will not break the communication stand off. If you have a working system that can be test driven and commented on in detail you might get somewhere.
At a company I worked at recently we had a manager who boasted that the programmers knew as much about the business as the business people. What a disaster. We had two types of transactions; invoices and credits. Invoices were used to give loans based on money coming in soon. Credits meant the invoice was wrong and not as valuable as the customer represented it to us. These seem like two very different things to me. But the manager insisted that the two must be “treated the same.” And that meant that credits were just invoices with a negative amount. Well in our system we loaned out money and charged a fee for it based on amount. When a credit came in we did the calculation with a negative sign and gave a portion of our loan fee back to the customer.
Skipping ahead: On the day before we went out of business I finally got a chance to ask the accountant if he had really said “treated the same.” He said absolutely. He wanted credits and invoices to be in one single report not separate reports. They must be “treated the same.” Be careful about programmers thinking they know the business better than the business people they serve.
I am going to stop reading here because I just came to the Yahoo Group Quotes. Anyone who has bothered to read Kent Beck’s book knows that the E is capitalized not the X in Extreme Programming. Quoting someone who obviously doesn’t know that seems like setting up a straw man to me. Enough!
© 2012 Created by Kelly Waters.
