Velocity or No Velocity?
The boundary between product development and solutions development is shrinking, in the context of agile development. When you adopt and practice agile in it's true sense, right from coming up with a roadmap, creating a release plan, breaking the release plan into iterations / periodic releases to how you actually run an iteration or a release - there is actually not much of a different between a product development team and a solutions development team.
On this premise, I've been part of few discussions questioning the relevance and purpose of "Velocity" especially the usage of it, in the context of product development vs solution development. These discussions prompted me to take a step back and ponder over the very concept of "Velocity":
Purpose of velocity
- How long it would take for the product / solution to be completed and derive associated cost
- Raw velocity exercise is a common technique used during release planning
- How much work (in terms of story points) can be planned in an iteration
- Important metric that’s used as a continuous improvement measurement at team level
- Evaluate performance of the team / individual (or dev pair)
What happens in reality
- Teams normally fall short of planned velocity across different iterations - they either extend the release timeline or get into scope negotiations and / or prioritisation
- When used as a tool to evaluate performance, it’s normally used in negative connotation and teams tend to compromise quality or functionality to meet the planned velocity
How does the teams / management reacts if the planned velocity is not met
- Retrospectives and management meetings to discuss at length
- why team couldn’t achieve planned velocity
- how to improve velocity
- teams / individuals indulge in blame game, tries to find scape goats, how to protect one’s own interests in front of management and in effect it gets into a downward spiral and agile gets blamed in the end
Can we successfully manage a product / solution delivery without worrying about velocity?
#1: Self organised teams are expected deliver to its full potential every iteration; the collective output at the end of each iteration is the best the PO can get, without having the need to track the velocity.
- And it would only get better with time, given the team members stay longer and gain more in depth knowledge of the domain / product / solution
- Over time, the entire ecosystem of the project team, Product Owner and the management would work in tandem
#1.a: If the PO comes up with a minor change mid-iteration or a major change mid-release, he/she must provide the following critical inputs:
- business imperatives of the change
- critical business value that will be delivered by this new / change request (or lost opportunity by not picking up this change request)
- is there any major business impact due to change in release timeline
- finally, what other feature can be traded off or delayed, if timeline is a constraint
In this scenario, velocity really becomes secondary (please note: not necessarily irrelevant or insignificant) as it’s the business that’s really influencing the decision.
#2: On the contrary, a. if the team is in early stages of agile adoption and / or if the agile adoption is not by choice but by an organisational mandate OR b. agile adoption is by choice, but only in parts of the entire ecosystem, velocity becomes one of the important metrics to track and act upon.
In this talk, I plan to cover a. how to unlearn the wrong interpretations and usages of 'velocity' and make them understand and appreciate the right implementation of velocity through couple of examples.
Outline/structure of the Session
- Common symptoms of wrong implementation and usage of velocity - 10 minutes
- Scenario 1: Walk through of an example from a real-life project scenario with the wrong implementation of velocity in planning and tracking and the impact on business outcome - 15 minutes
- Scenario 2: Re-play the same scenario, setting the right environment/context and correct implementation of velocity in planning and tracking and the impact on the business outcome - 15 minutes
- Summary and Q&A - 5 minutes
This workshop will help the participants unlearn the wrong notions / usage of the 'velocity' and how to apply it in the right way and get the real benefits of this metric.
Scrum Masters, Project Managers, Product Owners, Product/Program Sponsors