Do you really have to do Scrum by the book? About ScrumBut, ScrumAnd and maturity
I regularly have the (wonderful) opportunity to help teams get to grips with Scrum and help them apply it in their company or project. Not only is this enjoyable because I get to help teams find a better way of developing software, it also provides with me with a wide variety of contexts where Scrum is being applied. Since every company, every team and every project is different, we always have to look for the best way to apply Scrum in a particular context with the given constraints. Rarely is it possible to do Scrum entirely as described in the Scrum Guide. The same goes for teams that have been working with Scrum for a while. For example, my Scrum Team at HROffice has deviated from Scrum avant-la-lettre by adapting and tweaking the process to suit our needs and constraints. Is this a bad thing? To what extent should you do Scrum by the book (or guide)?
The goal of Scrum
A meaningful answer to this question requires that we take a back step and identify what we’re trying to achieve with Scrum. For me, Scrum is a framework of practices and events designed to help the entire team achieve a state of flow and continuous improvement, and break down the walls between business and development. Obviously, this sounds easier on paper than it is in the real world. It takes teams months, even years, to truly ‘get it’. And quite a few never do. In a sense, Scrum has to become a mode of behaving for a team. As Gunther Verheyen from Scrum.org has stated: Scrum is (also) a stance.
To make this a bit more explicit, I would like to describe a good (Scrum) Team as having the following traits:
- Teams deliver working software _at least _at the end of a sprint;
- Members team up to work on the same tasks, either through pair coding or by taking on part of the work;
- Teams can level with, and relate to, the product owner when it comes to business needs and business value;
- Teams have achieved a steady daily flow in getting work done (little stress, few work spikes);
- Teams pragmatically deal with interruptions and difficulties, without compromising the sprint;
- Members like being part of the team and are proud of their achievements;
- Members openly discuss improvements and difficulties;
‘ScrumBut’ is a Scrum-implementation that deviates from the Scrum Guide. ‘Yes we do Scrum, but …’. This is where teams admit that their Scrum Master is also the Product Owner, that there is only a bi-daily Scrum, that the team is not fixed, that sprints have different lengths or that the sprint backlog is often changed during the sprint. Or teams deliver functionality, but test and release this during the next sprint. This is supposedly a bad thing, as Scrum is considered to be an ecosystem of practices. If you cherry-pick what you like, but leave out the rest, you will never be successful.
Another view is that of ‘ScrumAnd’. In this case, foundational practices of Scrum (as per the Scrum Guide) are in place but are extended with process- or technical practices that work well for the team. Some teams may decide to publish the sprint result to production at the end of every sprint. Other teams may decide to enforce stringent code reviews or pair programming practices. Still other teams may decide to implement team swarming to increase flow (and daily burn). In any case, these practices help teams become increasingly productive. And that’s fine.
But what happens when you _replace _foundational practices with other practices? Or if you decide that some foundational practices don’t work for you? Is that a bad thing? To answer this question we have to consider the maturity of a team.
The maturity of a Scrum Team
Teams new to Scrum
When a team is introduced to Scrum it is likely that there are constraints within the team or the organisation that limit how much of the Scrum Guide can be successfully applied. Constraints can come from a variety of sources:
- Maybe Scrum Masters mostly act as project managers because they feel more comfortable with that role;
- The role of Product Owner is taken up by a business analyst or shared by the Scrum Master;
- The next sprint is not being prepared during the current sprint, resulting in very long (and tedious) sprint planning sessions;
- The backlog is populated with mostly technical issues instead of functional ones;
- The sprint is sometimes extended with a day or two because that allows the team to finish more work;
- The retrospective is rarely done as there is hardly ever a moment when the team feels like it;
- Members mostly stick to their prescribed roles (tester, developer, designer) instead of having cross-over;
- The Daily Scrum is frequently forgotten or rescheduled. Or rarely attended by everyone;
- Members of the team are regularly pulled out of the sprint to work on other issues, such as support, unrelated meetings or bugfixes;
- There is a sprint 0 where teams analyze or design solutions, or the backlog is treated as a specification document where all stories are carefully analyzed and appended with acceptance criteria;
Although these are all examples of ‘ScrumBut’, they are — in my experience — mostly caused by a lack of understanding and experience of why Scrum works. Most teams start ‘getting it’ after a few sprints, which some members getting it faster than others. Forcing a team to adopt all the foundational principles right away rarely works out well, as it tends to increase resistance and people dropping out. Therefore, some degree of ‘ScrumBut’ is acceptable. As long as it is declining as the team increasingly gets into the process. There may also be some ‘ScrumAnd’ going on where teams adopt additional practices. Although this is not necessarily a problem, there is a subtle risk that they are considered to be a part of Scrum and therefore inflexibly applied (such as writing user stories, planning poker and sprint ‘grooming’ sessions) to the detriment of the process.
There are two ingredients that I think are necessary for teams to progress through this phase:
- Frequent structured retrospectives (metrics and subjective opinions) that address how the team can grow beyond it’s current state;
- A Scrum Master or coach that has more-than-average experience with Scrum and who is responsible for guiding the team and teaching them Scrum. Without such an experienced person, there is a significant risk that teams too easily drop practices that don’t fit within their constraints. Although a team may think they’re doing Scrum, they are not even close to achieving what could be achieved if they would incrementally add more foundational practices. This means that some gentle pushing is necessary;
Teams with moderate experience in Scrum
Teams that have been working with Scrum for a while have become familiar with the Scrum events and practices. These may still be applied with some formality, but it doesn’t feel awkward or uncomfortable anymore. Most teams have grown into the Scrum rhythm and adopted either all or most of the foundational practices (within the constraints). In any case, the majority of their sprints result in working and valuable software that is valuable and there is no longer any resistance to the process itself. The Scrum Master spends less time teaching Scrum and more time keeping the process running with the team, while the Product Owner has moved from simply providing backlog items to actively working with the team. The sprint velocity has mostly stabilized.
This is the ideal moment to start extending Scrum with additional practices (‘ScrumAnd’) such as continuous delivery, swarming, scaling and code reviews. As long as they contribute to delivering working software and increasing team happiness and effectiveness. A key risk for these teams is that they lack input on new (or adapted) practices that are not foundational to Scrum, but may benefit them. Or teams may lack the drive or initiative to do so, causing them to get stuck in this phase. Therefore it is important to focus retrospectives on evaluating new practices and improving ‘beyond’ Scrum.
Teams highly experienced in Scrum
Teams that have ample experience with Scrum often get into a flow where the delivery of working software has become second nature. For these teams the Scrum events are natural moments in a sprint where they review what’s done (and learn from it) or plan their next sprint. And because sprint preparation is pretty much an on-going process, the sprint planning itself is short and effective. In terms of the backlog, stories are specified just-in-time (before the sprint or during) and broken down into the smallest possible tasks that can still be sensibly shared within the team.
Teams with this level of experience don’t need to follow the foundational practices to the letter to be successful. From experience they understand what the practices are for and why they are important. Instead of following the guide to the letter, they’ve often tweaked and extended the process and the roles to suit their needs and constraints. It is entirely possible that scrum events are not longer formally timeboxed as teams naturally move fast and effectively. When they have achieved a high level of flow, the concept of a sprint becomes increasingly less meaningful as software is being delivered throughout the sprint (story by story or batch-wise). As long as the process has become ingrained and second nature, and the team keeps reflecting on their process, there is nothing wrong with this kind of ‘ScrumBut’ and ‘ScrumAnd’. If there is one risk for these teams it’s that they become too comfortable and complacent. So frequent critical retrospectives (preferably based on metrics) remain necessary.
Concluding thoughts
‘ScrumBut’ and ‘ScrumAnd’ are considered to be deviations from the Scrum Guide, either by dropping practices or by extending Scrum with additional practices. Of course every team and every organisation is different. Within the provided constraints, some degree of ‘ScrumBut’ is often unavoidable. But it should never cause a team to _not _deliver working software at the end of every sprint. It should also not inhibit the growth of a Scrum Team. Generally speaking it’s advisable to avoid ‘ScrumBut’ whenever possible, especially for teams new to Scrum. On the other side is ‘ScrumAnd’, or extending Scrum with new practices. Although this should not be the focus for teams new to Scrum, it is a useful way to allow a team to grow ‘beyond’ Scrum. Teams that have ample experience with Scrum have usually adapted and tweaked their process significantly. Although this can be classified as a mix of ‘ScrumBut’ and ‘ScrumAnd’, this is rarely an issue as these teams have a natural understanding of what Scrum tries to achieve: self-organizing teams that deliver working software as frequently as possible. Although they started out following a framework, they ended up owning the process.
