Ok you may ask “how is this an anti-pattern? it sounds more like a symptom”.
I would argue that it is both a symptom and a cause and that it really doesn’t matter. It is a symptom because we get long lead-times from of the practices and processes we use. It is a cause because today we have the knowledge, technology and experience to greatly reduce the lead-times. In other words the length of lead-time is a matter of choice.
Traditional development processes, steering-models and organization is by definition working against short lead-times. Much of the delay is created in the handovers between requirements, development, test and production.
Some consequences we almost always see in traditional organizations which are related to long lead-times are:
- Difficulty in planning
- Highly risky deliveries
- Poor quality
- Very large cost to make sure quality is good
- Cleanup months after delivery
- Unhappy customers
- High employee costs
- Employee burnout
Naturally we may have more or less “debt” in the organization which are preventing us from instantly reducing the lead-times. There are on the other hand many examples of organizations which have reduced lead-time greatly (and also reduced the mentioned consequences) by just working in another way.
So what is a good first step? Having the management team look into DevOps and Continuous Delivery is great. You don’t need to understand every technical detail about it but getting a basic understanding and then focus the whole organization on reducing lead-times can be very effective.
As I mentioned short lead-times is a choice, for some perhaps a long term goal. We have learnt that in traditional organizations this choice must be made at the very top of the organization. There is often a lot of competence and ideas just waiting to be used in the organization, so expect a need for good change and technical leadership once the choice has been made.
- We deliver software and configuration of test and production environments manually
- We deliver to a production-like environment only after development is done
- We are not aware of where the waste is in our process
Latest posts by Emil Vikström (see all)
- “Big 5” dangers for your software company - March 10, 2015
- How to produce successful change - November 19, 2014
- Guest blog: Stepping Stones into the Future through Leadership Agility at Ericsson - September 1, 2014
Copyright © 2014 Emil Vikström. All Rights Reserved.