Tuesday, November 24, 2015

Agile at Scale – What to Do When a Sprint is Cancelled?

At one of the lowest levels of Scrum development, you have Sprints. If you are combining Scrum with Kanban or have another iterative and incremental development, then you are likely to have iterations. In either case, with a small team and one Sprint backlog, it is easy to manage the dependencies, have the needed integration and deliver. When you have multiple sprints (iterations) running in multiple teams, the complexity increases in managing dependencies and delivery. 

In such case, synchronization of Sprints is a practice for Agile development at scale.  In place of overlapping Sprints, it is advisable to have synchronized Sprints for good collaboration and dependency management. Now, what happens when one of the Sprints - synchronized with same length or nested with different length – gets cancelled?

Sprint getting cancelled is rare, but it might happen, e.g., when the goal of the Sprint is no longer relevant.

Say there are Sprints of different lengths with a cancelled Sprint for one of the teams. The situation looks like this as shown below (Figure - 1). I have 3 teams – Team 1, Team 2, and Team 3 - running Sprints. The Sprint lengths are different. For Team 2 and Team 3, it is nested inside the Sprint for Team 1. But, Sprint 1 for Team 2 has been cancelled for certain reason.

Figure - 1
So, what can be done in such a case? Will the team immediately start the next Sprint? If not, will the team seat idly? 

Some suggest that add on the days leftover from the current Sprint to the next Sprint and start off, which is like the one shown below (Figure - 2). As shown below, Sprint 2 of Team 2 has been extended to start some days before. Note that I have shown first Sprint getting cancelled. It may be other Sprint in the development cycle.

Figure - 2
In my view, it is not a good idea. There are certain reasons which I will outline.

First, Sprint cancellation is not an easy thing to digest by the team members. Let the team find out what went wrong or if by external reasons, what could have been done better. That takes some time. Starting off immediately, does not help address this case. In fact, I would suggest to have a small retrospective of what went wrong and how it can be avoided. 

Second, the changes that you have made to the codebase while running the Sprints have to be commented out or removed or placed into separate classes or packages, as they may not used now. The branches that been created to have the code checked in and tested have to be tagged as such. If they have merged to the main branch (if there are dependencies with other team), have also to be addressed. These take time. 

Third, though I am saying that Sprints can be of different length in different teams, I am also suggesting for the same team keep the team length same. Going forward, for every Sprint, I would like to see improvement in terms of delivery, e.g., by checking on the velocity. This is not possible if we change the length for the same team. 

Fourth, Sprint length should be kept at same length (at least for 1 or 2 quarters) because it helps in reaching a high productive state. If you keep on changing the lengths, it breaks the rhythm

Fifth, think of distributed environment where Sprints are running. How can the next Sprint immediately start off, if the previous Sprint is cancelled? It is just not practical.

After the cancelled Sprint, start the next Sprint as depicted below (Figure - 3). Have the next Sprint as scheduled earlier, which you would have done in your release planning. 

Figure - 3
So, what the team will do for the time left? There are many things that can be done, e.g., doing a small retrospective, Product Backlog refinement, technical debt payoff, making the changes to the branches etc.

You may also like:

No comments:

Post a Comment

Any comment is welcome - comments, review or criticism. But off-topic, abusive, defamatory comments will be moderated or may be removed.