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.
Other Anti-Patterns
- 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
Emil Vikström
My specialities are efficiency in IT, leadership, management innovation and people development
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.