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:
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)
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.
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?