A few years ago, I found myself in an ad hoc encounter with a number of individuals who were very angry at the current state of affairs for the highly visible agile program they were working on. Across the organization, everyone was frustrated that the program had not yet been released into the open market. Sales people were attempting to sell an application that didn't really exist. Marketing wanted to push press releases out into the public space with delivery dates. Executives were seeing what should have been a revenue generator turn into a revenue drain. Delivery managers at multiple levels couldn't figure out what to do as defects being found in higher environments vastly outnumbered new capabilities that were being delivered to those environments. Team members were looking for any way out of their current predicaments, which included leaving the organization entirely. In essence, everything was a mess.
And then I heard a comment I had to write down. Paraphrased, it was, "Team members should always want to increase velocity if they want to keep their jobs."
The comment, articulated by a senior manager at the time, summarized the current state of affairs on multiple levels. Continually increasing velocity meant that people could stay gainfully employed. What was unfortunate and somewhat disheartening at the time was the organization itself. This organization had started its agile journey approximately three years prior and had seen some success within other areas of the company. However, the success didn't resonate across the board for everyone, and the frustration was apparent.
At the time, I wasn't in a position to do much with or about the statement. However, since then, it’s given me ideas that can help agile-based practices.
Now, whether I'm working with a new or existing agile organization, I'll look for ways to introduce the concept of "velocity values" at the team, program, portfolio, and organizational levels. Like many other agile practitioners, I believe each team should develop its own characteristics and subculture. I also encourage each team to develop its own velocity values and share that information throughout the organizational structure. This can go a long way toward helping management understand how their respective teams work and can provide great insight into mentoring at both the individual and team levels going forward.
Velocity at the team level will fluctuate based on a number of different factors:
- Unplanned team member outages (sickness, emergencies, etc.)
- Planned team member outages (vacation, holidays, etc.)
- Quality and consistency of story refinement (success criteria, acceptance criteria, diagrams, etc.)
- If used, consistency of story sizing (points, T-shirt, etc.)
These factors will affect velocity on an iteration basis. Yet, even with these considerations in place, I believe that encouraging teams to discover their own velocity values can be a very positive step in shaping their own agile-based culture.
Below are some examples of velocity values I've seen and heard articulated by teams I've worked with in the past. This is by no means the best list or even a complete list. These are just examples to share based on my experiences up to this point.