alacrity in action
| Tags: , ,

It appears to be the height of the political parties conference season here in the UK. It means politicians get to make many announcements about their policy choices. Now imagine one of the political parties decided to announce that during the next parliament they will work to increase the average speed of cars on the roads. In principle you can see the benefits of decreased travel time and thus earlier arrival at your destination. In practice however I suspect you would quickly discard such policy as not being sensible. You most likely understand the relationship between speed, safety, road capacity, vehicles’ capabilities, traffic, congestion, etc. We tend to understand traffic because it’s tangible and we experience it either actively or passively almost every day.

When it comes to software development however even practical experience doesn’t always create the same level of understanding. Writing software is not tangible – it’s just “bits and bytes on disc” – and hence it’s much more difficult to obtain meaningful feedback which is essential to developing a correct mental model.

Perhaps that’s one of the reasons why organisations adopting Agile jump on the bandwagon of “increasing speed of software delivery”. It makes sense to want to deliver working code more quickly and with the initial introduction of Scrum or another agile approach a step change is often experienced. However, just like increasing speed on the roads, on it’s own an understandably futile effort, so it appears to me is the common focus on lowering the cycle time.

My point here is not to draw any direct parallels between driving and building software though I hope it serves as a useful illustration. I would like to emphasise that a holistic approach which includes the understanding of all the elements involved and their interactions is essential to providing a basis for continuous improvement.

Now, a party which declares to commit to improving the road infrastructure makes far more sense in my mind. So where would you like to see improvements focused for software development?


Comments3

  1. I agree. Cycle time should be a metric, not a target. Using it as a target just leads to getting the wrong stuff out earlier, along with the futility that you mentioned.

    Do you have any different suggestions for measuring whether the infrastructure has improved, though? Otherwise cycle time seems like a reasonable proxy measurement, and is only as fickle as, say, bug counts or customer satisfaction surveys…

  2. Nice analogy. I feel encouraged that other folks are thinking and writing about these kinds of things. This post meets my need for opportunities to engage in mutual learning and constructive dialogue (and practice my new approach to feedback) 🙂

    Can you help my understand better how improving road infrastructure would be a better policy objective than increasing traffic speed? My automatic response was to look to “customer value”; directly, a better travel experience, indirectly, more wonderful lives less blighted by travel frustrations.

    – Bob

  3. I agree that organisations adopting Agile tend to want to “speed up software delivery”. However IME they are not even talking about quickening cycle times. They are talking about increasing productivity of development and testing teams, which is not the same thing.

    I don’t believe reducing cycle times is necessarily a bad thing to have as a target because this is about reducing the time from idea to delivery (speed to market), which means addressing work-in-progress as well as throughput (with reducing WIP being the more effective way to short term improvements). More the problem I feel is a need to try and increase the speed of delivery of a fixed set of requirements, and the belief that this is done by “increasing productivity”. I still struggle to see what productivity looks like in a creative pursuit of discovery such as software development – story point velocity and the such-like certainly don’t cut it. At least cycle times, when used correctly, are addressing the end-to-end delivery of software to customers.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.