When I teach iterative approach in software development, I use to justify it with an analogy that I have borrowed from Kent Beck: managing software is like driving a car; you permanently need to adjust left and right if you don’t want to have an accident. That’s a fine analogy and it always worked for me. Being myself deeply convinced that iterative approach is a completely natural human behaviour I have added my own list of images, examples and stories to reinforce the concept. For instance, I often ask my audience in autumn, how many in the classroom know precisely what they are going to do for Christmas eve. At best I have a couple of people saying they do and all the other ones showing uncertain faces. If I ask how many have a rough idea of what they are going to do, most hands come up. And all in all, we all know that Christmas will come and that we’ll do something special on the 24th and 25th. Interestingly, you will notice that nobody is seriously contemplating the idea to postpone Christmas because we would not be ready. So, we deal with it!
I often use another example and ask my delegates to plan a year long trip around the world to start in 3 months time. To keep a long story short, we always end-up with at best a planned trip for the first weeks and a lot of unknown to adapt to the situation. I never had the case of someone describing week by week what they will be doing, visiting, and where they will be sleeping or what transportation they will use. But they can all assure that they will travel around the world, …and be back at work on a very specific date! So, we can get firm and confident on the objectives without planning like mad all the details of the plan.

Now, I am asking the question: if we, for our own personal interest, can’t figure out what the plan will be for Christmas, 6 weeks in advance, or where we’ll be sleeping in a trip 6 weeks inside the journey, I wonder why on earth we would be naturally interested (I mean genuinely, deeply, honestly) in knowing what the plan will be for our software in 6 or 12 months time. I am not challenging the relevance of the question in terms of business planning, budget management, sales perspectives. I am challenging it in human terms. The scale an individual is comfortable with has nothing to do with the scale some big projects are talking about.

One way to tackle that problem is definitely to manage the project iteratively. This has the immediate benefit to reduce the time scale to something people can naturally cope with. We all can have an objective in mind to achieve in the next 3 weeks. So, in terms of connecting with human’s behaviour, it does the job. Now, does it have other serious implications in terms of business benefits? Here comes my glass of tap water!…

This example is taken from “The Fith Discipline” by Peter M. Senge. The point of the chapter it is taken from is to be able to describe the root cause of problems rather than stick to the surface of the problem. So, here is the example: one is trying to fill a glass of water from the tap. This simple action is in fact rather complex and involves a real time reaction to the situation if one wants to get the glass filled right. We never think about it but that’s what we really do (the arrows mean “influences”):

Now that works fine because of the speed of the influence between each step. You get immediate change in the water flow when you move the faucet and you see immediately any change in the level of water in the glass. Now comes the interesting bit: what if we introduce a delay in the system? What if we had a 5 seconds delay between the move of the faucet and the flow of water? That would look like this:

Concretely, you are very likely to overfill the glass due to the lack of response from the system when you make an input! What I find interesting in that simple fact is that if you think of the system as a Software Development Project, then you get the following:

At that stage, if you are the sponsor of the project, your obsession becomes to remove the delay in the system. The longer the time between, in one hand, the injected money and effort and, in the other hand, the possibility to evaluate the result (perceived gap box), the bigger the error will be. This is what Peter Senge calls a reinforcing loop. Pragmatically, the consequence of this will be:

  • More money injected due to the lack of response of the system. This is the equivalent of one opening the flow of water bigger because there is no response.
  • Counterproductive actions due to the feeling of panic that target will not be met in time. Imagine that the delay is now 30 minutes when you are filling your glass, we would probably be hitting the faucet, swearing at the pipe, put the glass aside while we would look into this, even maybe start some unnecessary quick fixes, like opening other taps to fill the glass. We would certainly start thinking of reducing our objective and intend to fill the glass by 30% only. We might even call the plumber for enlarging the pipe to fix this problem once and for all when this is not the problem.

In the end, I think it is important to understand that an iterative development approach is not only beneficial to the development team in terms of respecting the human scale of projects but also very beneficial in terms of financial control. The more often you get a feedback for the effort put in the project, the less you will waste time and energy fixing the wrong problems on the project! So, let’s get the shortest possible iterations in our software development projects!

Let’s think about it!