Rants
Questions
Soapbox
Best Practices
Apply today for a FREE subscription to CIO Magazine!
Wed, Aug 26, 2009 2:31 EDT

|
Posted by: Michael Hugos in Soapbox Topic: Enterprise ManagementBlog: Doing Business in Real Time
Current Rating: |
Agile has come of age in the IT world. It has moved past the fad phase; it has created and field tested a well defined set of practices and techniques. Agile is out of beta; it’s in production. Although the numbers of agile IT practitioners still only comprise a small percentage of the total IT workforce, the adoption rate is growing and the trend is obvious. Agile practices will define the future of the IT profession.
And there is more going on here than just the future of the IT profession. Much more. Agile is starting to blend into the business world. Just as agile practices and approaches define the future of IT, agile practices and approaches also define the future of business. For the last 20 years we’ve all known the traditional hierarchical organization and its slow moving bureaucratic operating processes were no longer a successful way to structure and operate a business. But we didn’t know what would replace it. Now we do. Look at how IT groups are reorganizing themselves in the companies where those groups have adopted agile practices. Then extend that new organization model into the rest of the company. That’s the new structure for successful companies in this century.
As I talk to people and attend the sessions and learn more about the services and products provided by the vendor sponsors of the Agile 2009 Conference, I see signs that we are reaching a tipping point. Twenty four months from now the things I say here will seem quaint (and obvious). Let me describe a few of the signs I’ve seen today that lead me to the conclusion we will soon reach a tipping point.
Evidence that We are fast Approaching an Agile Tipping Point
I attended a session titled “Covert Agile: Development at the Speed of… Government” by David Morgan and David described how he and a group of IT contractors employed agile practices to deliver a Department of Defense system in half the time taken by two earlier failed attempts to build the system. They used the agile approach because it offered the best chance of success even though official regulations of the DoD dictate that all contractors must use a traditional waterfall process. They just created the required waterfall documentation deliverables at appropriate points in their agile process and delivered them as required by DoD regulations. They were agile because they had to be; they did not ask permission; they just did it. Other people in other organizations will start to do the same thing because they see that agile practices offer them the best chance for success. They won’t ask for permission; traditional procedures can still remain in place; but agile will happen anyway.
Next I attended a session by Mary Poppendieck titled “Deliberate Practice in Software Development”. She recited research from several fields that indicates it takes about 10 years and about 10,000 hours of deliberate practice to become an expert in a chosen field. In the next 24 months a significant number of agile practitioners will reach their 10 year and 10,000 hour mark and will become experts in agile practices. They will spread far and wide training others as they go, and their effect on IT and business practices will be enormous.
In the afternoon I talked with several of the vendor sponsors of the conference. I met with Laszlo Szalvay, president of a company called Danube Technologies that was founded in 2000 and is now the largest provider of agility training and project management software focused specifically on the use of Scrum. Scrum is the most
We have been saying pretty much the same thing about Extended Agile for a while. We've seen the results of extending agile principles throughout an organization pay off. It's not just a noble goal, it is a pragmatic win!
Thanks for a great article!
The one problem with agile that I've seen so far is a lack of specification documentation.
Why is 'a lack of specification documentation' a problem? Detailed specification documents assume that one knows what the outcome will look like before you start and also limits the input of the project team. Not having a detailed specification up front introduces flexibility, not only in design and implementation but also in meeting consumers' ever changing needs. Agile allows for specification document but in a 'just enough, just in time' basis.
Using Agile principles we've got to market quicker (and beaten our rivals to the punch), improved the cash flow (and who can't afford to do that these days), increased the business' ability to change its mind cheaply (which they love) and markedly improved the teams morale.
I don't think I could go back to a waterfall approach to software development.
The one problem with agile that I've seen so far is a lack of specification documentation.
I'm not buying it. Still a fad. Still a short cut for people that don't want to write requirements. Has no fit with large organizations due to lack of predictability and consistency.
If "rising" means more consultants are getting rich off of endorsing it, I can see that. But if rising means becoming a practical approach to software development for large organizations, not so much.