10 Good Reasons To Do Agile Development
by Kelly Waters
Here are 10 good reasons to apply agile development principles and practices...1. Revenue
The iterative nature of agile development means features are delivered incrementally, enabling some benefits to be realised early as the product continues to develop.
2. Speed-to-market
Research suggests about 80% of all market leaders were first to market. As well as the higher revenue from incremental delivery, agile development philosophy also supports the notion of early and regular releases, and 'perpetual beta'.
3. Quality
A key principle of agile development is that testing is integrated throughout the lifecycle, enabling regular inspection of the working product as it develops. This allows the product owner to make adjustments if necessary and gives the product team early sight of any quality issues.
4. Visibility
Agile development principles encourage active 'user' involvement throughout the product's development and a very cooperative collaborative approach. This provides excellent visibility for key stakeholders, both of the project's progress and of the product itself, which in turn helps to ensure that expectations are effectively managed.
5. Risk Management
Small incremental releases made visible to the product owner and product team through its development help to identify any issues early and make it easier to respond to change. The clear visibility in agile development helps to ensure that any necessary decisions can be taken at the earliest possible opportunity, while there's still time to make a material difference to the outcome.
6. Flexibility / Agility
In traditional development projects, we write a big spec up-front and then tell business owners how expensive it is to change anything, particularly as the project goes on. In fear of scope creep and a never-ending project, we resist changes and put people through a change control committee to keep them to the essential minimum. Agile development principles are different. In agile development, change is accepted. In fact, it's expected. Because the one thing that's certain in life is change. Instead the timescale is fixed and requirements emerge and evolve as the product is developed. Of course for this to work, it's imperative to have an actively involved stakeholder who understands this concept and makes the necessary trade-off decisions, trading existing scope for new.
7. Cost Control
The above approach of fixed timescales and evolving requirements enables a fixed budget. The scope of the product and its features are variable, rather than the cost.
8. Business Engagement/Customer Satisfaction
The active involvement of a user representative and/or product owner, the high visibility of the product and progress, and the flexibility to change when change is needed, create much better business engagement and customer satisfaction. This is an important benefit that can create much more positive and enduring working relationships.
9. Right Product
Above all other points, the ability for agile development requirements to emerge and evolve, and the ability to embrace change (with the appropriate trade-offs), the team build the right product. It's all too common in more traditional projects to deliver a "successful" project in IT terms and find that the product is not what was expected, needed or hoped for. In agile development, the emphasis is absolutely on building the right product.
10. More Enjoyable!
The active involvement, cooperation and collaboration make agile development teams a much more enjoyable place for most people. Instead of big specs, we discuss requirements in workshops. Instead of lengthy status reports, we collaborate around a task-board discussing progress. Instead of long project plans and change management committees, we discuss what's right for the product and project and the team is empowered to make decisions. In my experience this makes it a much more rewarding approach for everyone. In turn this helps to create highly motivated, high performance teams that are highly cooperative.
Implications of embracing agile development principles
But there are implications. There's no such thing as a free lunch! And there's no magic bullet for software development. Sorry, no, you can't just drink the cool aid :-) In exchange for all these benefits, you do get less predictability, software and humans are still difficult, you can't blame someone else if things don't go right, and it generally requires much more commitment and effort from everyone involved - i.e. teamwork is even more important.
Nevertheless, the advantages of agile development are really compelling.
11 June 2007 21:10
'Agile' is a hoax. Don't believe what you read here!
11 June 2007 22:07
I wouldn't say it is a Hoax but in most cases it requires a level of sophistication, dedication and experience that doesn't exist in most development teams.
12 June 2007 07:53
I agree with Steven apart from the sophistication – let’s face it software engineering is not the simplest of disciplines (it’s easy once you know how). It just takes a change in mind-set and after a while the rewards are quite pleasurable
refer to my blog article regarding
Derek
13 June 2007 02:30
Agile is not a hoax. Speaking from experience, I'll take agile over waterfall 80's style development any day of the week, and I'll take low tech iterative development over model driven, heavy tool dependent, PMO driven projects as well.
13 June 2007 12:14
For projects that are technically very challenging agile development does not offer an advantage compared to a big-design-up-front.
I don't take the risk management argument. If you have a lot of technical requirements than it's too easy to ignore or not understand some important ones.
You may think you're managing risks but you're unaware of missing links.
17 June 2007 20:19
Agile isn't a hoax, neither is it a cure-all. It is a very good 'method' to follow as long as you have a team of experienced programmers and a good technical lead. Less experience can cause problems later in the cycle.
Point 2 can be a worry however. Some people read far too much into this potential benefit leading non-technical managers to push software into release before it is ready. This often leads to users receiving a poor quality product that turns them off before they have realised the potential.
19 June 2007 12:44
I think that with Agile is all about attitude.
23 June 2007 01:32
Agile Development works! We've been using it in our organization for two years. Amazing results, very happy customers!
30 June 2007 13:44
Generally Agile environments are are implemented correctly, and the most common error is to put too much responsibility on development. However skilled a developer, their mindset is not geared to usability, or indeed anything user-focussed beyond functionality. This can increase general resentment from development, as they are expected to include the client in development process. Which is why most Agile slatings on blogs are commonly from developers.
The answer to effective software development, regardless of methodologies, is decent project management, always. Coders are ten-a-penny these days, but good project managers are gold dust. A very provocative statement, but truth hurts. Coders need to wake up to fact they need more than just coding skils, they need business and people skills too - sadly lacking in projects in my recent experience.
17 July 2007 14:46
Coders might be ten-a-penny but good developers are not. Decent project management, might as Paul Littlebury says, be the key.
Most if not all project that went wrong during my 18 year as a professional developer were due to incompetent project management. Managers that have have no experience of development (or more often that wrote a program or two at the university and therefore think they are more than qualified to lead a team). Worst of all I think is project managers that think the work method means nothing it is they that perform the great work since they are so damn good leaders.
On the other hand most projects that were successful were that in my opinion because the developers were highly skilled and motivated combined with a project management that knew that they know jack shit about development and thus let the coding decisions: methodology etc. to the actual developer teams.
PS I wonder if/when companies will realize that manager positions today are mostly administrative and require a lot less skill and intelligence their workers (coders here) and thus pay them less so that the Dilbert Pinciple will not be the main rule.
29 February 2008 02:05
Hi Kelly,
I would like to republish some of your material on PM Hut. Please contact me through the "Contact Us" form on PM Hut's site in case you're interested.
27 June 2008 18:13
i can't stand projects that adopt the trappings of Agile (twice-daily standups, etc) but are actually build-to-spec. I'm on a project now that calls every phase an "iteration" even though it's just a section of th e project that's supposed to be 100% and never revisited.
5 October 2008 09:23
Thanks for the article...
It helped me in understanding agile....
29 January 2009 19:48
Agile only fails when you refuse to become agile and start putting "management-based" decisions as the driving factor. If its not negotiable its not agile.
17 February 2009 09:29
Awesome article.....Thanx
24 September 2009 10:23
Agile is good where you have well deciplined, motivated, well balanced team is present as author said. Agile will not workout where you have 'greedy' client and unbalanced team.
7 December 2010 17:14
Having worked in multiple methods and having seen the worst of many I'd give this article a C-. The only one of the 10 reasons that stick would be the "Enjoyable" one, and that's probably the catalyst for most to fall in love with Agile.
The others are a total wash. Honest. If you've got the right resources, the right management and the right stakeholder involvement, most project management methods can work; of course some will fit certain circumstances better than others. If you don't have that mix, any method will fail you.
8 December 2010 10:11
Seems agile has taken utmost care to handle all the changes except the dynamic teams.
Team, which is the core for Agile methodology is not equipped well for change in the team.