I met Scrum in 2011. Since then I've worked in a number of Scrum teams in various projects. It's not that I always consciously chose to adopt Scrum in my work, but rather, it dominated the entire software development industry in the last 10 years or so. Overall it's been a positive experience but not without occasional doubts and disagreements.
It's a shame that through all these years only recently I got my hands on the Scrum Guide and had the chance to read it from top to bottom - thanks to a friend who suggested me to take a look at it. First of all, I was positively surprised by how short it is. And secondly, I realized something important:
Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques.
Because Scrum is relatively small and designed as a process framework, it has been extended and interpreted in various ways by its practitioners. As a result, it has become more and more difficult to separate the original framework or its actual intention from the interpretations of it. Popularity of an idea usually doesn't help either. The more you spread something, the thinner it gets.
Reading the Scrum Guide helped me to understand some of the misconceptions I have witnessed around Scrum and in this post I'll try to bring a few of these together.
One disclaimer before we begin. Although this post is categorically about software development processes, I'm not a rigid process advocate by any means. Just like it's written in the Agile Manifesto, I always prefer placing "individuals and interactions over processes and tools". In fact when I sat down to write this post, I unintentionally wrote another post.
With that final note, here is the 7 Scrum myths that I often witness in my career:
1. Development Team commits to a Sprint Backlog.
The first version of Scrum Guide indeed used the term "commit" but very early on, between 2010 and 2011, it was replaced with "forecast". Here's what Scrum Guide revision history says about it:
Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint.
The word "commitment", in my opinion, sounds heroic and ignorant. It means you have to do something no matter what. It's blind and closed to new discoveries. On the other hand the word "forecast" is smarter, open to learning and adaptive. Good that this got fixed early on.
2. Once the Sprint is started, scope cannot change.
We've just discussed above that a Sprint is not a commitment but an educated forecast. The scope of a Sprint can very well change as more information gets discovered along the way. Let's refer to Scrum Guide revision history again:
The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint.
Committing to complete a piece of work early on in an unpredictable environment and keeping to that schedule and scope "no matter what" is not something to be proud of. It's simply foolishness. Only a fool would ignore any discovery he makes along the way and stick to the original plan or course of action regardless of what this new information reveals.
3. Finishing a sprint is a noble cause and a good team always pursues this goal.
I've been to many workplaces where finishing a Sprint was seen as a holy grail and pictured as a strict duality of success or failure. This is a very shallow way of measuring success. This mindset also opens up the door to a range of unsustainable behaviour like working overtime just because one story didn't make it or cutting corners to be able to declare a story as done. We've all done these in the past.
When we improve our understanding of what a Sprint is and having already busted the previous myths of commitment and strict scope, it becomes more clear why Scrum Pillars are defined as transparency, inspection and adaptation - and why "Finishing the Sprint" isn't there. It's just irrelevant.
4. Scrum Team must release to production at least once every Sprint.
Not sure where it originates from but many people think after each Sprint a Scrum Team has to release what they have built into production. Did you know that Scrum says nothing about "Release Planning"? Here's a remark made in the Scrum Guide between 2010 - 2011:
Release Planning is a valuable thing to do when using Scrum, but isn’t required by Scrum itself.
And here's what Scrum Guide says about the Sprint Increment:
An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it.
A smart move from Scrum authors. It turns out Release Management can be a complicated and multifaceted process depending on your product and your user base. If Scrum naively mandated some sort of a one-size-fits-all release management process, it would quickly be thrown out of the window. It's a subject better be left to the Team and to Product Owner to judge and decide what the best course of action is.
As for the believers of this myth, if you're not releasing some finished piece of work to production at the end of a Sprint, you can't be possibly Agile, or practicing Scrum for that matter.
But let's not be religious about this. There are many reasons why a team might choose not to release a change or a new feature to their users just yet. It can be that only a part of the feature is completed and doesn't add any value without the rest. Any non-trivial size feature can fall into this category. Not everything is buildable within a single sprint. Duh!
It can also be that the release cadence is too aggressive for the users of the application. Evolving an existing product with an established user-base is a very delicate process. You can't simply throw bits and pieces of your features at your users as they get spit out of your Sprint machine. You have to make more comprehensible changes, create migration paths when necessary and more important of all, give time and choice to your users when making important changes.
Also useful to keep in mind that deployment is not the same thing as releasing, which means you can deploy a partial or full feature to production and still decide not to release it (f.ex by using feature toggles). So a team can perfectly follow engineering best practices like integrating early and deploying working software as often as possible but still keep certain features in dark.
Finally, it's important to highlight that the Sprint increment should be a step towards a goal and should be inspectable and support empricism. Whether you want to release it to your users or not is up to you!
5. Product Backlog refinement and Sprint Planning should focus on the problem space and NOT on the solution space.
Some extensions of this myth:
- The Sprint itself is the place for finding and implementing solutions.
- Effort estimations should NOT be based on solutions but rather on the complexity of the problems.
This is a very romantic idea which argues that for any given piece of work, the Scrum Team should initially focus on the problem space by making sure the problem is well defined and well understood. Then the team should go and estimate the effort purely based on the complexity of the problem. And only after the Sprint is started, should the Development Team start focusing on solutions and implementing those solutions.
I think this is a recipe for disaster. Without a doubt, making "the problem" and "the need" clear in a Product Backlog item is very important. But strictly limiting it to that until the Sprint starts is an act of recklessness or being naive at best. Luckily I don't have to argue against this with my own words because the Scrum Guide already does it very clearly:
Sprint Planning answers the following:
- What can be delivered in the Increment resulting from the upcoming Sprint?
- How will the work needed to deliver the Increment be achieved?
Here's another section from the Scrum Guide revision history:
The Sprint Backlog is the Product Backlog items selected for the Sprint, plus a plan for delivering them. A self-organizing Development Team always has a plan.
Already at the beginning of the Sprint the team needs to have a common understanding of what needs to be done. Obviously some more details will be revealed within the Sprint and further choices will be made, but the overall direction around how to solve a given problem should already be there at the start. So yes, we should be talking about solutions all the time - in refinements, in plannings and obviously within the sprint.
6. At Sprint Review Meeting, Development Team presents what's done to the Product Owner. Product Owner accepts or declines presented features and solutions.
This myth is partially an extension of the previous one above. It's a continuation of that romantic idea where the team comes up with creative solutions in the Sprint, builds them and then presents the results to the Product Owner (PO) at the end of the Sprint. And PO decides which ones he finds fit and which ones not. Rejected solutions are dropped from the increment and back to the drawing board.
Another recipe for disaster. As a matter of fact, what needs to happen is exactly the opposite. Instead of letting everything stay in limbo until the end of the Sprint, the ideas of shift left and fail fast has to be adopted by everyone in the Scrum Team. That means frequent communication and alignment. Validating everything as early as possible with the rest of the team and the PO. The earlier problems are identified, less waste is created.
During the Sprint Review meeting, nothing that is being presented there should be a surprise to any member of the Scrum Team - because they've been communicating and aligning on those items all the time.
7. At Sprint Review, the Development Team is only allowed to demonstrate Sprint Backlog items that are "Done". Partially done items cannot be demonstrated.
Perhaps I should start by confessing that this, in fact, is not really a myth. The statement above is pretty legit. Even though the Scrum Guide never explicitly forbids demonstrating partially done items, it still makes it pretty clear what should be demonstrated:
The Development Team demonstrates the work that it has "Done" and answers questions about the Increment.
So clearly, it's unfair to present this as a myth, but I still want to add it to the list because more often than not I find myself in disagreement with it. Arguably, this rule represents "high standards" and looks very nice on paper but let's look at it from a more realistic angle:
In many business environments (think of banks, large firms etc.) the only time you can get all stakeholders together in one room is the Sprint Review meeting. If you're running two week sprints, that's going to happen twice a month. Bear in mind that this is a very good number! There are many organizations where sprints are either longer or stakeholders occasionally skip those review meetings. So in many cases it's likely to be even less than twice a month.
Let's go with the good scenario that all stakeholders get together twice a month. It happens often that a feature story can be fully implemented from a coding perspective but a bug might have been found or a test case might be missing. So based on the "Definition of Done", it might not be "Done". But the whole feature flow would be available to demonstrate and elicit feedback in that valuable review meeting which happens only twice a month.
I would like to think that we're all responsible adults and when we want to demonstrate a piece of work, even if it's not 100% complete, we do that to elicit feedback - not for deceiving ourselves and our stakeholders. If that's not the case, I'm afraid you have more serious problems to fix first.
Probably one important rule of thumb is to make what's "Done" and not "Done" crystal clear to everyone in the meeting. Once that's out of the way, trying to get as much feedback as possible is a good way to spend that valuable time.
I came across this blog post from Mike Cohn, "Only Show Finished Work During a Sprint Review—Maybe", where he says:
To get feedback during a sprint review, a team may occasionally show incomplete work.
It's a nice read btw, if you're interested.
The main takeaway from this post isn't really about finding out which ideas are original Scrum and which are "fake". An idea being original Scrum doesn't make it "sacred" either. Teams don't become good at what they do by simply following blind rules. The world around us is too complicated for that. That's why teams should be encouraged to find their own paths in their own unique circumstances. I think Scrum encourages that as well.
It's important to remember that none of these techniques, be it Agile or Scrum, are management techniques. It's only useful to adopt these ideas as part of a grassroots movement, complemented with people excellence and technical excellence.
Thanks for reading and until next time 👋.