Last week, Ken Schwaber opined in a blog post that Scrum is akin to learning the rules of chess:
Scrum is like chess. You either play it as its rules state, or you don’t. Scrum and chess do not fail or succeed. They are either played, or not. Those who play both games and keep practicing may become very good at playing the games. In the case of chess, they may become Grand Masters. In the case of Scrum, they may become outstanding development organizations, cherished by their customers, loved by their users, and feared by their competitors.
I’ve heard Ken use this metaphor before, most recently when I was at his PSM I course in Boston last Septmber. He argues that intrinsically, Scrum and chess are just frameworks for achieving a desired outcome: One is an intellectual diversion with strict rules of engagement that govern “play”, the other is a process to get complex work done with strict rules of engagement that govern “who does what, when”.
It seems simple, right? Well, clever by half for some of the detractors who had some bitter complaints in the comments (emphasis mine):
(Michael Dubakov) Chess is a complex game, still it has defined rules and there is NO DEPENDENCY ON ENVIRONMENT. In software development, environment is VERY diverse. It means it is hard to create a defined set of rules that should be followed and lead to success.
Are you one of those who believe that defined set of rules can be applied to any situation?
(William Pietri) As far as practical things go, the only things that can’t succeed or fail are religious activities. If a particular surgery doesn’t fix your medical problem, then it has failed. If your favorite prayer or voodoo ritual doesn’t deliver results, well maybe you did it wrong, or maybe the gods just have other plans…
Scrum originates and is almost always applied in a business context, something inextricably bound with material purpose…
As long as Scrum is being sold and bought to accomplish particular ends, I think it should be evaluated like any other practical intervention.
…
If Scrum can be thought of as something that can’t succeed or fail, then that should be equally true of any other software process. That makes questions of which approach one should pursue nonsensical, because they can’t be evaluated on practical grounds. I think that’s a mistake that would destroy a lot of productive dialog… Whatever you… claim, a lot of money is being made by people who raise expectations of what Scrum can do. There are a lot of employees suffering right now when Scrum fails to do what it says on the label.
These comments reveal a problem that the certification industry and associated snake oil salesmen have created for agile software delivery in its ascension to the mainstream. In IT, we’re used to having a lot of IF..THEN structures embedded into our thinking and culture, and this leads some to see things in a very binary way.
Success or Failure in Scrum
As Ken explained way back in Scrum’s early days, the rules of engagement it sets out are deliberately built as a non-prescriptive framework that is checked and balanced to promote the optimization of team performance when working on complex, collaborative projects like software development. They thus increase the probability of success. In and of themselves, the rules of Scrum do not succeed or fail - they just are. Success or failure (which must be objectively defined by the business) is a byproduct of the collaborative work of the entire Scrum Team, including the Scrum Master/Coach, Product Owner and Scrum Team.
What Scrum Says “On the Label”: Continuous Improvement
When we look at the Scrum Guide (freely available as a PDF from Scrum.org here), we read the following:
Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques. The role of Scrum is to surface the relative efficacy of your development practices so that you can improve upon them while providing a framework within which complex products can be developed.
This has been the “promise” of Scrum since Schwaber and Sutherland first promoted it over fifteen years ago: A framework for continually improving and refining a product and a team. It takes what you have on-hand (people, skills, technology, requirements) and gives you the best possible shot at Return On Investment.
However, if we take what William Pietri says in his comments at face value, teams are suffering because of Scrum. Scrum is failing them. But what does this mean?
Failure?
In my experience, “failing” at Scrum usually comes from several places all at once with new teams as they transition away from the chaotic governance of BDUF/waterfall or other high-ceremony/low-trust methodologies:
- Scrum is open. VERY open. There’s nowhere to slack-off or hide; the Scrum Dev Team moves as fast as its slowest members and the Daily Scrum makes this evident. However, it also provides an opportunity to help team members remove obstacles every 24h – this is either welcome or it isn’t.
- Scrum requires some intense participation by the Product Owner to establish what they want to build and to keep a prioritized queue of features. They can throw an entire project into chaos or success depending on their approach (see this Agile Journal article for a real-world example).
- Scrum doesn’t prescribe how to gather feature requirements or attain development best practices – eXtremeProgramming does. It leaves it up to the team how they can achieve the goal of a functional, potentially-shippable product increment every 2–4 weeks. This said, the obvious solutions to the problems a team will face meeting this goal includes writing user stories with good acceptance critieria, estimating with a point scale, using burndown charts to track progress and automated builds and tests to keep the developed system stable over successive iterations. Ultimately, the team should coalesce around what works for them to meet the goals of each Sprint and Release.
- Scrum depends on having a good Scrum Master to provide servant leadership to the Product Owner and Scrum Team. For mission-critical projects, this shouldn’t be a member of the team who wears both hats or someone who just read the Scrum Guide – this must be someone who understands and has applied the fundamentals of Scrum (and indeed agile philosophy, values and principles) and is vested with management authority to ably help the team remove impediments. This can and does include helping the business align their processes to support the Scrum Team. The role requires rigidity to adhere to the basic rules but flexibility to allow the team to find their own solutions to big problems.
Success and Failure Defined by Context
A lot of folks like William and Michael want some objective measure of success, which should be easy in Scrum: It’s the output of each Sprint – working, tested software. If this isn’t the case, Scrum doesn’t prescribe what to do, but it should be readily apparent based on the “success” of the team achieving each Sprint’s goal. This is something I have seen with every team I coach into adoption of Scrum.
Often, the Product Owner will seem discomforted with the reality of what their team is able to achieve, especially in the early iterations of a new team. They will fault everything and everyone else for the failings – it’s a common reaction, because previously they’ve never been so aware of what their team was capable of doing.
However, because the team is given first-order preference in Scrum (vested with the authority to self-organize around their work and determine how to resolve problems themselves) and because they are given the opportunity to continually improve through Scrum’s baked-in two-week delivery windows, they can and do improve over time. They become more and more able to achieve world-class delivery.
In my most recent engagement, I saw this over the four iterations I coached a completely green team: Objectively, they were “failing” to deliver all features as completely tested. They were taking shortcuts and impacting quality. But they knew it. Every Sprint Review.
Part of the problem was organizational, with a lot of delays getting automated testing tools that could have made the QA members of the team more productive and able to support the developers. Part of the problem was with the team learning a new skill and technology. Every Sprint Retrospective we considered what could be done to improve the situation.
By the last Sprint, the team was becoming a more cohesive whole; they attained more fully-tested and delivered work than ever before. They planned, estimated, worked and delivered like professionals. This is success in Scrum.