Dave West is the Product Owner at Scrum.org. He is a frequent keynote speaker and is a widely published author of articles, along with his acclaimed book: Head First Object-Oriented Analysis and Design. He led the development of the Rational Unified Process (RUP) and then worked with Ivar Jacobson running the North American business for Ivar Jacobson International. He managed the software delivery practice at Forrester Research where he was vice-president and research director. Prior to joining Scrum.org, he was chief product officer at Tasktop, where he was responsible for product management, engineering, and architecture.
October 18, 1995, Ken Schwaber presented at the Object-Oriented Programming, Systems, Languages & Applications (OOPSLA)1 conference an approach to delivering software called Scrum. That paper laid the foundation for a movement that has fundamentally changed how software is delivered around the world. If you assume there are 18 million2 people involved in software delivery, and that 90% of those teams3 are doing some form of Agile, with Scrum accounting for 70%4 of those that means over 11 million people are doing Scrum, at least in some part. Even ifyou consider those numbers too aggressive, Scrum has become the de-facto standard way that teams are organized and delivering software. Can we tick off Scrum as a success?
For many the promise of Scrum has not been realized
If you ask Ken Schwaber the co-creator of Scrum you will get an interesting perspective. “Scrum has been more successful than I could have ever imagined, but I am still disappointed with most Scrum implementations.’’
This disconnect between the success of adoption with how it is being adopted was described in my keynote jointly presented with Ken at Scrum Day London5. In this keynote we described issues with Scrum implementations:
- Project failure / challenged rates continue to hover
Even though Agile projects continue to be 3 times more likely to be successful compared to waterfall project success, true improvement still seems to be an allusive thing. At the heart of Scrum is the idea that professional software developers would focus, by applying an empirical approach on the things that are important to building a different sort of relationship with customers and stakeholder which in turn would create more project/product/software success.
- Done software is not really done software.
As proven with Continuous Delivery and DevOps movements, for the majority of organizations software is not ‘done’ within a sprint and requires other actions to occur to move it into production. In fact, software developers have more definitions for the word done than Eskimos have words for snow. Scrum and Agile are all about delivering working software frequently to customers to provide feedback and when Scrum says working it means as close to production as possible. Ideally in production providing feedback to the team.
- Water-Scrum-Fall is still a reality.
As an analyst I coined the term Water-Scrum-Fall6 when describing the reality of Agile adoptions in the majority of large IT shops, and this trend continues. In fact, approaches like Scaled Agile Framework (SAFe), though I am not encouraging it, support it. Scrum is sidelined to small teams and thus those businesses do not get to realize the benefits of business agility.
- Everyone says they are doing Scrum.
But the lack of consistency and shared values creates confusion and reduces value. As Scrum has become more popular more and more people are practicing it. That is a good thing, as long as they really are practicing it. Scrum is a light weight framework which provides flexibility, but though light, it is possible to do things that are ‘not-scrum’. The Scrum Guide provides a definitive, agreed to description of what Scrum is, but many people have not read it, and do not practice it. Consultants have added lots of good things to the way that they apply Scrum, but that in turn has added complexity and led to confusion. It is, therefore, almost impossible to make sure the people ‘off the street’ who say they know Scrum actually have a consistent view of Scrum.
Looking at these 4 challenges over the next 20 years, the community needs to focus on improved adoption through measurement, help organizations get to Done faster, look to scale Scrum without falling back into waterfall and improve consistent knowledge of what Scrum is.
Measurement needs to focus on value, not velocity
Burn-down charts and velocity are great tools for driving improved work rate and better estimation and planning, but do not provide the right focus for product success and business adoption. Evidence Based Measurement (EBM) is a set of ideas developed by Ken Schwaber that encourages organizations to focus on delivering ‘value’. EBM concentrates on three dimensions, current value, time to market and ability to innovate. By considering value, not only does this change the relationship between the Scrum Teams, their Product Owner and stakeholders, but also encourages a change to backlog items, prioritization, reporting and even Sprint Reviews.
Done is really done, not almost done
For the last 21 years the phrase ‘‘potentially shippable’’ has allowed practitioners to decide what potentially means to them. The original meaning of the word was to allow the Product Owner to decide if the software should be shipped, not to put flexibility into the definition of done and allowing un-shippable software to be part of the increment. Add to the confusion about the increment and the Sprint Review being mistaken for a phase gate7 and software is not being shipped from a Scrum Team in a regular fashion.
Continuous Delivery and DevOps are both movements that are encouraging teams to integrate release and operations capabilities into Scrum Teams and deliver software more frequently. These movements are not different to Scrum, but their associated practices need to be married into how you implement Scrum, surrounding the core Empirical process of Scrum with modern engineering practices.
Scaling product delivery with Scrum
There are two dimensions to scaling Agility. Breadth, adding more Agile teams and Depth, adding upstream and downstream groups to your Agile initiative. Scrum has been successful in changing the way teams operate, bringing Agile to teams, and has done it in an incremental manner. The next logical step to scaling is to take that success and support to teams of teams delivering a product. Nexus8, an exoskeleton to Scrum, provides additions to the Scrum framework that enable multiple Scrum teams to work effectively together.
Professionalism, values and, consistent Scrum
There will always be a tension between building the right process for you and your team with putting in place consistent and standard approaches to delivering software across the whole enterprise. Scrum encourages teams to optimize locally, but that does not mean teams need to use inconsistent terminology and approaches just for the sake of being different. The Scrum community provides a clear definition of what Scrum is in The Scrum Guide9. This body of knowledge should be used as the foundation for teams using Scrum and should remove any ambiguity of what is or isn’t Scrum. The Scrum Guide also includes the 5 Scrum Values of Focus, Commitment, Openness, Respect and Courage. These values re-enforce the social system that supports Scrum and should be front and center to any team using it.
Professional software delivery will always be empirical
The popularity of Scrum has also led many people to questioning its validity for modern projects. After all, modern implies a different approach to delivering software—right? But at the heart of Scrum is the idea that process needs to be empirical. This empirical process is applied by inspection and adaption through transparency. These concepts sit above technology or practice and form the basis for professional software delivery.