Pushing work into a system creates lack of capacity, long lead-times and poor quality in the development organisation.
One of the worst drivers of stress, long lead-times, high costs, not fixing long lasting problems and other bad things is in my opinion the way we have disconnected the work done on the business side with the work done on the development side. The potential for knowing the capacity of the development organization is then effectively reduced to zero and usually causes a massive and constant overload in the development organization.
To be more specific one could see the situation as the business side pushing work into the development organization without considering the capacity (Picture 1). I call this Scope out. This leads to that late in the development process you must take out, move forward (in time) or throw away partly developed functionality. This in turn leads to huge hidden costs. Often it is this behavior which creates lack of capacity, long lead-times and poor quality in the development organisation.
If you can throttle the feeding of work into the development organization you can have very positive effects. I call this Scope in (Picture 2). In Scope in you take the capacity of the development organization in consideration and, in the ideal case, let development pull the amount of work they have capacity for.
An important part of Scope in is to be able to split work into small parts. This makes it much easier to get a feel for the capacity and makes it easier to test and deploy. This happens to be exactly what we want to achieve with Continuous delivery and DevOps!
What is the state in your organization? To what extent are you doing Scope out and Scope in?
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.