Scrum Trainer

Why Your Team Does not Get to Reasons Done 7 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 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. 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. 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. Reckless Prudent Deliberate Deliberate 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. Reckless Prudent Inadvertent Inadvertent 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. 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. Change of scope during Sprint 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. Ineffective Planning 7 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 and rudimentary Product Backlog. vague 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. Infograhic by Accelright Agile acceleration! Why Your Team Does not Get to Reasons Done 7 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 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. 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. 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. Reckless Prudent Deliberate Deliberate 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. Reckless Prudent Inadvertent Inadvertent 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. 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. Change of scope during Sprint 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. Ineffective Planning 7 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 and rudimentary Product Backlog. vague 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. Infograhic by Accelright Agile acceleration!