Project Management

Where’s the Commitment?

From the The Reluctant Agilist Blog
by Dave Prior

About this Blog

RSS

Categories

Date

Categories: Scrum

The Scrum Guide is the document created and maintained by Ken Schwaber and Jeff Sutherland at Scrum.Org and it serves as their definition of what Scrum is. A recent change to that document has the potential to significantly alter the way many people look at Scrum.

Here is the definition of the change as defined in the update notes:

Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint.
(See: http://www.scrum.org/storage/Scrum Update 2011.pdf)

For some, the switch from commitment to forecast will be simply semantics and not a point of concern. But I believe that removing the idea of making a “commitment” and changing it to “forecast” has the potential to be a very dangerous change for Scrum. For high performing, committed and focused teams, this may not present a issue, but for the teams that are just beginning a transition to Scrum, or struggling with the discipline required to follow the process, this change has the potential to make it “OK” to not deliver potentially shippable code in any given Sprint.

In Scrum, at the end of the Sprint Planning meeting, the Team makes a commitment to the Product Owner. The team commits to what stories it says it will get done during the Sprint. While it is not expressly stated as such, this commitment is basically the Team saying to the Product Owner (and thereby to the Business), “if you are available to us for questions when needed, and otherwise do not disturb us or try to alter what we are agreeing to do, we will have these stories completed and ready for review by end of Sprint.” This may sound simple, but there is a lot going on here.

First, the Team is saying that they’ve looked over the prioritized work, and with their current (but admittedly incomplete) understanding of what is being asked of them, they feel enough comfort with their knowledge of the stories, the project, the process of getting work done and accepted, and their own capacity and abilities as a team, that they can take responsibility for getting that work to a state of potentially shippable by end of Sprint. So, while each Story Card may only represent a conversation, enough work has been done breaking it down into tasks and understanding the acceptance criteria that the Team is willing to be held accountable for it.

Accountability is a critical part of Scrum. Once the Team makes the commitment, they are responsible for it. If they’ve over committed, they still need to get the work done. If one team member becomes ill or is otherwise not able to perform their role, the Team still needs to get the work done. There are times when, for one reason or another, the Team can’t complete the work. If there is a valid reason for this, they should feel no fear about reporting to the stakeholders in the Review Meeting. If, however, they are just not getting it done, they should experience a significant amount of discomfort at having to explain their failure to meet commitment to the people whose budgets are paying for them.

For the Team, commitment is important because it carries weight, and the Team should feel the burden of that on their shoulders. However, the Team should NEVER commit to things it does not feel it can accomplish. This is something that they need to defend. No one is going to praise them for not doing what they say they’ll do. The promise of Scrum is that you get potentially shippable product at the end of every Sprint. When a team commits to things it does not believe it can do, it is basically committing to failure. Scrum offers the Team great power and, as Uncle Ben said, “With great power comes great responsibility.”

In addition, as it is working through the Sprint, the Team should be monitoring its progress towards meeting the commitment. Anytime an individual works on something that does not contribute to meeting the commitment, the team should work to correct that because it is the other team members who have to pick up the slack.

It is also important to note that it is not just the Team that is making a commitment. When the PO accepts the Team’s commitment, he does so on behalf of the Organization. The PO’s part of this commitment involves ensuring that she is available to the team as needed to provide additional information about the features defined on the story cards. It also means that the PO is agreeing (on their behalf as well as the organization) to not introduce change into the Sprint once the commitment has been agreed upon and to not otherwise disrupt the team (or permit the Organization to do so).

This two-way commitment is the basis of trust for the Sprint. When a commitment is not met, the trust is endangered. If this happens and the Team cannot determine why and make necessary corrections, it may result in the team repeatedly failing to meet its commitment. At this point, the idea of a Team commitment becomes invalid, and the lack of accountability places us more or less back where we were before taking on Scrum.

In many ways, Agile is a privilege, not a right. Teams should treat it as such and be respectful of the idea that “with great power comes great responsibility.”

Posted on: July 26, 2011 02:01 PM | Permalink

Comments (3)

Please login or join to subscribe to this item

Anonymous

There will be plenty of opinions on the continuum of support and opposition. This is my first, but certainly not my last, public comment on the matter. At the Scrum Gathering in Minneapolis several years ago, Ken S. stated that notion that there would be or should be a Scrum 2.0 was illogical and groundless. Scrum was so simple and pliable that users could adjust it as they desired, but the more they strayed from the core, the more it became the proverbial "Scrum, but." I feel that Dave has solid, reasonable points regarding his opinions about the commitment matter and selecting and isolating words he chooses to describe his feelings and other points is a bit absurd to me and smells of familiar tactics used by some talking heads.

The underlying troubling issue for me in this matter is whether any one, two, three or four people can legitimately lay claim that they are definitive source of Scrum knowledge and can unilaterally institute change that may not even have been warranted or desired. It smells strongly and fervently bad to me. This has always been a “community-based framework” and any claim to being definitive authoritative regulator of its content and practice was surrendered long ago. To operate otherwise, a person would have to have a legitimized right to the content. The Scrum Guide is, indeed, the work of Schwaber and Sutherland, but that doesn’t make it or them anymore authoritative or regulating than Norm Geisler is to the Christian religion. Of course, Schwaber and Sutherland should be respected and admired as the creators of Scrum and their opinions should be appropriately honored, but to decree that their Scrum Guide is the singular, definitive body of knowledge about Scrum is really preposterous.

Those of us who use, train, teach, coach, live Scrum can appropriately decide whether “commitment” should remain a tenet of Scrum and/or whether forecast is suitable. No one person need dictate to us which we select – either, both or neither. For me, commitment remains in tact and forecast is something we can do.

What is the next thing we might see - a declaration of a change of Scrum values and principles? To me, this "anouncement" has just created undesired and wasteful noise in our community. It may provoke some worthy discussion, but such dialogue should ensue (and does ensue) without inspiration by some whimsical declaration of change. We are way beyond that point in the adoption and use of Scrum. Perhaps if a person or persons have difficulties with the 10 Commandments, they can rewrite those for more sutable use. Tha will precipitate similar discussions.

So, I’ll respect Scrum’s founding fathers as such respect is certainly due them. But, using the US Constitution as a simile,just as no single person or small group of persons can unilaterally and single-handedly make changes to that document with an “updated publication," neither can a person or small group dictate changes to Scrum. It took (and takes) the authority and support of the broad US community to foment change in the US Constitution by virtue of the defined amendment process. We don’t need that kind of process to change Scrum; it will evolve on its own as its users desire without directives and mandates.

Posted: Jul 28, 2011 4:23 PM

Anonymous

I probably would like to present this data as some form of trigger for further thinking. How many shops have you been who claimed they are an agile shop and yet they don't complete deliverables on the desired/targetted time? How many times did you hear people we need flexibility and yet you hear the same complaint that the team is continually firefighting and submitting emergency release almost immediately after production cut-over.

I thought the whole intent of scrum is to thinly slice the pieces of a product for better quality and more efficient delivery of product from a time perspective through the application of proper techniques in product development. Scrum did not say that we can just create something fast to the detriment of quality.

Posted: Jul 30, 2011 3:56 PM

Anonymous

Getting back to Dave's original observation, my colleagues and I think the distinction between committing and estimating (or forecasting) is critical enough that we have made it our central tenant of our approach - Commitment-based Project Management.

As Dave points out, having each member of the team taking responsibility (for not only his or her pieces, but for keeping the project on track to it's goals) changes the whole dynamic and is the best and maybe the only way to build trust and confidence among the entire team. Teams who can see that they are consistently able to accomplish what they said they would make even stronger commitments in the future (build commitment muscle), which comes in handy when the overall scope inevitably evolves. The Agile philosophy is very clear about enabling the creation of high quality outputs, but it should not be forgotten that a team that can deliver quality products with a degree of predictability (around timing) is more valuable than a team that eventually creates quality outputs, but never knowing when it will be releasable, until it is.

In our experience there is more to operating from personal commitments than just adhering to the scrum steps. Taking the fear and blame out of speaking up, when a commitment is in jeopardy is critical and requires leadership. We are committed to the notion that this leadership can be taught/learned.

Thanks Dave for not letting this critical declaration go un-tested.

Posted: Jul 31, 2011 3:30 PM

Please Login/Register to leave a comment.

Where’s the Commitment?

About this Blog

RSS

Recent Posts

Categories

Date

Comments (3)

Sponsors

Vendor Events

Guessing is not a strategy: How to build decision velocity with AI and real-time data

Newsletters