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.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? 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.).
Waterfall (is) Committed?
The thought goes that since teams plan their execution thoroughly in Waterfall, to a set of documented 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. You hear this coming from nearly every executive, technology leader, and project manager who are adopting agile and struggling with forecasting project outcomes.
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 narrow in on their delivery target as they gain more understanding and collaborate with their customer. That teams can commit when they’ve made some progress and understand their delivery velocity.
In lieu of simply committing without knowing, agile teams focus on incremental delivery and incremental commitment; needing some time to truly understand the project complexity and their own capacity. Many misconstrue this prudence and transparency for a lack of commitment. But there’s also a truth to agilist’s struggling with the term.
A quick diversion to the Scrum Guide
Ken Schwaber and Scrum.org publish something called the Scrum Guide. They 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. Not let’s look at commitment from a different angle—probably the right angle.
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, trust, 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, work-life balance, 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 An Environment of Commitment…
Till next time,
Bob
Don't forget to leave your comments below.
References
- Top 10 Agile Phobias - http://www.slideshare.net/visuri/agile-phobias
- Chaos Report reference – http://www.few.vu.nl/~x/chaos/chaos.pdf
- Scrum Guide reference – http://www.scrum.org/storage/Scrum%20Update%202011.pdf
- Wonderful article on Estimation, Prediction, and Commitment – http://tynerblain.com/blog/2011/08/09/agile-estimation/
Comments