Agile team missing commitments regularly and complaining about no trust

Question

I am on the product side and have an agile team that has missed every sprint commitment through the first 4 by between 40 and 60% measured by points. The team continues to say, that it is OK and that the stories were mostly done and they'll just split and move stories forward. We've already cut scope beyond what I think is really going to be possible. At this point we only have 4 sprints left to achieve a minimal product and by every calculation I make that is impossible. Our team is widely distributed with multiple vendors. I have asked for root causes of the problems and the team is pushing back hard saying that management needs to trust the team.

The team keeps just telling me this is how agile works and that I just need to continue to adjust scope and we will deliver whatever we deliver at the end.

How do we handle missed commitments in agile?

Answer 1

TL;DR

Missed estimates are not an opportunity for blame, but rather an opportunity to inspect your process and adapt it to fit the requirements of your organization. The Product Owner, the Scrum Master, and the Development Team must all work together to learn from the failed sprints.

Misconceptions

It seems like the entire Scrum Team is working under some misconceptions. Let's see if we can't clear some of them up.

[The] team...has missed every sprint commitment through the first 4 by between 40 and 60% measured by points.

Nope. Based on what you're saying, the team has missed the first four Sprint Goals by 100%. A user story is either done or not-done, and a sprint goal is either met or not met. There are no shades of gray.

The team continues to say, that it is OK and that the stories were mostly done and they'll just split and move stories forward.

Nope. As the Product Owner, it is your job to review the Product Backlog after each sprint and determine how (or even if) missed stories should be re-prioritized, and what stories should be placed at the top of the Product Backlog for the next sprint. In other words, nothing is "carried forward" unless you place it back at the top of the backlog.

I have asked for root causes of the problems and the team is pushing back hard saying that management needs to trust the team.

Nope. Blaming the team is not constructive, but asking the team to inspect the estimation or delivery process when there's clearly a process problem is extremely reasonable. In fact, it is part of your responsibility as the Product Owner to engage the Scrum Master and the Development Team in the various Scrum meetings to identify and remove roadblocks to successful project delivery.

Root Causes

I don't know what the root cause is here, but you need to involve the Scrum Master and the rest of the Scrum Team to find out. Some possibilities include:

1. The Scrum Team is doing a poor job of estimating story sizes, and taking on more than can fit into a sprint.
2. The Scrum Team as a whole may not be articulating a Sprint Goal that is both achievable and clearly defines what stories are essential to the current sprint.
3. Retrospectives or other forms of inspect-and-adapt are not being performed to identify why the process is not working.
4. The process is not respecting the time-boxed nature of the sprint or the Scrum framework.

Transparency of the process is essential to the success of any agile implementation. The team is not entitled to tell the Product Owner to mind his own business when stories accepted into a sprint are routinely incomplete at the end of each sprint.

Closer Collaboration Required

Based on what you have not said, I'd wager good money that part of the problem is that you either do not have a dedicated Scrum Master, or you do not have a Scrum Master who is able to provide the education, feedback, coaching, and process adaptation necessary for a successful Scrum implementation within your organization.

Even if that isn't the case, I certainly think you need to collaborate more effectively with the Scrum Master. Whatever deficiencies your team may or may not have, the relationship between the Product Owner and the Scrum Master is one of the most important aspects of the Scrum framework. Don't neglect it!

Answer 2

"Our team is widely distributed"

I don't have all the information, but I reckon there's your root cause, right there.

Agile methodologies don't have as much up-front analysis as traditional methods. Because of that, it's even more likely that discoveries will emerge during the sprint. For the team to react to the discoveries in a timely manner, they need to be able to communicate very easily. If they're in different offices, that isn't going to happen.

Scrum generally works best with co-located teams. At the very least, make sure that your distributed people are actually behaving like a team, trying to achieve a goal, rather than just doing "their bit".

You could try these:

• Invest in a bit more analysis. Some teams like to analyse at least one sprint ahead. Any more than that, and you risk investing in things which you won't end up delivering anyway. (Be careful if you do this that any uncertainty uncovered is addressed early, through spikes, rather than pushed to the end).

• Increase the ability of the team to communicate. Make sure everyone knows who everyone else is and what they look like. Give them a forum or channel to hang out on together so that they can talk through any problems they encounter. Get webcams.

• Rethink what the minimum product might be. If you can imagine shipping just one tiny thing, focus on that, and add more later if you have time.

• Cancel the project, if a reasonable minimum is unfeasible with its current setup and timescale.

Agile methods aren't designed to help a project, as scoped, be successful. They're designed to fail fast, so that you can change the project appropriately - or cancel it. They give you transparency and information with which to make decisions, with minimum investment having been spent.

Cancelling a project may actually be the best decision.

Answer 3

I think there are a few problems you and "the team" need to address:

1. Customer collaboration over contract negotiation
   Agile is first and foremost about collaboration. There is no "product side" and "the team". The team is everybody including you. There is no difference between the team not delivering and you not delivering. It's a collective effort and you fail or win together.
2. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
   Do you do retrospectives? If not, do them.
3. Working software is the primary measure of progress.
   If the team does not complete the stories, use smaller stories. In fact, use stories as small as you can make them whilst keeping them minimally valuable. Remember Apple's MVP.
   Do you have a "definition of done"? That should cut short any discussion on what the team commits to in a sprint planning meeting. You commit to delivering a set of story up to the quality standard specified in the definition of done. No splits.
4. Trust them or change the team or leave the team. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
5. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
   If the team can't deliver enough value it's because estimates are not reality. They are estimates, we all screw them up constantly. Accept the loss and move on.

Note: all the text in italics is from http://agilemanifesto.org/ and http://agilemanifesto.org/principles.html.

Answer 4

CodeGnome's answer for this is excellent. The only thing I'd add is to have a look at the teams velocity for an indication of what is happening. Because velocity is well defined in Scrum and easy to measure, it provides a non-contentious start for conversation which can be handy when there is a perception of a low trust environment.

Bearing in mind that velocity is the average story points for completed stories in the last few sprints, I'd start by asking:

Are you including partially completed stories in your velocity?

If so, stop! If possible, go back over previous sprints and recalculate velocity without including partially completed stories to get your real velocity and use that for future commitment.

Is velocity trending down or staying fairly consistent?

If it's staying consistent it's an indication that you're over committing and you should look at what is driving that behavior. If we did 10 points last week, 10 the week before and 10 the week before that, why did we think we'd do 20 this week?

In my experience downward trending velocity is usually an indication of technical complexity slowing the team down over time or the team feeling under pressure to under-estimate stories but your mileage may vary.

Answer 5

Sometimes this happens because of problems that developers suspect privately but don't speak publicly. Or they may not want to admit the problems even to themselves.

• They lack clarity on what the software they're creating is supposed to do
• The foundational approach to how they're solving the problem is too complex
• They're writing code in an unsustainable manner, perhaps rapidly creating complexity with no automated tests

Each of the above is a plausible, common scenario. They happen all the time and cause development to drag on longer than expected.

But in each case

• Developers might not recognize the problem
• They might recognize it but not know how to address it
• They might recognize it but not want to say it

Unfortunately, they're still not likely to say that they have no idea why they can't deliver what they thought they could. They're more likely to give a vague answer. Privately they realize the project isn't doing well and hope that

• More time will be added
• It will be cancelled
• They won't get blamed

Or they might just be in denial.

Some suggestions:

1. If someone specifically describes a problem and a way to address it, listen to them. There's no guarantee that they're right, but people who know what they're talking about tend to be more specific.

2. If someone tells you that they don't know something or understand something, listen to them. It's not easy to admit, so if someone does, they're not lying. People often feel pressured to admit to understanding what they don't. So if they say they don't understand what a feature or product does and then you explain to them that it's important because someone said it's important, they might nod their heads and move one. They still don't understand, and it will still affect the results.

What's really happening is that someone with experience is telling you that what you're directing them to build doesn't make sense and won't work the way you think it will. Do not make it your goal for them to stop questioning. That will not make the underlying problems go away. Work that doesn't make sense stalls. That might be what's happening.

2. If work is stalled because someone is waiting for another team to finish something or fulfill some request, recognize that you have a systemic problem. Even if you get that one thing done, there will be another and another. If developers need access to something, help them it get it very quickly. Don't force them to make requests to other people for things they should be able to do themselves. Don't force them to ask others to make decisions they should be able to make themselves.

3. Recognize that just because someone is a software developer with the word "Senior" in their title that there might be significant gaps in their skills. It's very common. Even if you're not a developer yourself, try to familiarize yourself with the technical practices successful development teams practice, and find out if your team applies them.

For example, you might ask your team if they write automated tests. If they say that they don't, that's a cause for concern even if they're all senior developers. A lack of automated testing results in defects, rework, and unexpected complexity, which in turn demoralizes the team.

If this is the case, your team might need coaching and help. If you can't provide it, find someone who can.

There are other answers. Why do I focus on these? Because they're the things people know but don't say, or don't know and don't want to admit not knowing. When that happens we give alternative answers that don't help.

• We're rushed
• The requirements changed
• Don't worry

When we hear answers like that we need to dig deeper and find the real ones. And in doing so always be compassionate. Not speaking up or not knowing something isn't incompetence. It means developers need someone to listen or need help learning what they don't know.

Answer 6

TL;DR: Ask if there's anything you can do to help instead of asking for root causes. This might make the team act less defensively. For example, if stories are incomplete during sprint planning, spend more time during the week grooming the backlog.

Longer answer:

I have asked for root causes of the problems and the team is pushing back hard saying that management needs to trust the team.

It seems obvious that many factors are coming into play, but may I suggest taking a different approach? Rather than asking the team for root causes, try asking the team if there is anything you as Product Owner can do to help the team achieve their goals. For example, are the requirements complete at the time when the team pulls the stories into their sprints, or does the team spend lots of time gathering requirements at the beginning of a sprint? If the latter, then there's an easy opportunity for improvement - set aside more time throughout the week for you and the team to groom the backlog so stories are complete before the team gets to sprint planning.

Answer 7

Some nice long answers which I have not had time to read completely so if is what hads been said before, I apologise.

My experience is that Sprint Goals are widely misunderstood.

A Sprint Goal should NEVER be to complete all the PBI in the Sprint Plan; that would be mini waterfall!

The PBI taken into a Sprint Backlog to meet the Sprint Goal should never be more than 60% to 65% of the Dev Teams capacity for that Sprint. Generally, most Dev Teams produce between 70% and 80%; so - hey - you get more than was committed.

BTW - as a Product person, why do you even know about your Teams velocity? It is only for the Dev Team to help with their programming.

The only thing that you should be interested in is the relative size of the PBI and how many are left to do before the end of the Increment.