...that is usually absent in fast-paced environments.
This article is oriented to teams with mid-level proficiency in an Agile process, like mine. Impostor syndrome at work or new possibilities to deliver value?
James Shore argument (Scrum)
James Shore in 'We deliver business value ' talks about aggressively reducing velocity, while lazily increasing it after large measurements. Velocity is not a fixed quantity, especially when you're starting out estimating and measuring.
The velocity of the current iteration is a random variable V, let's say distributed as a normal centered on (for example) 8 story points and with a standard deviation of 1. This means:
- in about 60% of iterations the velocity will be between 7 and 9
- in about 90% of iterations between 6 and 10
- in about 95% of iterations between 5 and 11
What typically happens is that your team is excited with the new model, it may finish 10 story points in the first iteration; maybe you're even taking on technical debt because you're doing the simplest thing that could possibly work and you see the Product Owner is happy with it. In the second one you're facing the weight of the mass of code previously produced, and you go back to 7.
What to do now?
- you can complain with the team that they got 11 points done, they should always get them done from now on (bad idea: mistaking a realization of a random variable for the interval it really is)
- you can promise for the next iteration 8 or 9 story points, the average. However, still a bad idea since two data points are not much for an average
- introduce the concept of slack and promise 7 points, the minimum that you got.
If in the next iteration you're able to deliver less than 7 points, at least you did not overpromise. If you finish the 7 points early, you are left with a small percentage of time to use, a slack; what to do there? reduce technical debt (which is always present). While reducing technical debt, your velocity is allowed to go up later, while like James Shore says if you have a power cord attached to the socket which is just long enough to reach your machine, even an inch movement will tear it from the wall.
In order to make and most importantly maintain commitments on what you can deliver in the next two weeks (an empowerment for the team to see that they make promises and deadlines), you have to cut down on the expected velocity.
Given the assumptions of:
- a symmetrically distributed velocity or any distribution of it where median is not far from the mean
- a significant variance in what you can deliver from time to time.
if you promise to deliver its average value, you will miss the estimate half of the times. To get there, you will have to first reduce the variance of the velocity by artificially underpromising (I will get 7 points done) and only increase it after several successful realizations where you consistently experienced slack.
The whole discussion requires that Scrum is applicable in your domain, however.
Kanban is a different model, as velocity is not commonly tracked but cycle time is instead an important metric. However, slack still influences cycle time: the mathematical model here is that of queuing networks, a model for the performance of computer systems.
While the math is a bit complex, the best metaphor for slack is that of a road experiencing high traffic: the utilization of the road is increased over its normal capacity, and almost to its full one. The result is that everyone slows down and when you enter at and one of the road you get a bad time getting to the other end. The solution seems easy: either increase capacity or get less people on the road (develop and stimulated commuter trains for short to medium distances, for example).
However, speaking in game theory terms and infrastructure terms, when a new road is built it influences the demand for roads usage. What happens is that even when capacity is added (a new road or lane) it is quickly filled up by new cars, that find the non-congested road favorable with respect to taking a train.
This teaches us that unless you set up rigorous constraints on the capacity to use, your team will get to full utilization quickly; throughput will maybe increase for a bit (how many cars can get through the road) at the expense of cycle time (how much does it take for a car to get through it). It doesn't matter if you can deliver quickly, because two more stories are waiting around the corner for each you complete. Reducing technical debt helps throughput (you get things done quickly) but since the utilization is high stories often wait for a developer to be available or force him to multitask.
With Kanban, the contraints are set as the number (or the sum of points) of Work-In-Progress stories. These constraints should be, like velocity, be eagerly lowered and probably never increased unless ongoing stories are all serial tasks and free team members cannot help them get to completion.
Like for Scrum, rigorous acceptance criteria and code review should be in place to prevent finished stories from coming back, in an unsustainable model when your WIP limits are violated by stories coming back instead of entering the system.
I must stress this: looking to increase velocity or to reduce cycle time blindly is a sucker's game; the more so if there is disregard for technical quality as the increases only last up to the time where a new story impact a part of the system in technical debt.
It doesn't matter if your PM is happy; it's his job to be sad :) No matter how fast you are, there will always be more work for you: so deliver a sustainable amount of value, because it's your job to avoid destroying the system for short-term needs.