As I discussed in my last post, I’m a bit of an “odd bird” when it comes to certain aspects of coaching agile teams. For example, I like the notion of calling sprints either a success or a failure based on how the team swarmed around and delivered on their Sprint Goal(s). Many agilist’s struggle with using the word failure to connote team performance and delivery—some prefer avoiding it entirely.
Another term that causes angst within agile circles is the word commitment. Again, I personally like the word commitment. After finishing sprint planning, I like to ask a team to “commit” to their sprint goal. I like the visualization of going “hands-in” as a team—in formalizing their commitment. Sometimes teams even physically do it, which always makes me smile. I see commitment as being a bond within the team to deliver on a realistic goal that they determine as part of sprint planning. It’s a bond extended to the business and generates meaning and focus for the team. But again, I may just be odd and miss the true nature of commitment.
So, what does it mean to be committed?
Let’s start with a definition of the term. From wordreference.com I found the following definition:
the state or quality of being committed to a cause, policy, or person.
- a pledge or undertaking
- an engagement or obligation that restricts freedom of action.
Given that definition, project leadership is always looking for a team to commit to a project—to its target date/schedule, scope, and cost. They’re looking for guarantees from the team to meet the projects’ inception views towards completion targets.
On the surface that doesn’t sound bad—does it?
Waterfall (is) Committed?
Bringing it back to software development methods, there’s a perceived difference in how “committed” teams are in Waterfall variants vs. Agile variants (Scrum, Extreme Programming, Lean, Kanban, etc.). The thought goes that since teams plan their execution thoroughly in Waterfall, to a set of written requirements, that when the project begins they’re in a clear position to fully commit to the project.
They’re committed to the date, to the scope, and to the costs they’ve estimated. And if there is any “negative discovery” along the way, the team will somehow figure out how to “suck it up”, working harder and longer to meet their “commitment”. No matter what happens along the way! You’ll often hear management driving this behavior—reminding the team of their commitment and to work smarter and not harder. There might even be veiled and not so veiled threats, as to what might happen if they fail to meet their commitment.
Agile (is not) Committed?
Conversely there’s a feeling that agile teams lack commitment. This comes from the basic tenet that teams commit to projects incrementally—as they gain more understanding of the work by implementing it in small chunks. That teams honestly don’t know what the future might hold in level of difficulty or challenge in delivering their software. That committing to a fixed date and fixed scope effort, before writing one line of code, is foolhardy no matter how much pre-planning the team has done. And that it sends the wrong message of confidence to organizational leadership. Essentially the team is lying about their commitment, since they haven’t done this particular project before.
Consequently, agile teams prefer to be honest and transparent with their level of knowing or certainty when they commit…to anything. So instead, agile teams commit to many other things, for example—
- To work hard and collaboratively as a team; to stay focused on the business goal
- To creatively solve the business problem and not simply execute a rote list of tasks
- To get as much done as possible; working on the highest priority bits first, and delivering content quickly
- To not compromise on quality; meeting agreed quality standards for every delivered feature
- To work at a sustainable pace; knowing that they’re in the project for the long-haul and will make mistakes when their overextended or exhausted
- To invest in solid designs that are extensible over time; working to build products or applications that they can be proud of
- To be utterly honest and transparent with “management” on where the project stands—daily; to never mislead or promise what they can’t deliver
- To engage business stakeholders in feature delivery (acceptance) and all trade-off decisions—in real-time; to truly partner with their stakeholders
And most importantly, as they execute the project, they can narrow the completion time estimates for leadership based on the actual velocity the team has realized. So they quickly converge towards understanding the effort and towards a fixed date and fixed scope commitment.
Meaning, a solid agile team can always commit to delivering a set of the highest priority features in a fixed time-frame. It’s the low priority, less valuable, potential ‘fluff’ that they are unsure of.
A quick diversion to the Scrum Guide
Ken Schwaber and Scrum.org publish something called the Scrum Guide. Since Ken’s split from the Scrum Alliance, he’s been attempting to corner the market on the raw definition of Scrum, so he’s been pushing the guide as the defacto standard.
I guess as one of the originators of Scrum he’s earned that right. It just seems to me that an inherently emergent, and empirically driven, and continuously improving definition of Scrum can’t really be ‘owned’ by a single individual—no matter how knowledgeable or well intentioned. But that’s just me.
Moving beyond that point, Ken recently (2011) published an update to the Scrum Guide changing the language used to reflect the team posture at the conclusion of Sprint Planning. Previous language had used “commit”, as in the team would “commit” to the work they identified and planned as part of their sprint.
The updated language changed the word “commit” to the word “forecast”—here’s a copy of the language change that I copied from the FAQ on the Scrum.org site –
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.
This was one of six changes or adjustments that were made within the guide. I bring it up because it amplifies a common reaction in the agile community to the word commitment. At my core, I don’t understand the issue. It’s just a word.
Back to Waterfall vs. Agile Commitment
So are Waterfall teams more committed than their Agile counterparts. In the use of language around project targets and scope, it certainly appears so. But let’s get real. Waterfall projects rarely meet their commitments. I rarely do this, but I’ll bring out some statistics to make the point…
According to the 2009 Chaos Report examining the success rate of IT projects found that – 32% of projects succeeded, 44% were challenged or failed to meet some project goals, and 24% failed completely.
The key point here is the assumption that these were committed teams, yet literally 2/3 of the projects failed in some capacity. So I contend that commitment is simply a word.
The Real Nature of Commitment
I don’t think team commitment comes from a methodology or a planning process—particularly for highly complex, technology-driven projects, with tremendous up-side risk because your teams are creating novel solutions to your problems.
Commitment is created by many factors and I don’t pretend to be an expert on it. However, it seems to me that some of the following are crucial to support an environment of commitment—
- Teams commit to work that they have planned and estimated themselves; factoring in their true capacity and not influenced by unrealistic or artificial targets from their managers or corporate leaders
- Teams commit to a compelling leadership vision, which leads to understanding project goals, determines strategies, and ultimately measures success
- Teams commit to each other; so fostering an environment of teamwork, mutual accountability, and professionalism
- Teams commit to exciting and meaningful work; so communicate the ‘why’ and ‘impact’ of their work to inspire them
- Teams commit to solid leaders—leaders who trust them to do their jobs and who provide sufficient support for them to succeed
- Teams commit to doing good work. Work that balances competitive delivery against solid designs, creativity, and high quality
- Teams commit to providing total honesty and real-time transparency so that their leaders can make congruent adjustments; to leaders that can “handle the truth”.
Wrapping Up
So I still like to instill in agile teams that Sprints can either “Pass or Fail” depending on their efforts and behaviors and results relative to their sprint goal. And yes, I do expect a team to “Commit To” their plan to meet a sprint goal that they’ve established with their Product Owner.
I feel it’s not the word that is the problem. Instead, the question is—does the environment support the team in the areas I mention above in meeting their commitments? Point being—I don’t see commitment as a team only condition. I think the organization needs to establish a culture and an environment where commitment is supported. Where discovery and adjustment is supported, where honesty and transparency is honored, and where failure is tolerated.
If you have an environment that isn’t supportive, then yes, I can see changing the term and not using it. In that environment, then “forecast” would be a better term…as would dysfunctional. But I’m tremendously disappointed in the organization that can’t make congruent commitments across their teams and then deliver on those commitments.
So call me committed to commitment… Thanks for listening,
Bob
References
- Top 10 Agile Phobias
- Chaos Report reference
- Scrum Guide reference
- Wonderful article on Estimation, Prediction, and Commitment