How we Improved a Team’s Ability to Plan & Deliver by Changing These 3 Practices
On a recent client engagement, we were asked to coach a team who were experiencing several problems with planning and delivery. Neither the management or the team had much confidence in their plans and what would be delivered, resulting in an atmosphere that was tense and painful.
We kick off most of our engagements with a couple of weeks observation, as this allows us to fully align with our client’s culture, leading to better outcomes and results.
After two weeks of team observation, we determined that the largest indication that changes were needed was the team’s very unstable velocity.
Velocity is the amount of stuff a team is able to get out of the door in a given time period. Usually we take an average from the previous 3 sprints to plan for the next. If there is huge variation between sprints then this is an unreliable measure. Planning and expectation management is difficult as a result(*).
This unstable velocity was a visible indication as to why the team and management were experiencing so much pain. Through further investigation there were three surprising areas that were impacting the velocity and ultimately causing so much turmoil.
Velocity is a common indicator we look at when starting with teams. Usually we see velocity affected by technical issues, poor understanding of the requirements or lack of trust and communication between team members. However, all these attributes were fairly strong for this team, although there is always room for improvement. The real areas that were affecting velocity were quite simple concepts that had been forgotten over the couple of years “doing Scrum”:
- Management expecting 100% capacity every sprint
- Incremental not iterative delivery
- Use of Immature Estimation Practices to Size Work
Let’s explore each of these a little.
Management expecting 100% capacity every sprint
The department had recently moved to using the Scaled Agile Framework (SAFe). As a result the team had been required to present plans for the next 4 sprints to the wider department. This was coupled with a culture where the management pushed work onto the teams. The department had started with some planning based on capacity but as a whole had not understood the need for some headroom in the plans. They believed that by doing planning for an 8 week period variability could be eliminated so there was no need for a “buffer”.
In reality, sprint plans made for a single two week sprint are usually inaccurate by a certain percentage because:
- teams will miss technical details,
- story details may emerge as development starts,
- production issues may reduce the availability of team members.
What we did:
The belief that setting up plans for 4 sprints and that these plans will require no rework is a common misunderstanding of SAFe. However, through the process of coaching and retrospectives we realised that this behaviour was present before moving to SAFe. For instance it was common practice to fill up sprints with as much work as possible, leaving no room for bugs, requirement changes or emerging ideas. By expecting a 4 sprint plan SAFe had amplified the issue. During a retrospective the team expressed the need for help in communicating the pressure they were feeling to the wider department.
After communicating with the Scrum Masters (SMs) from other teams, it quickly became apparent that this problem wasn’t limited to just one team. The management team were also aware that something needed to change. To rectify this, we showed the teams that SAFe suggests that teams plan for about 80% of their available capacity per sprint. Because overheads can change and will depend on the context for the team, 80% is just a number to start from. This isn’t a SAFe specific approach, but a sound method for any team.
This resulted in an agreement between the SMs and managers that the management would no longer push the teams to fill their sprints to maximum capacity. In fact they went further and the SMs asked for mutual accountability that the teams do not overload themselves.
Incremental not iterative delivery
When the team were in the early days of their Scrum journey they had focused more on the mechanics of the framework. During this time they had been introduced to user stories, but they had not really been coached on how good user stories foster iterative delivery. Because the Product Owner (PO) had been brought in at a later date, after the initial training, they weren’t aligned to the way of working and did not know how to create a backlog of stories. Subsequently the backlog read like an extended technical task list. Their requirements were still captured in a large document that wasn’t easily accessible or shared with the team.
The result of this technical breakdown of work was that the team were using each sprint to build various components of the solution, rarely delivering end-to-end solutions.
- Infrequent integration
- Infrequent end-to-end testing
- Infrequent opportunities for PO feedback
One interesting strength, however, was the PO’s excellent communication of the product’s “what” and “why”. Consequently, the team had a strong understanding of the vision and specific goals for the feature they were working on. This is fundamental to a collective understanding when building a solution, without this it is very difficult for a team to collaborate on work.
What we did:
- Team Coaching
- PO Coaching
- Regular backlog refinement sessions
- User story training
- Story writing sessions
This resulted in a team that understood how better user stories can help towards an iterative delivery. Also the PO was now comfortable not writing large requirements specs, and they continued the great conversations they had with the team, but with the added bonus that they all had some useful anchors to frame each discussion.
Ultimately the team started demonstrating small end to end slices of working product each sprint because they had started specifying the work in the right way. They were also getting feedback from their PO much more frequently. Plus, the transparency around what was planned and what was completed brought a new level of confidence in the team.
Use of Immature Estimation Practices to Size Work
Another concept that the team had struggled with was relative estimation. This is the idea that complex work cannot be estimated accurately using absolute units of time, but instead by comparison of items of varying difficulty using an abstract metric. We showed the team that relative estimation needs to take into account more than just time.
The primary problem was that the team were failing to consider the risk and complexity of the tasks at hand by focusing on trying to accurately estimate time. In the real world knowledge work such as software development is dynamic and complex, things rarely work perfectly. Additionally, they would frequently seek clarification on what points equated to, this meant they lacked a common baseline that they could all anchor to.
What we did:
We reintroduced the concept of relative estimation. One method we use that has the most impact is the use of metaphors, for example the relative heights of buildings in the London skyline. This method enables a more empirical approach to the backlog estimation. We also introduced techniques such as affinity estimating to quickly re-estimate the backlog, and planning poker to collaboratively size work.
With a consistent abstract measure for the size of the work and a continuous review process in place, the team were able to better understand what they could commit to in a sprint and within the longer period required by the SAFe framework.
We identified that the team’s unstable velocity and variability was affecting their ability to plan and deliver. Through retrospectives and coaching we identified the three main areas of focus that needed improvement in order to stabilise the velocity. By working with the team through training and coaching we successfully improved their ability to consistently plan work and deliver.
Please note: This was just one team whose problems manifested as unstable velocity. These three areas may not be a problem for other teams. Please do not take these approaches as a silver bullet to solve issues within your context.
If your teams are experiencing planning and delivery issues, or the problems talked about in this case study resonate with you, please talk to the AWA Team about how we can help you.
* The concept of velocity is a useful tool for any team, but it should not be viewed as the only objective. It is simply a measure of output that helps us understand how work flows. The overall aim for any team is to focus on maximising outcome while minimising output.