"Iceberg" Velocity - What, why and how to solve
Iceberg velocity: work that a scrum team completes during a sprint but is not made visible, inspected and adapted to.
Visibility is the first pillar of Agile and also the most fundamental. Any empirical approach such as Scrum must take some cycle of measure/observe, model/predict, adapt. Without mechanisms to enable measurement and observation, without visibility, we end up working hard but not very smart.
I once worked with a team that had newly transitioned from a waterfall process, split up from much larger project teams. We had an approximate guess as to the team velocity, derived from measurement of the project team. There was a mix of on- and offshore developers; with the offshore team directly assigned tasks by their project manager (as you can see, this really was a team still transitioning to Agile).
The team started the sprint and were very busy. In addition to user stories that the Product Owner had prioritised, the team found bugs they included as part of completing the story. At standup, the team never raised any impediments - which every scrum master knows is a bad sign. There is no scrum team so good so as to not have impediments of any kind. At the last few standups, we switched the focus to ensuring that the longer user stories were being completed, asking directly if a given user story had any impediments against it that would prevent it from being complete as part of the sprint. The team reiterated that in-progress tasks were going to be complete as part of the sprint.
The sprint completed and the results were interesting:
- the team's velocity was only 60% of the expected velocity. This counted only stories prioritised by the Product Owner
- including the bugs hidden up until this time, the team's velocity actually exceeded expectation slightly
- these "hidden bugs" accounted for 2/3 of the total velocity.
- almost all of the in progress user stories turned out to have some issue with them and were not complete
There were dominant amounts of iceberg velocity.
Why did this occur?
At retrospective, drilling into this with the team on the surface produced a number of symptomatic impediments:
- "the tasks you gave us were too big"
- "the sprint duration is too short"
- "we need code quality to be high, so we committed to fixing every bug"
the real impediment was visibility. The Product Owner had no information to make decisions with. Bugs raised during the sprint against stories were not inspected and adapted to. Technical issues were not called out early. Large stories were left as big, opaque chunks instead of smaller chunks delivered within a sprint.
The team was driven by fear - of looking bad because bugs were discovered in code; or asking to split user stories for fear of being seen as delivering very little. This fear driven behaviour led to hidden work and thus iceberg velocity.
How do we solve this?
What the team did not realise was that the Product Owner wanted to hear impediments. Unlike the previous, waterfall based approach, changes (impediments, new scope, discovered functionality, tech debt, etc.) are constant and managed. Problems previously called "Risks" and "Issues" are not negative things to be fought and controlled, are instead seen as normal, everyday impediments the team works together to solve. Raising impediments, inspecting and then adapting to them is the most crucial lynchpin of Agile.
This is a cultural change that starts with each individual in the team.
- Product Owners can encourage this by praising and encouraging impediment reporting.
- Scrum Masters can help to foster the right environment for this to occur
- Team members will have to transform their thinking to make the everyday raising of impediments something that is seen as a characteristic of good productivity, not a bad one.
- Time and repeated positive stories about impediments that were raised and quickly fixed will help to reinforce this positive culture and head it in the right direction.
What do you think? Have you been in scrum teams with iceberg velocity before? I'd love to hear from you.