In the first part of this two-part series, I talked about deploying Scrum to parts of the larger organization without starting in development (“Can you deploy Scrum to a test team?”). This article looks at another kind of “ScrumBut” – the most commonly meant kind: deploying only parts of Scrum to an organization.
Is it half-assed to skip practices in adopting Scrum in your organization?
Lots of sources appear to say that it is.
Ken Schwaber gives a short presentation on ScrumBut in this video (you may have to click the “Download Optimized” button to play this). I’d paraphrase his position as saying that the Scrum practices fit together to create more value than they do individually. So if we punt on one or more of them, he sees potential value being left on the table, and potential organizational weaknesses becoming more entrenched. He sees Scrum as best adopted as a whole without deviation. Consider this excerpt from his book “The Enterprise and Scrum,” about the medium-term issues in Scrum adoption:
“… many people in your enterprise are probably advising you to change Scrum because it needs some tweaking to be compatible with your enterprise. My advice is this: Don’t Do It.”
Later in the same book, he suggests developing an organizational audit function to independently assess the degree of success in adopting Scrum:
“… the ScrumMaster and the team often get so embroiled in their work that they lose perspective on themselves. For this purpose, having an audit capability is useful. Someone who knows Scrum and is from outside the team needs to have a way to measure how well the team is using Scrum.”
That can be viewed as an organizational-wide commitment to avoiding ScrumBut.
This article from Mitch Lacey, “Practicing ScrumBut: Ensuring Project Failure,” captures a workshop delivered at SQE Agile Development Practices 2009. I think the title here says it all in terms of the expected value of ScrumBut.
This article from Michele Sliger covers a particular pattern of ScrumBut that’s near and dear to my heart, failing to meet sprint commitments. The thing I liked most in this article was the notion of “we suck less” Scrum adoptions. Michele is encouraging us to strive for more than “we suck less” – in large measure, saying to at least aim to suck less.
Process change in large, traditionally structured organizations is hard
These authors are stressing the value of Scrum in its entirety, which is difficult to argue with. The question for me is: “What if doing vanilla Scrum is too hard right now?” As I noted in the first article, a big chunk of my career has been spent in larger organizations with very strong functional silos and long histories of plan-driven, waterfall lifecycles. If you look at what you’re really asking an organization like that to do when you ask them to try Scrum, it’s clearly pretty easy for them to say “no.” 
Even on pilot projects, this may be too much to ask for from them – especially so if they’re doing reasonably well with their current processes.
Certainly the value of the practices of Scrum together is greater than their sum individually but does that mean that the value of the practices goes to zero if we don’t deploy them all together? Can the adoption of Scrum be something that is tackled incrementally with an eye towards creating value with each incremental change? If that last question sounds a lot like how Scrum advises us to approach the creation of value on our projects, that’s no mistake. Sometimes, and particularly so in the kinds of large, slow-to-change organizations I’m referring to above, I think it’s sensible to ask Scrum itself to deliver its value incrementally. In scenarios like these, I think it’s important to keep in the forefront of our minds Mike Cohn’s advice in “Succeeding with Agile” about the difficulty associated with viewing Scrum adoption as a traditional change initiative:
“… unlike other change initiatives, with Scrum there is no end state. There is no point when you’re done. Instead, Scrum requires continuous improvement …”
The key thing here from the perspective of assessing the value of a ScrumBut adoption is that it should not at all be viewed as any kind of finish line, but rather a potentially useful step along the path of organizational improvement. If we’re on a path of continuous improvement, do we have to start with a big bang introduction of all of the Scrum practices?
Schedule pressure, estimation and the “Release Train” – a real-life example
I once had a client whose group followed what they called “the Release Train.” In it, they prioritized higher-level features and other work items in a big list and then worked on a few at a time in priority order. They did not use fixed time boxes for this work but rather used a Definition of Done to help them decide when a given work item was complete and another could be started. In sum, a process that resembled a kanban system perhaps more so than it did Scrum. The problem he brought to me was this: stakeholders wanted estimated dates of completion for the items on the release train. He worked with his team to come up with these dates, but they knew that the overall project goals were heavily influencing their estimates. For example, if a project was intended to hit a market window six months out and was to be defined by a handful of key features, the team felt considerable pressure to estimate dates for those features that met the release timelines. We discussed the possibility of trying story points – instead of asking the team to forecast the completion date of each item, ask them to estimate each item’s size using story points and then measure the team’s progress in completing the work (in terms of story points delivered per unit time) to derive estimates of completion for future items on the release train. We agreed that would be an interesting approach to solving the problem they were most concerned with. Now in fairness, we had a pretty wide-ranging discussion over the course of which he talked about other problems they had – among them difficulties in establishing priorities, nailing down what the release train items actually meant, and getting inputs his team needed from other groups in a timely manner. He expressed interest in adopting Scrum “somewhere down the line” but was unwavering in his desire to fix this one problem – improving his team’s ability to estimate release train item completion – as soon as possible.
As a Certified Scrum Coach (CSC), I suppose you could make a case that I should have pushed him harder in the Scrum direction. In private conversations with other CSCs and Certified Scrum Trainers, my approach has been questioned as perhaps overly complacent. In all honesty, I’m not sure. As a coach do I strive to challenge my customers – to push them to want more than they come to me wanting. Or, do I try to solve the problems they actually ask me to solve? For better or worse, I tend to do the latter. I can say that it doesn’t feel complacent per se, but rather doggedly determined to make progress that provides value to my customer as quickly as possible. In the example above, just improving their estimation practices would go a long way to improving their lot. Why not help them do just that?
A view from the perspective of another process improvement approach – the CMMI
Much of this discussion puts me in mind of the CMMI and the difference between maturity levels and capability levels.
The CMMI defines a staged approach to organizational process improvement – very comprehensive about the order in which different aspects of the overall processes (“process areas”) has to be done. For example, achieving maturity level two implies improvements in the following process areas: requirements management, project planning, project monitoring and control, measurement and analysis, configuration management and process and product quality assurance (also supplier agreement management, if that makes sense in the organization). The remaining maturity levels, three through five, are defined in a similar manner. That prescription of a process improvement path frankly seems like the kind of approach calling for all of Scrum to be deployed in one go.
But the CMMI defines another approach (technically another representation) – the continuous representation, which leaves the ordering of improvement to process areas to the organization to decide, while still offering some guidance on how to go about it (the specific and generic goals and practices). That guidance is supported by the notion of the capability levels, which define a path for improvement for the individual process areas. In the continuous representation, an organization would be free, for example, to focus first on improving how they approach project planning practices – estimation perhaps – if they believed that was going to offer them the greatest value.
Suddenly, insisting on deploying all of Scrum right away starts to feel perhaps a bit too prescriptive.
So is it half-assed to deploy part of Scrum to your organization?
Scrum is one useful assemblage of Agile practices. XP is another. There are others. So it’s not unreasonable to think an organization could skillfully define their own set of Agile practices or an incremental path through adoption of the complete set of Scrum practices that would provide decent value, tailored to their organization’s needs over time. At the end of the day, if you held a gun to my head and made me winnow down Scrum to the absolute minimum I’d really not be willing to part with in any initial adoption, it would amount to just these two practices:
- Iterate: define a window of time in which the team commits to delivering some potentially shippable increment of working software
- Reflect: gather the team together at the end of each iteration just prior to planning the next iteration and ask them how they can improve
Mind you, if you do just those two for a while, you’re likely to end up inventing many of the other common Agile practices :)
But if you started even at that modest point, would you be pursuing a half-assed deployment of Scrum? Maybe so. But maybe a half-assed deployment of Scrum is like “half an eye” that provides value all by itself but also represents a step along the path to something amazing.
So can you deploy part of Scrum to an organization?
Sure, why not?
What do you think?
I’d like to thank Selaine Henriksen for her help in developing this post.
About the Author: Ed Willis has been a ScrumMaster, Product Owner, Scrum coach and trainer. He is currently a developer in the telecommunications industry.
RallyDev.com
Ryan Martens is CTO/Founder of Rally Software, a recovering Entrepreneur-in-Residence at the Unreasonable Institute and chief promoter of the Entrepreneurs Foundation of Colorado. You can follow him on Twitter @RallyOn. 
The customer validation step for Project Stratus is going full steam. We welcome more earlyvangelists to partner with us in this exciting endeavor. The more input we receive, the more valuable the product will be. If you have strategic planning challenges and a passion for applying agile principles for solving them, I invite you to reach out to us at 
This post will be split into two parts so that it, itself, will be half-assed with the suggestion of an additional half-ass to be delivered later :) And, in keeping with that spirit, the post mistakenly went live before it was ready for prime time. This time, I meant to push the ‘publish’ button…
One of my favorite lines – frequently quoted in optimization discussions but applicable equally well here – comes from Voltaire: “Le mieux est l’ennemi du bien” (the best is the enemy of the good). “Best” is hard to define in any complex system like a large company but “good” seems a little more tractable. We should not let an inability to approach some notion of perfection prevent us from getting better.
Larman and Vodde have some great advice about how to go about ever more closely approaching the “potentially shippable product increment” goal of the Sprint through expanding the Definition of Done (DoD below):
I’ll split this post into two pieces so that it, itself, will be half-assed with the suggestion of an additional half-ass to be delivered later 
One of my favorite lines – frequently quoted in optimization discussions but applicable equally well here – comes from Voltaire:
Larman and Vodde have some great advice about how to go about ever more closely approaching the “potentially shippable product increment” goal of the Sprint through expanding the Definition of Done (DoD below):
That latter idea suggests a path to improvement that starts in development and then spreads over time to the other functions.
