Last update: 02/06/2016 13:53
Many Agilists, amongst the most experienced, advocate that the only thing that counts is the Lead Time, the time between the moment an idea has formed, and the time at which it has materialized as a product or service that is ready to be consumed by the customers/users.
We of course agree saying that Lead Time is indeed an important measure. Our discomfort comes from the adverb "only" and by the shortcuts such Agilists take and spread amongst organizations.
Such measure, in the true sense of Systems Thinking, cannot lead to any action until the moment a company has fully turned to be a Lean Enterprise.
During a significant period of the journey towards Agility, Agile or Lean Teams won't have any grip on some parts of the process: it won't influence the speed at which ideas are accepted, funded and even partly how they are spawned. Conversely, the end of the process also escapes much of their grip in the early stages of their journey.
What's more, even in a Lean Enterprise, there are occasions where the Lead Time is definitely not the only thing that counts even if the Lead Time reduction is an important part of Lean Manufacturing. As a matter of fact, working on the Lead Time, and on the Lead Time only, would lead to a very suboptimal optimization of the complete chain of value. In many cases, today's Agilists confine their thinking and judgement to software that is purely and entirely "web based", that is software that gently sits on a server somewhere (or network of servers) and that is consumed by users as soon as it appears. We of course know that this is most of the today's reality, but we also see every day how this confines the reasoning behind it, leading to many shortcuts that, soon or later, pollute entire organizations. Nobody thinks about the cost of a release anymore, something we wanted to make people aware of in our SAMBA page related to that problem: Frequent Releases.
"Web based" development and type of software constraints these Agilists to this only universe in which Development (Engineering) is the driving cost, not to say the only cost they consider. Well, we're grieved to say that this is too short thinking: this is short-sighted. We say that there are additional concerns that must be taken into account, we say that the whole chain must be considered and that there is ALWAYS an associated cost to any release a company does. Such costs must be compared to the expected benefits (and sometimes that is very complicated). If for example a release requires an extensive training, then the cost of this training must be part of the equation. That is precisely what David Anderson taught us in is seminal book Kanban – Successful Evolutionary Change for Your Technology Business: there are transaction and coordination costs to consider!
We dare say that if the optimization of the whole chain goes through a slow down in the Lead Time, for example by synchronizing separate releases to reduce the overall cost, and therefore trying to maximize the benefits, so is the choice to be made.
We therefore once again pretend that the Lead Time, all important it is, is not the only one factor to pay attention to. Consider that the Lead Time is the qualifying time of one of the runners in a relay race: it is damn important to get it, but we may also consider that each runner has to transfer a bit of his or her energy in his or her legs transmitting the baton, which is energy that is not used for running as fast as possible, but energy that is used to optimize the entire race.
On top of the examples we cite, we observe that many Agilists consider the handover between Development and Rollout as a waste, and as such, needs to be removed, can be removed. They're right of course, but not all the times; they're right partially. This way of thinking is once again induced by the fact that they live in a "web based software" world. This trend is more and more acute in the industry, mostly because of the incredible success, fully deserved, by the Continuous Deployment or Continuous Delivery paradigm. Make no mistake, we really love the idea and the concept; as a matter of fact, we advocated its usage in many instances! But this cannot be taken as the fundamental verses of Agility. We need no religion!
If Agilists would place themselves in industries other than software, they would see things differently, with more nuances. For example, we really much doubt that the teams which produces the dish washes are also the ones placing these dish washes in the retail stores! There is a handover (but it must be optimized)! To remain in the world of software, it would be a totally different ballgame simply by thinking how we can optimize the whole chain (develop and then rollout) for “shrink-wrapped” software!
In such a world of “shrink-wrapped” software you must create the box, and produce it in the quantities you need, you must create the gold copy (master copy), duplicate it, maybe registration cards (at least 20 years ago), put eveything together, etc. In such cases it makes perfect sense to delay a rollout to optmize the entire chain. For example, at FastWrite we created the “I Manage…” software collection of which we sold more than 300.000 copies. We usually gathered 3 or 4 titles together to reduce our costs of duplication, of manutention, of transport… in other terms we were looking for an optimzation of the global chain through economies of scale: duplication per piece was cheaper, design of the boxes was cheaper, manutention/pc was cheaper, negotiation with large distribution channels was easier, transport and shelf filling was cheaper, products could be advertized together, bundles were possible, sales material was cheaper to produce (in which we could also announce the next big wave that was coming), etc. So here again … Lead Time is not the only thing that counts!