This blog is part of the Blog Series: A Decade in Agile and was first published in February 2005. My updated reflections are in blue italics.
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.
The assumption in my thinking at this time that I couldn’t see, was that a strong, intelligent, informed and networked Product Owner is directing, prioritising and developing the product backlog. In my earlier scrum projects the product strategies,owners and backlog were very clear and iteration was part of the process
Increasingly, the role of the Product Owner is becoming more demanding and important, I think there are a number of reasons for this:
- Agile teams are getting faster
- Sprints are shorter
- The scaling of teams is more prolific
- Teams are incrementing but not iterating
As teams get faster they create more demand on Product Ownership. More stories are required per sprint, more software is created for review and delivery. Couple this with shorter iterations of just 1 or 2 weeks and the Product Owner necessarily becomes a full-time role just to fulfil the artefacts and cadence of a fast team, regardless of managing product strategy, market analysis or customer analysis and feedback.
If we then add in the scaling of teams then Product Ownership necessarily becomes a team activity with Proxy Product Owners (or similar title) where the ‘delegation’ of business requirements definition and prioritisation is essential and suddenly we find ourselves moving swiftly back to ‘middle-men’ between the customer and the development team.
Of more concern to me is the increasing devaluation of iteration. I think here I ought to define what I mean. In a sprint, the team will take in stories as vertical slices of software to product a potentially shippable product. This slicing of software and delivery of pieces is what I refer to as incremental delivery.
Whereas, iteration for me, is the ability to return to a piece of software and evolve it, change it, adapt it, alter it, based on feedback from the business or customer. My current concern is that many teams are delivering in increments, but are not actively seeking the feedback from the customer/product owner and expecting to iterate upon the increment.
Rather, teams feel that they’ve got to get the increment right first time and are increasingly spending more time upfront to get things ‘right first time’ rather than using the more tangible medium of customer feedback to refine their product.
If this trend continues, teams will lose the benefits of agile working and will increasingly put more pre-sprint activities in place creating longer cycle times to market with less customer validation and poorer product.
and now I'll tell you how...
Scrum is focussed on delivering increments of shippable software every 30 calendar days (typically 2 weeks now). 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)