Five indicators the Scrum Guide is holding you back
There is such a thing as adhering too much to the guide. Scrum is “barely sufficient” and empirical by design. Here are five patterns that signal a team has stopped adapting.
Every now and then I like to read the Scrum Guide. Sometimes for my own benefit, to try to stay true to the origins of Scrum, and sometimes because I’m kicking off a new Scrum team or mentoring new Scrum Masters (SMs) and want to make sure we level-set and use the same language.
There is such a thing as adhering too much to the guide. You may think that implementing, to the letter, the words of wisdom put forth by the creators of Scrum would be a good thing. But it’s not. Scrum is a framework that is barely sufficient and, in their own words, “empirical.” You must iteratively adapt your processes as you go forward, or else you’ll always be stuck at Shu, your training wheels won’t come off for Ha, and you definitely won’t reach the transcendence of Ri.
Over the years I’ve come to see certain patterns, indicators, that a team or organization is in a rut it is unable to get out of. If these patterns apply to your team, then you should revisit whether or not you are indeed embracing continuous improvement and the empiricism of Scrum.
1. No working software delivered at the end of each sprint
This is a big one. It’s true that the Scrum Guide repeatedly refers to producing “Done” increments of the product by the end of every sprint, and that the “Done” increment should be “useable and potentially releasable.” On the other hand, the guide also gives room for interpretation as to what the Definition of Done should be.
The Agile Manifesto clearly states that “Working software is the primary measure of progress” and that the highest priority is to “satisfy the customer through early and continuous delivery of valuable software.” Many teams quickly lose track of that because they feel the Scrum Guide gives them room to define what the Definition of Done is, which easily can fall short and include things like “Ready for QA” or “Ready for Integration.” Releasing to a production environment (and using feature-toggle flags) or a production-similar environment should be a must.
Keeping true to this principle will force teams to truly be self-organizing and cross-functional, by making sure they, as a team, can indeed finish a feature from start to finish. It also closes the feedback loop and puts the pressure on stakeholders to study the outcome and make a decision: whether to pivot or persevere. Otherwise, you get teams that continuously carry over work from one sprint to another, not feeling the value in producing a complete unit of work to make real-life decisions.
2. The team has no clear vision and roadmap
The Scrum Guide vaguely refers to a vision or roadmap by using the Product Backlog “to best achieve goals and missions,” hence reducing it mostly to a prioritization game, the ordering of backlog items by the Product Owner (PO). Other than that, there is no mention.
Some may argue that the Scrum Guide should not, and cannot, go into detail on every single aspect, but I feel somehow this should be a big part of the framework. Originally Scrum was thought of as a framework to manage projects and was later changed to a “framework for developing and sustaining complex products.” The differentiation here is crucial, and many teams that I’ve worked with fail to see it.
For teams to truly be performant Scrum teams, they should be motivated by a vision, and use the framework to help guide them to make decisions on where to go, lean-startup style: put forth a hypothesis, build it, and check if the hypothesis is true or false. If the team doesn’t feel connected to a vision and understand why this backlog of features (i.e. experiments) may help them reach that lofty goal, then they will automatically fall into just building things because the PO asked them to, without fully understanding why and contributing to that vision. Another byproduct of having no clear vision and roadmap is that progress becomes reduced to monitoring “burndowns, burn-ups, or cumulative flows”, which can easily become vanity metrics that do not show real progress of the product.
3. The team doesn’t collaborate with stakeholders and users
In the Scrum Guide, stakeholders and users don’t really make an appearance until the Sprint Review, which is odd because the Agile Manifesto calls for business people and developers to work “daily throughout the project” and states that “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
Failing to include stakeholders and actual end users in the design and building of the product they will use will most likely result in a product that does not meet their expectations, or features that go unused. The team should be able to get clarifications from users as to what a feature should look like, and not attempt to figure it out on their own or depend on the PO to spoon-feed them every minute detail. The team should have direct access to users and get feedback from them as they refine backlog items, or else the PO becomes a proxy and a bottleneck, which is not the spirit of agile software development.
Unfortunately the Scrum Guide is very prohibitive in saying “No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.” It is true that many so-called agile organizations have a bad habit of breaking process and forcing the team to change direction all too often, or take on more work than they can handle, but this can be used to discourage teams from working with users and stakeholders directly. It also assumes the team cannot fend for themselves and cannot make priority calls based on a clear vision and roadmap.
4. The PO is too involved with the team
Strange enough, you may have noticed that there is no mention of user stories in the Scrum Guide. Nonetheless, many POs spend the lion’s share of their time “writing stories.” The Scrum Guide refers to “Backlog Items,” and the PO is responsible for managing and ordering these items. Not much is mentioned about how much time the PO should spend on such activities and what other activities they should engage in. Because these other activities aren’t really mentioned, many implementations of Scrum I’ve seen reduce the role to backlog management, clarifying and accepting work from the development team.
When a PO spends too much time writing stories and working with the team to clarify items, that’s time spent away from surveying the market, analyzing competitors, brainstorming new features, and basically acting as the CEO of the product being built. As a result, many companies have very unclear or weak product visions (see point #2), or block the team (implicitly or explicitly) from interacting with end users for clarifications (point #3), because that’s the PO’s main job. Other organizations eventually come to see the need for more product vision and introduce more complexity by hiring for yet another role, a Product Manager. The PO then becomes just a story writer, an interface for the team, stripped of their ability to make real influential product decisions.
It is understood that perhaps the opposite problem is more readily seen by teams. The PO is not available to the team enough to answer their questions. That may be true, but the solution isn’t the PO taking the opposite stance and neglecting the product vision, market trends, and competitors. It is very important to strike a balance and trust the team to run its own day-to-day while the PO is looking forward.
5. The Scrum Master is busy removing the team’s impediments
Whenever I ask what the responsibilities of a SM are, almost always the first response is “removing impediments to the Development Team’s progress,” which certainly is mentioned in the Scrum Guide. Unfortunately many people forget that the Scrum Guide also mentions the SM’s responsibility toward the organization. Perhaps that is because the guide focuses primarily on the team and very scarcely on the organization. This is especially problematic considering most Scrum teams do not work in a vacuum and are part of a larger team. Issues in the organization become especially pronounced when scaling Scrum is attempted.
Just like the PO, if the SM spends the majority of their time on the team, unblocking them as they work on particular items in their Sprint Backlog, this takes time away from focusing on the organization and guiding it to be agile versus do agile. If the SM is stuck continuously unblocking the team, then there are larger problems to be solved, and the SM should focus on coaching the team to figure out how to unblock themselves so the SM can focus on the organization and not simply be content with handholding the team.
Many SMs fall into this grave mistake, and it is for this very reason some organizations are making a distinction between Scrum Masters and Agile Coaches, where the latter focuses on the organization and the former just on the team. This was never the intention of Scrum. SMs should be able to do both. Again, balance is key here.
Read against these five patterns, the Scrum Guide is a starting point, not a finish line. Teams that keep adapting past it are the ones that ship predictable releases, carry fewer defects into production, and keep improving without being told to. If any of these patterns look familiar on your own team, see where delivery is getting stuck.