Do Scrum, Not Scrumbut

In my experience, there are two different types of Scrum implementations: full Scrum, and what Ken Schwaber and Jeff Sutherland and others have called ‘Scrumbut’. The former makes full use of the Scrum framework, and the latter is what you see when a team adopts only pieces of the framework, as in “We are using Scrum, BUT we don’t really don’t do sprint reviews or retrospectives.” Or, “We use Scrum but we do all of our testing in the next sprint.” If you are not using the whole Scrum Framework, you may be employing an Agile, iterative process, but you are not really doing Scrum. Scrum is at it’s most potent and effective when you actually use all the elements of the framework, which were designed to address the core Scrum pillars of transparency, inspection, and adaptation. Half-stepping on your Scrum implementation can throttle the value and return on investment teams and companies will get out of using Scrum in the mildest case, and actually be dangerous in the worst. The danger exists that done poorly, your development process will churn more and cost more, quality will suffer, and people will burn out. Additionally, the implementation will be at risk of failing to achieve the success people expect, and they may not recognize that Scrumbut is to blame but may instead conclude that Scrum doesn’t work – leading to potential failure of the implementation.

Scrum is lightweight, easy to learn, but difficult to do really well. Teams have to commit to practicing it to do it well, understand that continuous improvement is a journey that never ends, and work thoughtfully towards mastery.

So how can you tell if you are doing Scrum or Scrumbut?

First, you need to have a robust understanding of the elements of the Scrum framework and how they are used. In a nutshell, Scrum is made up of roles, events, artifacts, and the rules that bind them together. Your process should include all of these to be considered a solid Scrum implementation:

Roles

Product Owner – owns product backlog, provides direction on ‘what’ should be built, constantly considers value to the customer

ScrumMaster – owns the Scrum process, coaching the team how to make the most and best use of it

Development Team – owns ‘how’ to accomplish the sprint goals, cross-functional team enabled to self-organize on developing the product. Note that in Scrum, the term ‘Development Team’ includes every role whether coder, tester, technical writer, UX expert etc)

Events

Sprint – container which holds all other events, between 1 and 4 weeks long

Sprint Planning – timeboxed session with the entire Scrum Team during which backlog items are discussed and understood, and a plan for the sprint is created on how to deliver working increment of product. The team is given a sprint goal, which could be a milestone along the product roadmap, and decides how to accomplish that goal. This could involve breaking backlog items down into smaller chunks called tasks

Daily Standup – 15 minute timeboxed daily session during which the team plans the day, synchronizes their work, and updates each other; this preferably takes place in front of the team’s task board and in person. This meeting is for the team, not management, and answers the questions 1) What I did since last time 2) What I plan to do before next time 3) What’s in my way

Sprint Review – the team reviews what they completed vs what they forecast and demonstrates completed work for final acceptance by the product owner and for feedback from stakeholders

Sprint Retrospective – the team inspects themselves and how they worked together during the last sprint, creating an ordered list of what went well and what needs to be improved. Items to be improved are included in the next sprint planning or added to an improvement backlog.

Artifacts

Product Backlog – an ordered list of features or items to be worked on along the product vision and/or roadmap.

Sprint Backlog – the set of backlog items to be worked on during a sprint plus the plan on how to complete them.

Backlog Item – a single item to be worked on. Many teams use User Stories as their backlog items (borrowed from XP).

Definition of Done – this is a team defined list of everything that must be in place for a backlog item to be considered done. This might include code checked in to source control, functional and performance testing complete, documentation written or updated, acceptance criteria met, etc and will depend on what the team needs to deliver a potentially shippable increment.

Understanding all of these roles, events, and artifacts is important, and more details about the basics can be found in the Scrum Guide.  The other thing that can help you identify whether you have a real, robust Scrum implementation is to consider some examples and causes of the Scrumbut anti-patterns so that you can learn to recognize them on your team or within your organization. Scrum.org has a list of potential causes here. Additionally, here are some examples I have seen:

• no real Product Owner or ScrumMaster, or the roles are filled by the same person
• team doesn’t really do daily standups
• team doesn’t conduct a review or demonstrate working software to stakeholders at the end of the sprint
• team doesn’t retrospect on how the sprint went or how to improve their use of Scrum, the product, or how to work better as a team
• no real product backlog or understanding of the priority or business value to be delivered
• team (sometimes or always) does not deliver working software at the end of the sprint

So, are you doing Scrum, or Scrumbut?

Updates to the Scrum Guide

Ken Schwaber and Jeff Sutherland have posted an update to the Scrum Guide this year. Here is a link to the summary of the changes. In case you prefer, here is a summary of the changes:

1. The team doing the work is now called the ‘Development Team‘, and all members of the team are called Developers whether their expertise is in programming, testing, UX design, technical writing, etc. This is to emphasize that the team works together to ‘develop’ the software.
2. The team no longer ‘commits‘ to accomplishing the sprint goals, they ‘forecast‘ what they will complete and the expectation is that the plan will adapt as they learn more. The main reason for this is at times stakeholders have engaged in committment bashing, penalizing the team for breaking commitments even when the circumstances were beyond the team’s control. This is an acknowledgement that it’s nearly impossible to predict a 100% accurate plan until the team has enough information – which is usually when they are doing the actual work. We can, however, forecast accurately enough to make a plan with flexibility baked in.
3. Scrum doesn’t require use of a burndown chart specifically, only that the amount of work remaining in a sprint is summed and known daily, and trending towards completion is maintained throughout the sprint.
4. Release planning is valuable but isn’t required; it depends on your circumstances.
5. The Sprint Backlog is the Product Backlog items selected for the sprint plus the plan for delivering those. Here is a diagram from scrum.org which illustrates what is considered the sprint backlog:

6. The product backlog is now ‘ordered‘ instead of ‘prioritized‘; this is to emphasize that there are many factors that go into the order of the backlog including ROI but also logical order, dependencies, gaining knowledge, and other factors unique to the situation.

Edit: Here is a link to the Scrum Guide