While it’s true more and more organizations are turning to agile software development for their IT projects, adoption is now hitting the wall. At a recent conference, IBM project management expert Scott Ambler (see story page 6) cited statistics from a survey earlier this year in which 69 per cent of respondents said their IT departments were utilizing agile development practices.
These numbers were exactly the same last year, which has Ambler and many other agile development advocates believing “agile has peaked.”
We hope the other 30 per cent smarten up.
Agile practices basically allow software developers to alter their projects on-the-fly and adapt to changing business requirements. In a non-agile process, business analysts often write up overly prescriptive requirements specs before any piece of code is ever written. These projects almost always go over budget and arrive late.
In the agile process, developers are more responsive and frequently come up with updated plans during production. Ambler said he comes up with project goals every two weeks and looks to have a shippable piece of software done at the end of that time period. By implementing the most important features first, he’s able to keep management happy and finish earlier than usual.
And because Ambler is creating workable software every two weeks, his company can simply continue funding the project until they see something they want to use. He called it “managing IT investments like an investment and not like a gamble.”
But perhaps the best argument we can offer for agile software development is to make a sports analogy. The IT manager should put himself into the shoes of a quarterback. The QB designs a play and moves up to the line prior to snapping the ball. If it was a non-agile QB, they would simply snap the ball and follow the game plan devised months before the game. But, if it was an agile QB, they would most likely look at what the defence is doing, potentially call an audible and change the play.
We think it’s impossible to argue that having a static plan is more effective than a flexible plan. So maybe, that 30 per cent that are still holding out on agile development are not doing so by choice. Maybe it has something to do with their corporate culture. Some employees, especially the business analysts who often write the documentation for new software and other IT projects, will provide resistance to agile methods on the grounds that it will affect their jobs. The best way to tackle this may be to try and convince management to go agile on some smaller projects. Once you get them off the ground, emphasize your successes and how you saved time and money to create an efficient piece of software.
Once the higher ups realize that agile software development will allow them to give rapid feedback and have those suggestions implemented into the production schedule, it will only be a matter of time before all your agile projects receive the green light.
icon.
Perhaps because agile is clearly bad for some things?
