Velocity is evil, predictability is divine

When an immovable object meets an irresistible force, things can get messy…

In Software Development, leadership requires transparency into when their plans are going to be delivered. Their workforce wants to be autonomous, work on impactful things, be appreciated, and not made to feel like they are a conveyor belt. Are these two goals forever at conflict, or are they reconcilable?

I believe they both can be met, though it takes work. Which is why this turned out to be my longest post yet. I promise, if you struggle with this, it's worth the 7 minutes.

I am not naive: More often than not, there’s tension and mistrust in this context.

My focus is on how to balance leaderships' justifiable need to understand productivity with the teams' human need to be in control of their destiny while being valued for expertise, input and impact.

‘You can’t improve what you don’t measure.’

This famous quote attributed to Peter Drucker is often used by evil management as the reason for implementing some measure of velocity on software development teams.

It’s not so common knowledge that Mr. Drucker never said this because he knew it didn’t apply to everything.

According to the Drucker Institute itself, here is how he caveats it (paraphrased - full source linked below):

Most important is the relationship between people, the development of mutual confidence, of a community. 

These are key functions, but cannot be easily measured or defined.

When it comes to people, not everything that goes into being effective can be captured by some kind of metric: 

  Not enthusiasm.

  Not alignment with an organization’s mission. 

  Not the willingness to go above and beyond.        

Indeed: it’s about measuring people.

I’ll take it one step further for our industry: in software development, implementing a measure of velocity without regard for these nuances will not give you a reliable velocity: and worse, it will damage progress towards attaining all those beautiful elements of an effective, happy team Drucker talks about.

Back to the issue at hand: Given the above problems, how can any development or cross functional team arrive at a reasonable estimate, if measuring velocity is evil and wrong??

The answer: Recognize that measuring productivity is quite different from measuring velocity.?Any measurement of “productivity” should be internal to the team only, with the goal of providing a reasonably accurate time estimate of when value delivery happens.?

Any measurement of “productivity” should be internal to the team only, with the goal of providing a reasonably accurate time estimate of when value delivery happens.?

In other words, predictability. So a team needs some measure of productivity, so they should decide what fits them best. Here are some options:

• Story points: the most common measure. Use your Googling skills if you’re not familiar. Of course they have a downside, and opponents will point out the clear gamability and inconsistency over time. Also, it typically takes a stable team at least two months to establish a baseline.
• Time estimates: second most common. The original idea for this concept prior to minting the agile manifesto was “Ideal dev days” which was meant to show how much work a developer could do in a day, i.e. in 3-4 hrs. It was abandoned as a recommendation probably because? it smells of oversimplification and conveyor belt mentality. Today. some teams will estimate work in increments of “dev weeks” or the like.?
• Number of submitted PR’s: this can work well for operational or large teams when the "average pull request" is meaningful.?
• T-Shirt sizing: can work for smaller deliverables, but is challenging when estimating large initiatives. When you find yourself needing XXXL and X2L it's probably time for something more useable.
• Gummy bears! You can choose to have some fun and use an abstract measure. In the early days of Agile, gummy bears were used. Since then, it developed into something like different colored marbles, or fruits. This can work just fine, as long as they mean something to the team, and it doesn't focus on emphasizing the fallacy of measuring velocity.

?? Pro tip: A not insignificant second benefit of understanding your team’s productivity using any of these methods, is that you have a data-driven way to answer the very difficult and critical question of “how busy are you?” as a team. I.e., how long would it take for you to complete your backlog? If you intend to request more people to be added to your team you will be asked to provide solid reasons, and this is as solid as it gets.?

Still with me? OK.

Let’s say you have your way of measuring how many story points (or melons) your team can deliver in a given period.

The next, also not insignificant step, is to understand and break down the request so you can map it to your way of measuring output.

I do not mean grooming or actually defining every deliverable: This is, after all, an estimation.

You should increase the level of understanding, though not all the way.

An analogy of descending the plane a bit further, so you can see more detail: Just don’t come in for a landing yet.?

Here are some actionable steps you can take with your team to break requests down and start creating some predictability.

1. The lucky way: It is possible that the team contains some experienced folks who have done similar things before who can “T-shirt size” the request into Small/Medium/Large if those parameters are clear. It’s a great starting point, and if this is the case you could skip right to the second part below.
2. If you're not lucky, break it down. Gather the right SME’s together and talk through the requirements, and go end-to-end. If you’re so inclined, a Work Breakdown Structure is a good model for this, but you have to resist the urge to go too deep (that’s something for another post). There will always be questions or decisions that need to be made, but for the purposes of estimation, focus on those that influence scope.
3. Explicitly exclude those items that the team considers out of scope. This may cause a nice, pro-active conversation with the stakeholders about said scope, which is precisely what you want. Better now than when the goal is missed or requirements change.?
4. Record the questions that need to be asked of the requestors for clarification before finalizing your estimate. Also, record any assumptions you made, and share those.
5. Identify dependencies on other services, platforms, communications or the like. It doesn't really affect your team's part in the estimate but in Program Management land, this is where the critical path is formed, and similar sessions may be held with the dependent teams.
6. Map the pieces to your way of measuring. Once all elements of the request scope are understood, the team can use their own methodology to break them down into actionable pieces and arrive at a meaningful estimate.

Now for the Program Management bit.

Once you have get this first semblance of an estimate, you need to understand and apply some variables.

The? following questions address not-so-unusual circumstances and gather insight into how it's all going to go down: I like to call it predicting the future:

1. If the estimate came from developers: They are often optimists, who will benefit from protecting them from themselves (caveat: after doing this for many years, no developer has ever told me this is wrong). So, either consider their history of estimating, or ask them how accurate they usually are. Then add 10 - 25% to the estimate.
2. How present are distractions? Are there operational or other support responsibilities, or tech debt that could take the focus away? How big and volatile an element of bandwidth is it? Add 0 - 33% of the original estimate.?
3. How skilled is the team at the tasks they are being asked to do? Is it a comfort zone, i.e. known technologies with experienced developers, or is it relatively new? Add at least 10 - 25%.
4. How efficient do you expect the team to be? I.e. How stable is the team, what does retention look like, is there turnover, maternity leave, vacations or re-orgs in the timeline?? Add 0 - ?%
5. How known is the unknown? I know this sounds like nonsense to the uninitiated, so consider this example: An internal service is to be moved to the cloud., and of the developers have ever worked on any cloud-based platform. In this example, the unknowns are huge. You might even decide not to provide an estimate at all until you investigate. Otherwise, add 50 - 100% (seriously).?

The key word here is still: “estimate”. Software development is inherently a creative process and impossible to predict with an infallible degree of accuracy. That is not a reason to say you should take the attitude it can’t be done, though.?

In the end, if these principles are applied well, both sides get what they want: Leadership gets a productive team with high engagement, expertise and retention, while the team members are respected and control of their work environment. This is not the norm: it takes real work but will (gummy) bear exceptional results which are as close to divine as you can expect in a work environment.

Supporting links

The Drucker Institute: Measurement Myopia

Elsevier/Kai Peterson: Measuring and predicting software productivity

Agile Alliance: Velocity in Agile, and Story points

Bonus:?

The Infinity from Nothing paradox: the Immovable Object meets the Irresistible Force