Scrum is like my mother-in-law; it points out all my faults. Ken Schwaber, one of the master minds behind scrum, is credited with that quote, and there’s a lot of truth to it. Scrum is an exposure model; it’s intended to highlight weaknesses in an organization and its processes. It’s then up to the organization and its people to find solutions to those problems. Unfortunately, many organization solve these problems by removing the parts of the scrum framework that cause the pain.
It seems like a silly way to solve the problem, doesn’t it? When a stranger comes to my house, I have a cat who runs to the bedroom and hides under the comforter. She feels safe because she thinks if I can’t see the stranger, the stranger can’t see me. Sorry, stupid, we can see the lump in the bed. You’re not fooling anyone. So what part of the framework do I see organizations tossing out most often?
When the team leaves sprint planning, they should have in front of them everything they’ll be accomplishing over the course of the sprint. That commitment is immutable. It should not change. Work should not be added, removed, or even exchanged for other work. Most importantly, this commitment should be made by the team without abetment from individuals outside of the team, and it certainly shouldn’t be dictated to a team by the product owner.
Of course, I write this with confidence but also some measure of skepticism. I recognize the realities of the work we do, and I recognize that sometimes things come up that cannot be put off. My argument is that we’re too quick to loosen up that commitment, and my heart burn is this:
When everything is the exception, why have the rule? tweet
That’s a rhetorical question, but I’ll tackle it anyway. Why have the rule? What’s the intent behind requiring that the commitment remain unchanged between sprint planning and the demo? I’ll give you six reasons:
- Before we can expect a team to take their commitment seriously, the organization must do so. It starts by having the discipline to keep your commitment static.
- If nothing changes and the team doesn’t meet their commitment, the team is more apt to confront its own shortcomings.
- Ensures the team stays focused and is free from organizational noise derived from a changed commitment.
- Ensures the team has a clear goal (or set of goals) to complete by the sprint review.
- Creates a predictable, simple, and straight-forward mechanism for work delivery.
- Keeps the target stationary. A moving target is much more difficult to hit.
But again, let me be clear on this. Things come up. Things change. It’s how we react in these circumstances that counts. All this is great (assuming you agree), but what can you do to be part of the solution?
In my next blog post, we’ll tackle just that. I’ll provide practical advice that scrum masters, team members, product owners, and stake holders can follow to ensure they’re part of the solution. In the meantime, I look forward to your questions and comments below.
* Note: Many people prefer instead to use the term forecast instead of commitment, and that’s okay. I prefer commitment. I believe the stronger language makes it more meaningful, and I think this is important. Failure to meet the commitment (or failure of any kind, for that matter) should be embraced and viewed by the team as an opportunity to learn and improve.
Fail early. Fail often. But never fail the same way twice. tweet