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 generating 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? 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.
Comments