For any agile-based operation, you can introduce the concept of "velocity values." Depending on the organizational culture, these values may come as monetary rewards, recognition, or other incentives. 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.
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.
Financial Rewards: Some teams have been able to create financial rewards by either keeping velocity consistent or growing velocity via some predetermined value, such as a 5 percent sprint-over-sprint increase for ten sprints. In this example, the company was fairly small (fewer than 250 people) and the majority of team members didn't move between teams frequently. Team members also did not work on multiple teams at the same time. Financial rewards were identified as part of their velocity values. Managers had tremendous input, based on their experience and knowledge, in helping to ensure that throughput wasn't overinflated in order to get an extra dollar. In this example, the company was able to integrate velocity values into team-based performance appraisals. Leaders in the organization worked tirelessly to ensure that teams knew what the financial rewards would be based on their ability to incorporate velocity values into the team, program, and portfolio culture. In this example, the rewards were based on a six-month cycle. It is important to note that this system would be for those actually doing the work; a different structure would be created for the management layer.
Nonfinancial Rewards: I was part of a project years ago that didn't distribute extra dollars to its members. This organization, a faith-based nonprofit, had its congregation at the heart of every decision it made. The velocity values were about continually meeting the needs of the congregation via the overall religious mission, values, and core beliefs. The velocity values became the continual fulfillment of services for the congregation. The members of the community were constantly involved with the teams at the project, program, and portfolio levels. An interesting result was from the member community. Individuals were willing to make the time commitment to the organization that was providing the value to them. This cultural aspect, in turn, motivated the teams to continually improve their output, as it was for the betterment of everyone.
Convertible Rewards: One option I've seen, although not quite as often as I would have thought, is convertible rewards. These are usually in the form of “reward points” that can be allocated at the individual or team level. The conversion options are as varied as the organizations themselves but often include things like gift cards, prizes, or even money donated to charities. Managers again play an integral part in ensuring that story points are not overinflated so that velocity could look better.
Bragging Rights: Let's face it: Most of us have values that go much deeper than the almighty dollar. I saw one organization where the teams created an atmosphere of intrateam competition to see who was the best in velocity growth. Yes, the team sizes were different and the type of work they did was different. However, this was a team-based velocity value that really got management to take notice. Ultimately, this game also resonated deeply with the company values and corporate culture. In this example, managers assembled in their own collaboration circles every three months to review and encourage the competition among the teams. The surprise reward for the winners was extra days of paid vacation—as well as bragging rights, of course.
Member Value Recognition: In another example, a division within the company brought a percentage of its current customers to the headquarters to be part of the product demonstration process. The teams formed personal and professional relationships with their customers at a higher level than what the division experienced in the past. Teams in this division had a velocity value of capturing the list of value-based statements that came from the customers during the demonstration. They encouraged themselves to begin every value statement with, "This good thing happens when we get this functionality to market . . ."
Capabilities Released: In yet another example, velocity values were linked to the primary capabilities that were released into the open market. The team in this case was always driving to capabilities that could be released either individually or as a group. For example, at the beginning of the planning cycle, fifteen primary capabilities were determined to be of value for the primary customer base. The value, in this case, was based on delivery. The delivery dates were not fixed so that the capabilities could be. In addition, key members of a product advisory group were periodically involved with the teams delivering the capabilities so that the highest value could be derived during the release.
There are many other velocity values teams can create, and I would not consider any value to be any better than any other. Other values can be centered around things like pairing, peering, quality, or collaboration. Also note that your teams may establish and create multiple velocity values and that these values will evolve as the teams mature.
If your teams are just starting their agile journey, then take some time to talk about and list some team-based velocity values. These values should be visible publicly so that everyone can understand the team dynamics better.
If your teams have been agile for a while, then introducing a concept like this may help them take their skill sets and mindsets to another level. Encouraging the discussion and continual inspection of velocity values may give you some valuable insights into the teams your company is building.
User Comments
I disagree strongly with the intent of this article. As agile practitioners, we should strive to ensure that team velocity is never used as a measurement of team performance (i.e. - increasing on a sprint by sprint basis).
Team velocity should only be used as a tool to both give the team insight into their iteration capability, and to aid management in short and long range planning, provided that the backlog is adequately stacked with estimated stories.
Team velocity can easily be "gamed" to increase sprint to sprint - just have the team bump up their SP estimating. No management "oversight" can prevent this, no matter what the author claims.
Heck, if I served as a Scrum Master for a team that was given the incentive to increase their velocity, I would just propose to the team that they double their SP estimates. The fact that these numbers can be manipulated like this should clearly indicate that they should not be tied to any incentive-based program.
One final thought is whether the author has read any scientific studies around incentive-based performance, because the science proves that if cognitive effort is involved, incentive-based performance is consistently worse than the performance of those that are not incentivized (Read Daniel Pink!).
Hi Tim,
I have to disagree with your response. In an attempt to increase velocity by simply bumping up the estimation will not cause velocity (i.e. performance) to increase. Changing the estimation size without increasing velocity will simply cause less items to be worked on in the Sprint backlog.
I do agree however with you that metrics alone are no indication of success for increasing velocity but only one of many areas to increase team performance. Organizationa culture, governance play an important role, and most importantly simply lving up to the scrum values will gurantee success. What you are suggesting also provides no room for continuous improvement.
Thank you Johann for your reply. Perhaps my post was unclear, so let me try to state my view a little more clearly and concisely:
Team improvement is paramount,. There are many disciplines and methods that may improve productivity and communication. Some improvements will increase team velocity, some improvements may not. Still, the focus should always be on improving (12th agile principle).
Velocity should never be discussed or published outside of the team or immediate stakeholders.
Velocity comparisons should never be made between teams.
Velocity should never be the focus of any analysis around team performance.
Velocity is a "reflective metric", representing past team productivity, and may be used as one of many tools supporting future estimation. Never should the goal of any organization be defined as "improving team velocity".
Improve team productivity? Yes. Improve internal and external team communication? Yes. Improve velocity? No.
There's a fundamental misunderstanding in the executive's original comment: "Team members should always want to increase velocity if they want to keep their jobs."
Velocity is a backward-looking statistical measure. If anyone, particularly an executive, starts to try "managing the velocity" and using it as a metric to set organizational goals, they start to distort the system. Velocity is meant only to be a tool for awareness and discussion. See http://www.infoq.com/presentations/agile-quality-canary-coalmine
Not only that, there's a lot of dysfunctional organizational behaviour around metric-driven goals. The book Drive goes into a lot of examples.
Once you turn a metric into a goal you have destroyed it as a metric.
Velocity is an average number that should ONLY be used for planning, never as a target number to hit in a sprint.