I believe that adopting a scrum approach to project delivery provides the following benefits:
- Higher levels of business buy-in
- Higher levels business involvement
- Clearer alignment of functionality to business value
- Higher levels of adoption
- Better ROI
Now... for clarity, I'd like to point out that I have created business cases before and hope I will continue to do so for agile projects. I've used ROI, with discounted cashflows, NPV and IRR and even the Benefits Management process designed by Cranfield Business School. But... often the traditional delivery approaches do not help the team to maintain a focus on the business case throughout the lifecycle of a project.
Often once the requirements have been stated, the business moves into the "pay and pray" stage, where they hope that in about 6 months time they'll get what they asked for. Agile approaches have in-built processes that ensure a constant focus on business value.
and now I'll tell you how...
Scrum is focussed on delivering increments of shippable software every 30 calendar days. In my experience, the impact on the business stakeholders and user group of seeing quality software delivered every 30 days (one 30-day iteration is called a sprint) is immense... http://www.controlchaos.com/about/
Picture the scene... It's the programme kick-off meeting, the steering group, user group and entire programme team are assembled and you are presenting the project business case, objectives, structure, ways of working and plan. Then you say, "and the first delivery will be in 19 working days."
I was not short of a few sceptical faces that morning...
However, 19 days later, I was in front of the same audience showing the working software. Now we'd only built about 8 pages, but they were of production quality. The functionality enabled the user to search for and view product information and provided on-line help. This functionality was built using .NET technology integrating to an IBM AS-400 mainframe.
The impact of delivering this one "sliver" of production code was astounding. Suddenly the user group could see that we were really building this stuff straight away, and from the end of sprint 1 until live date, we had significant levels of business buy-in and involvement. Far more than I have ever experienced using traditional, waterfall methodologies.
Now scrum also uses a Product Backlog. A product backlog is a list of high level business requirements prioritised purely on a business value basis. So what's so new about that? ... Nothing.
What is new, is that because we are delivering full production code at the end of every sprint, we can measure our expected business return directly against cost far more precisely. AND... at this point assess the outstanding functionality, and either change direction, de-scope because the outstanding functionality has low business value, or continue with the project as it is.
This gives us clearer alignment of functionality to business value. Because of the incremental approach, the closure of requirements every 30 days, and the ability to more granularly relate business value to requirements, the value of the project is transparent to all stakeholders.
At the end of each sprint the sliver of functionality is made available to the business users to review and feedback on. Feedback is classified as an enhancement or bug, but the real value is that the business users are iteratively reviewing and directing the design of the solution as the project progresses. By the time the solution moves into production,
potentially 8 months later, adoption levels are far higher than those of traditional project approaches.
Finally, scrum approaches give you a better return on your investment. Firstly, the teams are more productive see http://blogs.conchango.com/stevegarnett/archive/2004/11/19/297.aspx. But from a business perspective, the incremental completion of the highest priority requirements by the project team, means you will always be maximising your investment, because the team will always be building the stuff the business has prioritised as the greatest value.
In my experience, using scrum has really benefitted the business stakeholders because change is embraced, only valuable functionality is built (and this is picked by the business), and superfluous requirements are not built which reduces waste (Lean software development) http://dotnetjunkies.com/WebLog/darrell.norton/articles/4306.aspx