CHOW #20 – How do I handle the bottomless (scope) pit in Agile?

Krithiga is the development manager for a functional unit in Financial services organization. She’s responsible for two scrum teams from the India development centre. Within the functional unit another scrum team works from the US.

Till end of last year, the two scrum teams have always under promised and over delivered. Hence there has been lot of promises and expectations from the Business for the team to deliver. At the start of the year, to provide a better bang for the buck, one of the scrum teams were called to do a rescue project for another functional unit. This provided Krithiga a lot of great exposure. And the scrum team that was staying with the parent functional unit, subdivided into multiple streams to cater to the technical, functional and prototype like requirements as well.

All had been going well for the first two quarters of the year. But slowly what had started as a murmur, started becoming louder – that functional and compliance related requirements have been slow to deliver. The requirements that was in the backlog in the beginning of the year continue to remain in the backlog and were not being prioritized. New & urgent requirements were worked upon and backlog continues to be backlog.

When Krithiga analysed the past 2 quarters delivery, she realised that the teams have been consistently delivering around 35 story points per iteration (2 weeks) similar to last year. The team size has been the same as well.

What is going on? Have you had such a situation?

Suggested solution:

Few areas of observation that needs to be improved

When Krithiga analysed the team work for the past few months, the velocity was fairly constant. However, when she started analysing the stories that were carried over to the next iteration(s) as well as the scope creep within an iteration, she realised couple of symptoms

  • There was plenty of stops and starts that the team were doing. As the team size had reduced, the same team was responsible for multiple initiatives. With different requirements that came into a sprint, there were times where the team had to leave stories half way and re-start later. This came as a tip of the iceberg from the team as under-utilized.
  • Another finding that she found was that due to the number of streams that the team had to take up, there were silos that were forming in the team. Clearly she had agreed for the same to start with to bring in efficiency. However, the effectiveness to function as a team was lost in the process. There were deeper pockets of knowledge in different modules rather than overall systems thinking improving
  • Due to the streams that had formed, the actual value that needs to be delivered consistently was not present. For e.g. the story that had ‘database development’ was complete well before the ‘consuming services’. This was  not reflected when the velocity as a metric was analysed. However, when the value stream mapping exercise was done for a functional feature, there were many areas where teams were working on their respective streams

Now armed with this information, she realised that the team was hard working and it was more of a systemic problem that has been created and needs to have the team start seeing it the way she’s seeing. She shared this information in the next retrospective and asked the team what their opinion was. After a level of deliberation between the team, development manager, product owner and the application sponsor, they decided to take up 3 actions.

A. Self correcting team: Team needs to be self-organised and self correcting based on the goals. They would decided that they have to hold each other accountable using a structured retrospective.  Gaps were identified and solutions were brain stormed with action items and owners clearly taken up with a timeline

B. Release Planning: While the team could only correct and organize themselves so much while there is too much chaos outside. The Product manager called for a release planning exercise to provide a vision, features expected so that an adaptable plan that was balanced across functional, technical and experimental features.

One of the key elements from the Agile constructs is to establish release planning along with the team so that there is a clear and transparent plan in place for the product line. It is important to have a just enough detailing in the plan so that there is flexibility built in.

C. Product Backlog: Product owner along with the team continue to curate the backlog and spend time in the process of backlog refinement from the functional, futuristic as well as technical side.

With these three important constructs the teams are in the process of overcoming the challenges in delivery.

What do you think?

Leave a Reply

What to read next