How quickly are you able to deliver a product to a customer? Fast enough so that he doesn’t leave for your competitors? Or so fast that he is satisfied? Or so fast that he doesn’t have time to change his mind? When the economic situation, technological capabilities and customer needs are dynamically changing, fast software delivery ceases to be a matter of competitive advantage and becomes the standard of work.
Imagine a bank ordering a major system at the beginning of 2008, before the crisis. A project contracted for 30 months. Add to that 6 months of trying to implement the system and integrate it with the customer’s existing software. Sound familiar? How much of the contracted functionality do you think the client will use? As of mid-2011, no bank is lending in Swiss francs. Nevertheless, our bank will get extensive functionality to support this product. Hardly, it will be for later. By the way, the banking law has changed, so we still need to make adjustments here and there. Nothing difficult. Another project for a year or more and we have a job for life… Unfortunately, there are still an alarming number of such monstrosities in the IT market.
Random changes
Of course, it is possible to try to speed up the project. Such actions are called changes and are usually random. All of us have seen such attempts. We buy better hardware to speed up the compilation. Suddenly, instead of 30 minutes, the whole process takes 5. Success! The trouble is that the customer still does not get his product faster. Alternatively, we buy new hardware but don’t have the time or money to implement it well and train employees on it. The technique of managers selecting a tool for engineers based on a vendor’s PowerPoint presentation is also popular.
Another reliable method is to tell employees to work faster. Well, yes, after all, they didn’t know that until now and only when ‘motivated’ by a manager will they get to work. I also include in this category managers who confirm (i.e. commit from ‘commit’) unrealistic dates and then declare to the team ‘You have to do it’ (team version: ‘We have to do it’).
Another method is to closely monitor how employees do their work. In other words, for the time being, they are doing it inefficiently and you only need to show them the best way to make them more efficient. This one-right way is called the standard process and is often defined by process specialists (but not software developers) and imposed on everyone. This gives us precise control over who does what, and a heap of extra documentation and reports.
When a project is already seriously behind schedule, then, for dessert, we can throw in a few more developers. This ensures that the project slows down even more effectively (see Brook’s Law).
Looking for inefficiencies
I do not mean to say that making changes, buying tools, expanding teams or standardising processes do not make sense. They most certainly do, provided they are done with the whole system, the whole company in mind, and not just local optimisation at departmental level. Instead of ‘change’, organisations need ‘improvement’, and continuous improvement at that. So, to accelerate software development we need to look at the whole software development process. Understand the implications of the changes being made. And here it is worth drawing on Toyota’s experience. To call this company a leader in lean production would be a sign of modesty, because lean systems (Lean), originate precisely from the Toyota Production System (TPS). Toyota has distinguished three types of inefficiency:
- Muda – Waste, i.e. anything that does not add value from the customer’s point of view.
- Muri – Overloading of people or equipment leading to quality and safety problems.
- Mura – Unevenness resulting, for example, from unforeseen problems, or fluctuations in orders, deliveries or events.
Each inefficiency has an impact on the others. Errors, which are a type of waste (Muda), cause batches of materials to revert to earlier processes which generates an uneven production load (Mura). This again overloads machines and people (Muri), which generates errors and the circle closes. To help identify inefficiencies, Toyota has created a list of seven types of waste, which has grown to 10 categories in the case of mental work.
What is slowing you down?
In September 2011, I had the pleasure of presenting the topic of inefficiency and waste for the first time at a conference. I encourage you to watch.