19

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?

14

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!

  • 1
    I'm working in what sounds like a similar situation to the OP. I don't think the problem is PO/Scrum Master process understanding as you seem to say. The problem is the team pushing back against the PO/Scrum Master saying "We're doing fine. We don't need your advice." when that's obviously not the case. I can tell my team "You missed 100% of the sprint goal" and they'll just reply with "No we didn't. We got 80% of the stories done." They simply don't agree with the tenants of Scrum, yet they insist on using it because they don't want to do waterfall. – NightMan Jun 6 '13 at 14:07
  • 2
    @NightMan Managing people and enforcing framework processes is called "management," and often involves "leadership." Letting a team practice an opaque, pseudo-Scrum process is neither. – Todd A. Jacobs Jun 6 '13 at 14:16
  • I agree in theory, however the organizations we work in often don't. As "project management" is defined here, I am not given responsibility or authority for enforcing process compliance, only tracking. Enforcement authority is given to the engineering department managers and directors, who are the ones that instituted and maintain the Scrum-but attitude. So all that Scrum Masters and Product Owners can do is make recommendations, which the team and their direct managers can choose to ignore. – NightMan Jun 6 '13 at 14:46
  • Thanks. Our scrum-master seems to see the role as purely meeting facilitator and issue escalator. I have asked if we are on track to make the sprint goals and the response is "we won't know until we reach the end of the sprint." I will be trying to bring in a good agile coach for a couple of months to look at wha is going wrong and see how we could improve. – NoEasyAnswers Jun 7 '13 at 19:24
  • @NighMan - Have you had any positives happen on your project, our Agile Coach did much what is said here. Embrace the principles of Agile and let the team decide how to succeed even though I am on the team and no one on the team thinks there is a problem but me. They keep measuring their happiness index which is very very high except for the product part of the team which is abysmally low. I've had to go and extend the timeline and take a verbal beating from everyone in management and more importantly now, our product is failing and will not meet revenue targets. – NoEasyAnswers Sep 3 '13 at 19:53
8

"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.

  • It has always struck me as odd that as we move to a distributed and dispersed workforce, Scrum seems to define itself ever more rigidly in the context of a bygone era. "Scrum, the Project Management Methodology that Don Draper would endorse! Dispense with the internet, mobility, nomadism, and re-enter the glorious 1950's when workers could reach out and (illicitly) touch one another!" (Just for the record, that is humor). – Mark C. Wallace Jun 6 '13 at 13:17
  • Co-located teams certainly increase communications bandwidth and are a common practice, but they are not a required framework practice for Scrum. See this discussion for various viewpoints on that issue. – Todd A. Jacobs Jun 6 '13 at 14:09
  • 1
    Thanks @CodeGnome, you're right! And I wanted to edit this question anyway so have done so accordingly. – Lunivore Jun 7 '13 at 9:15
4

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.

  • 1. I agree that it should be a team, but it's difficult when the team is only concerned with the sprints and not willing to engage on what the customer needs. I agree we fail together, somehow the team seems to be under the impression that they will succeed even if the product fails. – NoEasyAnswers Jun 7 '13 at 19:15
  • 2. We do have retrospectives and look at blocked stories. We seem to be doing OK at removing blocks but the stories are not being delivered. – NoEasyAnswers Jun 7 '13 at 19:16
  • 3. Our definition of done is all the way through QA and accepted. In general the developers still think as long as they are have delivered from dev it is good enough. They seem fine with reporting that by our definition of done we achieved 50% of the stories, but we are really done them all from dev's point of view. – NoEasyAnswers Jun 7 '13 at 19:17
  • 4. The team would like more trust. Blind trust doesn't seem to be a viable option. In this case certain individuals seem motivates and some do not, but I don't have the authority to really change or leave the team. – NoEasyAnswers Jun 7 '13 at 19:18
  • 5. Our pace is not at all constant. In fact no one seems to be able to say what it even is. I am hopeful the team will learn from the mistakes, but individuals would need to be open to learning to do so. – NoEasyAnswers Jun 7 '13 at 19:20
1

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.

0

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.

  • Thanks for the suggestion, we have actually ensured that all stories are completely identified and even have full test cases for most stories. It hasn't helped at all. At this point, I think it is a team issue and am spending the bulk of my time trying to get the right people on the project and the wrong people off. Unfortunately there is no-one on the team with the authority to actually do anything as everyone is matrixed in and the team is "self-managed" which in this case means not managed at all. – NoEasyAnswers Sep 3 '13 at 19:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.