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?
Commitment.*
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?
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.
Do you want to get notified when new posts are published? Leave your email below.
When I was up at Scrum.org in November there were a few mentions by trainers that Scrum was beginning to drop the word commit and commitment and replace it with forecast. If you look at the current scrum guide by Ken Schwaber the word is not used. I admittedly was curious about the change but regrettably did not ask. Maybe because it is being used too much as a weapon these days?
Maybe I should of read the note but these are some pretty influential folks using forecast (i.e the founders)
Found it:
https://www.scrum.org/About/All-Articles/articleType/ArticleView/articleId/95/Commitment-vs-Forecast-A-subtle-but-important-change-to-Scrum
I realized this might come up, which is why I footnoted the word commitment. 😉
And thanks for the link, Mark. I don’t disagree with any of what they have to say so, for me at least, it really comes down to preference based on my own experiences. I explained some of the why in my note, but here’s a bit more:
* Failure should not only be embraced but rewarded at the individual and organizational level
* Our brightest minds are often the worst at accepting and learning from failing because it happens so rarely for them
* By softening the language, we lose an opportunity to coach our brightest through failures and helping our organizations adopt a culture of rewarding failure
There’s a lot more on the topic that comes to mind, and I intend to put more thought and words around it so keep an eye out for a future blog that digs much deeper. Most of what I know and have learned on the topic come from 10 years as a Marine, and I feel they exemplify the idea of both rewarding failure and holding people accountable so I expect the blog will draw heavily on my military experiences.
Yes it kinda took me aback but didn’t want to turn the session I was at into an off topic debate. I can understand both sides and I think the best is to use whatever works best in your team’s environment and stay consistent. Like most things:)
Agreed. And thanks for the great discussion.
I think the word forecast is better. The team commits to do their best to hit their forecast. It is a very subtle but important difference. The external perception of the word commitment sounds more like a guarantee, whereas forecast infers that based off data we think we can get to point B, but it’s possible we may be a bit off. For teams, I feel it takes away some of the pressure and temptation to cut corners to hit a commitment. The softer forecast word IMHO encourages higher quality and a more realistic, pragmatic view, both inside and outside the team.
Thanks, David. I expected my use of “commitment” was going to garner me some comments. In case you didn’t see it, I provide more context of why I prefer it over forecast in my reply to Mark. I certainly don’t disagree with the use of forecast, and I would even use it myself if I felt it was a better fit for teams and organizations that I work with.
The “commitment” stuff sounds like rhetorical tangle – for addressing simply working through the priorities as they stand each hour of each day. “Estimates”, better “forecasts”, are based on what is visible at the time, and priorities are set accordingly. When more is visible, forecasts change and priorities shift. The sprint goal remains, but the means to getting their changes as we go. Things move in and out of scope according to priority and time available.
I think “Rewarding failure” could be better expressed as rewarding having a go.
I mostly agree, Andew. Words are important, but more important is the mental models those words convey. The argument between commitment or forecast is one I avoid investing too much emotional energy into.
As far as rewarding failure, I like how I put it in one of my more recent posts:
“Success is a terrible teacher. Failure is a catalyst for learning. Teach those around you how to recognize failure and use it as opportunities for learning and growth.”
I usually condense that to ‘reward failure’ but only after I’ve ensured those I’m speaking with understand the intent.
That post: https://www.spikesandstories.com/agile-north-star/