Need for speed

Time is money

With the ever-increasing rate of change, there seems to be a craze for measuring and improving velocity for agile teams. After all many switched for the promise of "twice the work in half the time" in the first place.

Here is some empirical data about how quickly can a unit of work be done and whether or not that “velocity” changes with the duration over which the work needs to be done. Although machines can cover repetitive work at constant velocity, human beings cannot, based on this empirical data. In the following diagram, focus on the nature of the information (i.e. curve type, relative values) rather than absolute values (as the data is averaged over technologies, periods in time, team sizes and industries/domains).

Time value of money

What this shows is that work over small duration can be done comparatively quicker by humans – this could be because new things are exciting/motivating. It could also be because if something is for a shorter time horizon, quality may have been compromised as the consequence of poor quality disappears quickly (think about paper plates vs fine china, or use-and-throw vs pass-down-generation). However, as soon as the work horizon tends to expand, things seem to take longer and longer. Again this could be because work becomes boring or more time is invested in ensuring long term durability of the end result.

There is an additional complexity in software when working on the same element (i.e. a product or platform that is enhanced over years and years) – technical debt starts to accumulate. New changes become harder to implement, until the platform is classified as legacy and a replacement is brought in place. Most likely with a significant paradigm shift.

Project vs product/platform

The following diagram gives you an overview of where projects (i.e. work with fixed scope limited in time) vs products/platforms (i.e. work with an open ended scope and time) live on this spectrum:

As you can see, projects have a shorter horizon of investment in the result, a product/platform has a longer horizon. In a project context, you are incentivized to meet a certain point-objective (i.e. at end of project) whereas products need longer term commitment and investment.

Houston, we have a problem

The problem, as-is evident in the pictorial view, is that management looks at theoretical benchmarks over one set of conditions and applies the benchmark under a different set of conditions – then they are frustrated why agile is not faster.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. - Agile Manifesto

The general observation is that a team’s average velocity will depend on the scale of operation. While theoretical maximum can be met over shorter horizons, a stable velocity over long periods of time may be somewhat slower than the theoretical maximum. This is why:

• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. (Agile Manifesto)
• Scrum is a framework for developing, delivering, and sustaining complex products. (Scrum Guide)
• Scrum is used to develop and sustain Cloud (online, secure, on-demand) and other operational environments for product use (Scrum Guide)
• Scrum is used to sustain and renew products (Scrum Guide)

OK - what then?

This is where advancement of engineering processes and tools come in. The objective of improving engineering processes and practices is to see if any of these help in improving average velocity over longer time horizon. It is no surprise that that automation and CI-CD are so popular within agile teams. For example,

• By automating all tests, regression tests can be completed automatically (i.e. without the team’s active intervention) so that it does not take incrementally bigger time for the team to validate that new change has not destabilized existing feature. You will then be able to maintain a constant pace over time. Else (i.e. we have no time/budget/skill for automation), with every iteration that you bring in, the overhead of validating that past features work will be so high that you will not deliver enough value. Eventually, someone will decide to skip the validations and also eventually something will actually go wrong in live environment. The solution would then end up being not using agile and going back to waterfall (because you cannot manually validate everything once every 4 weeks - you can only make such an investment once every year)!
• By following modular design and coding approach (i.e. services/microservices and APIs), functionality can be kept segregated and interfaces clean so that changes can be contained – both for analysis, build and test … and so on.

When you can implement practices that align with the principles and you can articulate the change within your team, adoption will become easier - transformation will not be a dream. Everyone can understand why velocity is not sustainable without these practices and processes and how they can help you meet the underlying objective.

Disclaimer

Although I strongly believe in sustainable development, the data that I have used to make my points are not from IT development at all. I apologize for leading you on. The conclusions still stand.

The data that I had used handle some elements of being able to sustain a velocity over different horizons. See the original data below.

The X-axis is the distance in metres for a race – starting at 100m and then going on for 200m, 400m, 800m and so on until 100km! The Y-axis is the average of the best time (i.e. world record) taken to complete 100m in that race. For example – the world record for 100m is 9.58s. The world record for 200m is 19.19s – so the average time to cover 100m was 9.6s.

Source data: https://www.iaaf.org/records/by-category/world-records

The picture shows that while we can see some astounding times over short distances (100, 200, 400m), things start to drop gradually until it stabilizes at about 18s for every 100m (almost half the velocity if the race was only 100m). If we are looking to run the marathon (i.e. products and platforms), we cannot compare with the benchmark of short distance races (projects). This is true in every discipline of sport where a single instance of the sport is played over very short to very long span. Another example of such variability can be found in the game of cricket (runs scored per 100 balls) which can be played over as short as a couple of hours to as long as 5 days.

Its time for us to learn from other disciplines as we do not have time to make all of the mistakes ourselves!