In my last blog I had shared the first of the two common patterns that I have encountered in my Agile Coaching experience related to the cadence of the team, here I am sharing the second one.
The scrum team has a well-defined backlog and good clarity on what is expected in the release. They start their iterations and make good progress, delivering chunks of potentially shipable increments every iteration. They seek and get feedback from the PO, take in their stride any new requirements that are discovered or changes that are needed. They do their retrospectives and improve on how they are work as a team, adopting new practices. The team is making good progress at a steady pace.
When they near the end of the iterations the team slows down in-ordinately, for a variety of reasons:
- Often there are other scrum teams working on different features for the same release. A good amount of integration happens through the iterations, the planned short hardening iteration gets stretched, due to poor co-ordination during the initial iterations.
- At times the team is unable to deploy their code as they are unable to test in production environment, or the production environment is not ready for deployment.
- The customer / users not being in a state to accept and use the product is also a reason at times.
The above requires the team, product owner and users to make some drastic changes to deal with these issues. A Release Retrospective done in the right spirit with the right participants will put the team on the right track for the next release. But I want to talk about something else here.
The point I want to highlight here is the break in the cadence of the team at this stage, which if managed well can make a lot of difference. This phase can be turned more productive and team can exit this phase quickly.
A common occurrence at this stage is the lack of planning or slackening in the planning. The team feels that this is not a regular iteration, thinks that the quantum of work is much less than what they do in an iteration and the nature of work is different than what typically happens in an iteration. This feeling results in them not doing due diligence.
All of these may be true in parts or in full, but planning diligently for the “work” at this stage and creating an appropriate matched “iteration backlog” has helped the teams. Here are a few typical possibilities:
- The work that needs to be done can be accomplished by a subset of the team.
- At times the team may not be able to start all of work, they may have to wait, as there may be dependencies on other teams, stakeholders, etc
- An opportunity for the team member to enhance skills – training, cross-skilling.
The team along with the Product Owner can now decide on adding items that are of value to this iteration backlog – this could be improvements, pending technical stories and/or ground work for upcoming releases. If nothing relevant can be added to the backlog, the team members can focus on their skill enhancement, should not miss or fritter away this opportunity.
Alternately, in a multi-team situation, they could focus on expediting the dependencies by helping other teams. This will be the case when they discover that they have to wait for other teams to finish up items. In case the team itself is having a large iteration backlog to start with, they can seek help from other teams. This will help in cross-skilling.
All of this helps surface the issues as they exist and make it visible and transparent to all. This alone is of great benefit as the team and stakeholders become more aware and deal with these in a responsible manner.
To summarize diligent planning (or not slackening the planning) for iterations that occur towards the end of the release will help the team maintain a steady pace in delivering value to customer, resulting in a higher sense of accomplishment/satisfaction for the team.
You could also look up SAFe Innovation and Planning Sprint, which uses a ‘develop on cadence and release on demand’ approach.
