Getty Images/iStockphoto
Why you must avoid ScrumBut at all costs
How do Scrum and ScrumBut compare? Darcy DeClute explains why ScrumBut is bad, and how you can avoid this Agile anti-pattern and stay true to Scrum's core principles.
Some think Scrum is the most popular Agile methodology in use today. Those people and organizations are wrong.
While Scrum is indeed popular, in practice, far more organizations use a derivation of Scrum known as "ScrumBut."
What is ScrumBut? It's the partial adherence to a Scrum practice or principle, with a reason or a justification to avoid an essential element of it. This ScrumBut justification is often supplemented with a workaround.
ScrumBut examples
As all Scrum practitioners know, the daily stand-up is an essential part of the Scrum methodology.
With ScrumBut, practitioners say: "We do Scrum, but we don't do daily stand ups."
Other common examples of ScrumBut include:
- We do Scrum, but we don't do retrospectives at the end of each Agile sprint. Instead, we do them at the end of the project.
- We do Scrum, but we don't assign story points. We don't like the competitive conflict that story points create.
- We do Scrum, but short sprints don't work for us because we don't like the fast pace, so we extend them to seven or eight weeks.
- We do Scrum, but we invite managers to participate in the daily stand-up because we are over budget and the stakeholders want more oversight.
- We do Scrum, but we don't do product backlog refinements or grooming because we create very detailed user stories at the start.
- We do Scrum, but we invest in a lot of upfront planning, because our stakeholders are more comfortable with a waterfall model.
- We do Scrum, but we allow stakeholders to define the definition of done after a sprint is complete so they are happy with the quality of the product.
The problem with ScrumBut
The biggest problem with ScrumBut is self-evident -- if you're doing ScrumBut, you're not doing Scrum. If you've failed on something as fundamental as your chosen development methodology, how can you be confident that the greater project will be a success?
The official Scrum guide states that Scrum's framework, including roles, events, artifacts and rules, is immutable: "While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety."
When a development teams picks and chooses which parts of Scrum they like and which parts they dislike, they've gone rogue. The result is not Scrum, and it is no longer certain that they will realize the proven benefits of Scrum. That's a risk development teams should be unwilling to take.
Furthermore, if your team or organization is committed to Scrum, but in reality you're doing ScrumBut, you are fundamentally lying to yourselves. If you can't be truthful with yourself about the basics of the methodology you use, how can you be trusted to estimate timelines or communicate honestly and openly throughout the project? A home is only as strong as its foundation.
The three pillars of Scrum
The three pillars of Scrum are: transparency, inspection and adaptation.
Activities outlined in the Scrum guide ensure visibility, both to developers and to the project stakeholders. This transparency enables teams to regularly inspect progress, recognize when progress stagnates, and adapt as needed.
Required activities such as short sprints, retrospectives and daily stand-ups reinforce the three pillars of Scrum. Skip out on these activities and you've failed to properly implement your chosen methodology – and you've introduced risk that your project will be successful.
How to avoid ScrumBut
Every ScrumBut objection to Scrum comes with an excuse or justification.
Teams say they don't do daily stand-ups because there isn't enough time, or they don't do retrospectives because they don't see the value in it. These objections often reveal ignorance of the Agile process, or a lack of confidence in Scrum-based methods.
To address the ignorance issue, ensure your team members actually read the Scrum Guide -- it's amazing how many Scrum practitioners have never read it; it's only 14 pages long! Reading the Scrum guide helps to create awareness of the process and an understanding of why the Scrum artifacts are an essential part of the process.
When ScrumBut involves implementation issues, the Scrum Master must take the lead. The eight stances of a Scrum Master include duties as facilitator, coach, teacher and change agent. While acting in these roles, the Scrum Master must resist all ScrumBut objections and enforce the rules of the methodology -- and most importantly, map the Scrum-based activities back to the benefits they provide.
If developers have turned to ScrumBut because they lack faith in the process, it's the Scrum Master's job to educate the participants in the methodology's value.
Scrum is a proven methodology to complete software projects on time and on budget -- but it is immutable. ScrumBut is not Scrum. An organization must fully commit to Scrum to fulfill its promised benefits. Any fundamental compromise to the methodology will lead to missed timelines, blown budgets and dissatisfied stakeholders. ScrumBut will lead you into another failed Agile project.
Avoid ScrumBut at all costs. Your organization deserves better.
