By EHAB EL-BADRY
Senior Consultant
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 and want to make sure we level set and use the same language.
IMHO there is such a thing as adhering too much to the guide though. 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 that 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 indeed repeatedly refers to producing “Done” increments of the product by the end of every sprint, and that “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. 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 some how 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 an 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 the team 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 progress becomes reduced to, as the Scrum Guide puts it, monitoring “burndowns, burn-ups, or cumulative flows”. These can easily become vanity metrics - they do not show real progress of the product.
3. The Development 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 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 that they will ultimately use will most likely result in a product that will not meet their expectations, or produce features that will ultimately not be used. The Development Team should be able to get clarifications from users as to what the feature they are building 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 Development 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 definitely 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 that the team cannot fend for themselves and cannot make priority calls themselves 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 the managing and ordering of these items. Not much is mentioned about how much time the PO should be spending on such activities and what other activities they should be engaged in. Because these other activities aren’t really mentioned, many of the implementations of Scrum I’ve seen reduce it 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 (either 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 hence introduce more complexity and hire for yet another role - a Product Manager. The PO then becomes just a story writer, an interface for the team, and is 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, competitors, etc. It is very important to strike a balance and empower and trust the team to manage their day to day while the PO is looking forward.
5. The Scrum Master is busy removing the Development 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 towards 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 away time from focusing on the organization and guiding the organization 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.