The idea of staggering a sprint comes from the idea that we are working with a sequential process where the first task, usually done by one group, has to be done before the tasks of another group. The first group, usually Architecture or UX, don’t feel they can complete their tasks within the same sprint as the development team due to time pressure. The same thing happens with the Development team and the Testing Team.
If the two groups try to work in the same sprint, then the second group has little to do at the beginning of the sprint, and the firstgroup has little to do at the end.
A common solution is to split the two groups into two sprints.
This is very similar to the problem of having specialisms in a team and the same effects can be seen on an individual level, resulting in nothing ever getting DONE in a sprint.
There are many problems with this approach. These are:
- Cycle time is more than doubled
- Problems arising in the second part usually involve some rework or change in the first part.
- Reduction in flexibility for the Product Owner
- Lack of ownership of the true product
- Reduction in transparency and loss of work
- Bottlenecks and co-ordination are increased
Cycle time is more than doubled
The cycle time is the length of idea from concept to feedback from the customer. Feedback may be explicit in the form of written or verbal feedback, or it may be implicit in the form of increased or decreased traffic or sales.
Increasing the cycle time reduces the number of times you can test hypothesis and guide the product to being successful.
From the Lean Start Up we know that Cash is not King(1). The formula for success when tackling complex adaptive software development is the number of times or iterations we can complete before the money runs out. Increasing the duration of the cycle, reduces the number of iterations and hence feedback. Thus reducing our chance of success.
In our staggered sprint model, we have not only doubled the cycle time, we have increased it much more. This is because problems arising in the second sprint usually involve some rework or change from the group who completed the first sprint.
Problems arising in the second part usually involve some rework or change in the first part.
In our staggered sprint model, if problems arise in the second sprint, then it usually requires changes to be made by the team in the first part of the process. Unfortunately, those people are now working on something else.
If we make them fix the problems, then they will have to do unplanned work within their sprint. Thus putting their sprint goal and commitment at risk. If the team puts the items on their backlog, then the work the cycle time increases even further. The work is now on hold and no value has been created for any work done.
This can extend the cycle time over many sprints.
During this time. The priorities may have changed. This gives a huge reduction in flexibility for the PO.
Reduction in flexibility for the Product Owner
The faster the environment changes, the more competitive the environment, the more uncertain we are about our solution, and the more innovative we want to be, means we need shorter cycle times to succeed.
The shorter cycle time allows us to change direction, start something new, or abandon ideas quickly that are not working.
Extending the cycle time over multiple sprints puts the PO in a very difficult position. The PO now has an impossible choice or a no-win situation should they want to change priority.
If work is unfinished in the system. I.e. it is sitting in a repository, or on someone’s desk, and not in front a customer, that work is overhead. The sprint boundary is the place where the PO can change direction. That is the power of iterative development. It is what allows us to succeed in a complex adaptive environment. If the work extends beyond the sprint boundary, and the PO wants to change direction, they now have two options:
- Continue with the existing low priority work until it is finished
- Abandon the lower priority work and start the new, which will waste the effort spent so far.
Neither are good options.
Responsibility for making sure this does not happen must reside with the entire product team, not just the people in the second part of the process. Staggering sprints reduces transparency and reduces ‘product ownership’.
Lack of ownership of the true product
If the team in the first part of the process hands off to the team in the second part of the process, but feedback only occurs when the second part is complete and deployed, then the first team is one more step removed from being responsible for the success of the final working solution.
This has historically led to lack of ‘entire product’ ownership by all members of the product team. The side effect of this, is that the team who is second in the sequential process and who now feel overly responsible, will make whatever changes they see fit to ensure the product goes out on time. In the case of Development working in the second part of the sprint and Architecture or UX in the first sprint, the guidance and governance will be reduced if not by-passed altogether. This removes the original value proposition of having 2 sprints in the first place.
All product team members must be continually and transparently accountable for the success of working and consumable solutions at all times.
The hand off between teams may also result in a lack and transparency and loss of work.
Reduction in transparency and loss of work
In any hand off between two groups, there is inevitably information loss. This occurs because the people closest to the work gather and gain a huge amount of knowledge about the problem domain and not all of this information can be transferred. It is tacit knowledge (2).
Bottlenecks and co-ordination are increased
In addition to this loss of knowledge, it is unlikely that the two teams produce exactly the right amount of work to balance out the output from the first team to the capacity of the second team. If too much work is created by the first team, this creates a backlog of work or a queue for the second team. This work is waste and its cycle time is of unknown duration.
Increasing queue size has a geometric relationship to capacity utilization. Capacity utilization is the largest factor in creating dependency problems, waste, bloating in staff numbers, reduction in quality and a whole host of other system problems.(3)
This type of queue is to be avoided wherever possible.
How to overcome this staggering problem
Single sprint with cross functional teams
The first and necessary step is to have one sprint. There is only one sprint per product. If the number of people allow it, i.e. there are less than 9, then there should be one team. If there are more than 9, there more teams are required but each team has all the people in it to create something valuable.
This is the first step. Without this, you cannot solve this problem. You must dissolve the silo teams and work as cross function teams. This is basic Scrum.
Knowledge transfer
If all we do is create one team, (or set of cross functional teams), we are back with the problem that the two specialists have nothing to do at the beginning or end of the sprint depending on which part of the process they work on.
We must move away from the idea of sequential process. In the following diagram we can see how the transition might look.
In stage 1, we see the traditional waterfall approach. In stage 2, we see the problem we are trying to overcome where we maintain silo specialists in the team. In stage 3, we see specialisms partially merge and different disciplines are utilized continuously and interchangeably on each story.
To achieve this, we must transfer some of the knowledge specialism across the team. Developers must be partially testers. UX people must partially test or code, same with architects.
We must create the environment that is conducive for team members to become generalizing specialists or T-Shaped people. This is the most effective way to create flow through the team and optimize the team’s ability to complete all work in a single sprint.
Techniques
The first challenge is that the specialists in the first part of the process often don’t feel there is enough time to produce something of quality. To overcome this, there are two changes that need to be made. The first is a mind-set change and the second is collaborative working.
The mindset change is that the work being done should be good enough for now and safe enough to try. Lightweight modelling techniques allow teams to model quickly architectural and UX guidance. The value in these models are in the making of them. For guidance and further learning in these techniques I recommend reviewing Scott Ambler’s work from the Disciplined Agile framework(4). Scott often runs courses and these are highly recommended and include a masterclass with questions and answers(5).
Collaborative working
Making lightweight models, usually around a whiteboard allows all the members of the team to gain the core knowledge of the problem without loss of tacit knowledge in handoff transfer.
When everyone understands and works together on the core problem, then solutions are more likely to be right first time and when problems do arise, whomever is working on the problem at that time is more likely to be able to fix it on their own, thus reducing or removing internal queues.
Once work is underway, each team member, across specialization can pair with another so further swap knowledge and move towards the T-Shaped person. This allows the team to fill the gaps at each end of the sprint by working on items that are outside of the main specialization, but in which the team member has a broad but shallow knowledge.
Over time, the team will then be able to eliminate staggering and work complete every story every sprint.
References
- Ries, Eric. Cash is not king. startup lessons learned. [Online]
- Wikipedia. Tacit Knowledge. [Online]
- How to gain 98 percent improvement without hiring anyone. Adventures with Agile. [Online]
