5 Gaps In Scrum
I recently spoke at a corporate community of practice event. My session presented a useful model to identify indicators within a system to predict its failure. First, we started by applying the model to everyday systems everyone could relate to. Next, I asked the attendees to map a system of their own. As I walked them through my model step by step, I used Scrum as my example system. Upon completion of the worksheet (see my completed sheet below), attendees were able to see if there were any “gaps” in their systems. The gaps provided an indication that a respective system was at risk of failure.
To clarify, on a delivery team level, I see the Scrum Framework as a solid method for managing product development. But what about Scrum in the context of the entire delivery organization? Using both The Three Things You Need To Know To Transform Any Sized Organization and my model, I look at Scrum in a broader context. With that, I note 5 major gaps.
What are the 5 gaps in Scrum?
My model will segment any system into 5 areas: Clarity, Commitment, Ritual, Progress, and Habit. The gaps that I will note below are those things not mentioned in the Scrum Guide.
Gap 1: Clarity
What does the structure of the organization look like (Portfolio, Program, Product) above the Scrum Team? We need a shared understanding. What does the governance of the organization look like (Budget, Dependencies, Risks, Quality,…) above the Scrum Team? What are necessary metrics and tools of the organization above the Scrum Team? Some organizations are very large and heavily distributed. How will you measure the health of the entire delivery system?
Gap 2: Commitment
In Mike‘s 3-things talk, he calls this accountability. Given the broad applicability of my model, I prefer to call it commitment. Commitment can be any resource. So, what money and time may be required for Scrum training of all leadership and Scrum teams within an enterprise? What money and time may be required for procurement, installation and training of tooling used to manage and report on the health of the delivery system? Lastly, we need agreement from the Leadership team to follow the Scrum Framework (or more particularly respect that the Scrum team is following it).
Gap 3: Progress
As I noted in my post on Productivity Patterns, if you lack progress, you lose momentum. If you lose momentum (or should I be so bold to say velocity or throughput), you will lose commitment to the system. Those who are funding the efforts (those outside the Scrum team) need to know progress is being made in a way that is important to them. What is the Time to Value? Is the Scrum team predictable on a release level (Release Burndown/Burnup chart)? Are we even building the right things? (Product Fit) Are we building things right? (Quality)
Gap 4: Rituals
Rituals can be event or meetings, as part of your system of delivery. First, let’s start with product vision. Scrum teams have a horizon of a few weeks (the sprint). Vision is viewed or realized in months, quarters, or years. Read the Scrum Guide and you won’t see Vision mentioned once. Also absent from the Scrum Guide is the notion of portfolio or release planning. Unless you have a delivery capability that allows you to release at the end of every sprint, I can’t champion release planning enough. In addition to that, good portfolio planning ensures we have a balanced system of delivery and ensures we have capacity to make commitments against a roadmap.
Gap 5: Habit
Given the rituals I outlined above, you should make it a habit to have periodic Vision Reviews, regularly scheduled Portfolio Planning/Reviews, and ensure you’re consistently doing your Release Planning.
Conclusion
I’m not suggesting you abandon Scrum. But after you look at the highlighted gaps I listed above, in a system of delivery larger than a single Scrum team, you should consider more than what is in the Scrum Guide.
Comments (6)
Mike Dwyer
What you cite here and in other work is exactly what Scrumguidelines (www.scrumguides.org) define Scrum as being about. “Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and development practices so that you can improve.”
So the real question becomes how does one take generalites such as this article and use them to improve the efficacy of what you and your organization is doing.
Short form of this comment is simply. Good news, we found a hole in the whole, how are we going to use this to get better.
BestRegards
Mike Dwyer
Mike, thank you for you comment. I really like your question, “So the real question becomes how does one take generalities such as this article and use them to improve the efficacy of what you and your organization is doing.” My response is we use the generalities to spark a conversation. We use them as something we can anchor to, in order to understand the problems people and organizations are trying to solve. I know too many who quote the Scrum Guide like it is gospel. When I ask probing questions about things not explicitly written in the Guide, I sometimes get a blank stare. I want to force a (respectful) exchange of ideas. Thank you again. Best Regards, Derek
Sunish Chabba
Hi Derek,
I’ve been following your work on System Design Canvas and when I saw this post, it piqued my interest automatically. Is it just me or have you also observed that the gaps reveal the scaling problem which Scrum (as defined in Scrum guide or even in other earlier texts) never tried to provide answers for.
Product Management, Budgeting, Governance & Change Management are the other themes I can see from the above gaps, which is a good starting place to initiate conversations with clients without getting them overwhelmed by talking about SAFe and other scaling frameworks.
Regards,
Sunish
Sunish, yes, I have also observed that. I think the beauty of the Scrum Framework is that it’s a framework. It’s simple enough that you can apply it to many situations and environments. The challenge I see is many want to buy and install Agile. You can’t merely take Agile off the shelf and drop it into an organization. You have to think through the bigger challenges the organization is facing (as you noted: …Budgeting, Change Management). I think that is why SAFe and other scaling frameworks are selling so well. You wrote something that really resonated with me, which applies to another comment left on this post. “which is a good starting place to initiate conversations with clients”. Yes, yes, yes! I see using my canvas (and this post) as a simple tool to facilitate a respectful conversation about “everything else”. Best Regards, Derek
jeff streitmatter
An excellent compliment to Mike’s ‘3 Things’ discussion. Organizations may adopt Scrum to organize their delivery teams, but there must be a framework to align the Portfolio and Product work processing in the same manner. That’s the gap between Agile and the reality of enterprises implementing Agile at scale.
Thanks Jeff! As noted in my talk (and the worksheet), many things outside the delivery team can kill their ability to produce value for the organization. We need to have more conversations about those things, if we wish for Scrum to not be the next failed experiment of the organization.