All articles

7 Reasons Why Your Team Does not Get to Done

April 03, 2012

Many Agile and Scrum Teams struggle with very long release cycles. Sprint after Sprint, they produce work, but the work is not shippable, it is not Done.

Seven reasons lead to Teams not getting to Done

  1. Team is not cross functional
  2. Unclear or absent Definition of Done
  3. Technical debt
  4. Overworked Team
  5. Late integration
  6. Change of scope during Sprints
  7. Ineffective planning

1. Team is Not Cross Functional

Non cross functional Teams tend to struggle with getting Done by the end of their Sprints. They simply lack skills to turn the selected items to Done increments of functionality. They might lack business analysis, design, development, testing, database design or any other such skills. Team members might be unwilling to learn anything other their own well defined roles.

In many cases Teams end up with a mini waterfall within their Sprints where initially the business analysts do the analysis and clarify the requirements, then the designers design, the developers develop and if there is time left at the end the testers test the system. In case they find issues at the end, and they usually do, those remain unfixed and are pushed to following Sprints. All this undone work is pushed to the following Sprints. They just struggle to get to Done.

All the undone work leads to long, painful and expensive “stabilization phase” at the end.

2. Unclear or Absent Definition of Done

It is very hard for the Team to complete all the work during a Sprint if it lacks a clear Definition of Done. The Team might think that it is getting to “done”. The Product Owner, however, might have a very different view on this. If there is no clear agreement between the Team and the Product Owner about their Definition of Done, it leads to confusion and disagreement.

The Team might have initially defined a Done Definition, but is it complete and effective? If that Definition of Done is not taking the Team to Done, it is incomplete and ineffective. Although, the Team adheres to its “definition of done”, but the items do not get Done. The Product Owner cannot implement these items. The Team still needs to more work before that.

The Definition of Done is incomplete.

3. Technical Debt

Teams working on systems which have been developed over the years using “old engineering practices” tend to struggle to get to Done during Sprints. The “legacy” system has accumulated loads of technical debt. It lacks adequate test harness. It lacks continues integration.

A huge amount of time is required to manage the changes and make sure that no other part of the system has broken whenever changes are needed. Adding new features take enormous amount of time from the Team. Such changes are simply not manageable within the Sprints. And, the Team is not able to test the changes within a Sprint.

4. Overworked Team

Teams taking in too much work during their Sprints struggle to get their work Done. They either ignore their velocity while taking in work, or they do not keep track of velocity at all. Instead of selecting the work based on their velocity, they select the amount of work on “gut estimate” basis.

Pressure from management has a lot to do with this. Management is pushing hard to get “maximum out of the Team”. Management puts huge amount of pressure on the Team to deliver more work than the Team has capacity for. Team obliges by cutting quality and thus succeeds in “delivering more”.

The reduced quality of work catches up with Team rather soon. The Team now struggles to deliver Done work. Of course, this leads to more pressure, and more problems.

5. Late Integration

The Team is not working as self-organizing unit. Team members are working more or less as individuals. Everyone completes some piece of work. But this work is not continuously integrated. The integration is left till late. The Team finds about loads of issues once the work is integrated.

The problem exacerbates if multiple Teams are working together on one project. The Teams might get their own piece of work completed, but they do not integrate with all other Teams every Sprint. Integration is done after every few Sprints, only once a significant amount of work is completed. Big bang integration leads to loads of problems. Locating and fixing these problems takes painfully long.

6. Change of scope during Sprint

The Product Owner keeps changing her mind during the Sprint. Either the Scrum Master and the Team fail to resist the urge of the Product Owner to change her mind during the Sprint or are forced to do so by the management. The result is changed scope of the requirements that the Team selected during the Sprint Planning.

Changes in Sprint scope lead to confusion. These changes lead to wasted work that the Team has put in for the changed items. When new items are added or the existing ones are redefined, the work that Team has done on items before hand on these becomes useless. Now the Teams needs to do more work. It needs more time to do this work. It becomes harder for the Team to focus on the work and it struggles to complete their work by the end of the Sprint.

Sprint Planning and Review meetings lose their meaning if Sprint scope keeps changing. The Team stops taking the Planning Team and Reviews meetings seriously. The job of the Scrum Master gets even more difficult. Sprints become kind of a joke. Nobody takes them seriously, neither the Team nor the Product Owner.

Even though the Team and the Scrum Master are working hard, things starts to fall back to the old ways of doing work when scope kept changing and “Product Owner” and the management blamed the Team for not delivering and the Team blamed the management for keeping to change its mind. Not much gets Done during the Sprints.

7. Ineffective Planning

There is no clear agreement between The Team and the Product Owner. One big reason Teams struggle to conduct effective Sprint Planning meetings is that they do not groom their Product Backlog regularly. They go into the Planning meeting with a vague and rudimentary Product Backlog.

The items on the Product Backlog do not get clarified. Since the Sprint Planning is a time boxed event, The Team is not be able to gather the information it requires during the Sprint Planning meeting. The Product Owner might have updated the Product Backlog recently and the Team is not aware of the changes at all. The Product Owner and the Team have not worked together to groom the Product Backlog. The Team does not know the items very clearly during the Planning meeting and can not effectively get the scope clarified from the Product Owner.

And the Team, the Product Owner and the Scrum Master struggle to conclude the meeting during the given time-box also.

The Team and the Product Owner fail to agree on the acceptance criteria of the items on the Product Backlog.

Th Product owner might lack the information or might not have put in the time required to gather required information. The Team and Product Owner struggle to clearly agree on what exactly needs to be done during the next Sprint i.e. what does the Team need to do to get items to Done by the end of the Sprint. This leads to confusion and misunderstanding.

Starting the Spring with this kind of Sprint Planning does not lead to a fruitful Sprint.

Learn more about Agile, Scrum, the Scrum Master, Sprint Planning and getting to Done in our Scrum Master Certification Course.

© Faisal Mahmood

All articles