Improving the reliability of your team's commitments

 

Improve the reliability of your team's commitments

The commitment problem

How reliable is your team commitment? 

And can you actually answer this question? Many teams assume that they reliably deliver but in fact they don’t. There are plenty of reasons that may obscure the team’s visibility into their own performance levels. Here are some examples to be aware of. 

A team constantly fails to finish a significant chunk of work in the timebox but tends to attribute that to either the lack of clarity and specificity from the customer or other reasons. The unfinished effort is created as new, extension stories for the upcoming iteration and current stories are considered done in the scope the team was able to fulfill. Essentially, this is a hidden chronic roll-over to the next timebox. But technically, from the look at the team’s completion rate, it’s hard to tell that there’s a problem. A similar issue may occur when the team has delayed feedback. Late integration, or late testing or significantly delayed UAT or the delivery itself. And as a result of delayed feedback, quite a few things do not work out as designed which leads to rework, but that rework is considered as new backlog items and there’s once again, no way to tell that there’s actually a problem. 

Finding the solution

So, how to repair a problem with unreliable team commitment?

Well, first of all, the team needs to admit that the problem exists. And a first step to that is to carefully examine whether or not as a team we are delivering as expected. Try to answer this question in principle, not technically, whether the backlog items are ticked off. Because that’s usually why teams cannot see a systemic problem even though it’s in the plain sight. And generally speaking, the root cause may be intrinsic to the team or extraneous. Maybe the team is bad at estimating or maybe the team gets constantly interrupted. Or maybe it’s both. You may run a retrospective meeting on the issue of team commitment and examine it in detail. And it has to be a conversation driven by candor and critical thinking but also, constructive attitude, aiming at improvements. 

Taking preventive action

Once the problem is understood, preventive action must be taken. But before we go there, the team must define a way to measure improvement. This is a pretty contextual task. For instance, if the problem with commitment is due to the lack of size estimates of backlog items, then maybe the team needs to agree to define size estimates with all their backlog items and then start measuring the achieved scope in each timebox, based on those estimates. But if the root of the problem is in delayed feedback and rework re-appears later, the team has to be diligent about identifying those new items as “rework” and not “new work”. And then improvement is in minimizing the waste due to unnecessary rework.  
 

Building a team habit

Lastly, to solve any such problem, new team habits must emerge. This takes time. It is one thing to understand the problem, establish success measures and even run an iteration or two that will be better than previously rendered effort. But the question is: will it be sustainable? Old habits will most surely resurface many times over and that is something to watch out for. It takes months to start building a real habit, so a great deal of team’s self-discipline is needed. If you planned for some corrective action, successfully applied it within the next one or two iterations, do yourself a favor and do not rush to declare victory because the next thing you see will be deterioration of what you’ve just achieved. Your victory will emerge over time as a new powerful team habit. 

Taking action

So, at this point you probably know what to do. Diagnose the problem your team has, and take it from there, to improve reliability of team commitment.    

Alex Yakyma

Alex Yakyma is the author of “Pursuing Enterprise Outcomes” and “The Rollout”. As a consultant, Alex is helping enterprises succeed with complex challenges. Throughout his career, he operated in multi-cultural, highly distributed environments. Alex has trained a large number of change agents and leaders whose key role is to help their organizations achieve higher effectiveness at pursuing business outcomes.

Explore more content

Improving in the moment

Seeing the opportunity
Read more

Being an Agile developer

Knowledge workers are key to Agile <
Read more

Unit and Integration Testing Overview

The two important types of testing <
Read more
Contact Us