Using Product Portfolio Management to Improve the Efficiency of Teams

[article]

Me: How many of you would say you spend most of their time fixing bugs?

Developers: (Almost all raise their hands).

Me: Consider what happens if you write a bug and are immediately told there is an error. How long does that take you to fix?

Developer: Not much at all.

Me: Now, consider the same error. But this time, you are not told about it for a week. And imagine nothing else has changed. How long would it take now to fix it?

Developer: Obviously, much more time. And, if something has changed, if someone else has been working on the code, it will take a lot more time! There would be so many changes to have to wade through.

Me: The fix was the same in both cases, but now there is extra work. The delay, from error until detection, caused this extra work. I call this induced work because it was created by the delay.

If you agree with the developers I have talked with, that they spend significant amounts of their time fixing bugs, then surely the amount of induced work we face is significant. That is a lot of dirt!

The Common Problem: Delay
In software development, there are many different types of induced work; however, they all have a common element: delay. The most common delays are the time between when information is needed and when it is used and between when an error is made and when it is discovered. And they are made worse by delays in getting information needed to act. The primary cause of delay is doing more than one thing at a time. The math is simple. Doing two things at once doesn’t take twice as much long; it takes twice as much time plus the time to do the newly created (induced) work. Accounting for waiting, detecting, remembering, stopping and starting, the resulting time can be significantly longer.

But, you say, “We need all of this work done. We can’t afford to do them one at a time!” I have heard this justification time and again. All of the work items are critical. The development teams need to work on all of them. But what we need and what is reality are often different. Imagine being a pilot of a two-engine airplane. The co-pilot says, “Captain, number 1 and number 2 engines are out.” You respond, “That can’t be! I need those engines on!” What you need and what reality is are two different things. The same thing is true with our work; what we need done and what is possible are two different things. To create the greatest chance of getting what we need done, it is critical to avoid creating new work that does not add value.

About the author

Alan Shalloway's picture Alan Shalloway

Alan Shalloway is the founder and CEO of Net Objectives. With almost forty years of experience, Alan is an industry thought leader, a popular speaker at prestigious conferences worldwide, a trainer, and a coach in the areas of lean software development, the lean-agile connection, Scrum, agile architecture, and using design patterns in agile environments. Alan is the primary author of Design Patterns Explained: A New Perspective on Object-Oriented Design and Lean-Agile Software Development: Achieving Enterprise Agility.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

May 04
May 04
May 04
Jun 01