The 7 Software Development Wastes - Lean series Part 6 - Delays

September 11, 2009 by Jack Milunsky

Introduction

Interestingly, this weeks blog covers the 6th waste - Delays - as identified in Lean. How appropriate after the long delay since my last blog post on Task Switching. Herein lies an example of what Delays in software development can cause.  Delays introduce discontinuity and trigger additional wastes already covered like Relearning. It's important in any process, including software, to have continuity. This reduces cycle time and minimizes other wastes like Relearning, Task Switching etc.

Focus on the end-to-end process, not individuals

It's important to identify Delays early on and try to rectify them as soon as possible in order to maximize team productivity. It's interesting... I have been reading many interesting threads on the Agile forums lately about measuring developer productivity, team productivity etc. Managers/executives have us focus our efforts and attention on individuals instead of looking at the end-to-end process to find the real issues that address productivity and enhance team effectiveness.

It's actually unbelievable to me that organizations get trapped like this. Always thinking that Developers are the bottleneck. If we learn from what Lean teaches us, simple value stream mapping can uncover the real gems that can increase productivity.

Reducing delays between sprints

It's important to ensure that the value stream is tuned for maximum efficiency where there are little to no delays at any point in the process. For example, yesterday someone posted a question on one of the forums asking if it's possible to not have delays between sprints. Well of course it is possible but it takes hard work to get this right. You have to ensure that the backlog is properly groomed. So you need an effective PO who understands the market, the client etc. You need well written stories. You need estimates from developers early so the PO can make decisions ahead of the planning meeting. It's all about designing delays out of the system so that there are smooth hand-offs at all the transition points. And it's worth mapping this end-to-end process and identifying delays at each of these points.

Common Delays

So what are some of the more common delays you can look for and what can you do to avoid them?

1. Project approvals - waiting for projects to get approved is the most cardinal of all sins as this usually has handfuls of developers sitting around twiddling their thumbs and is a blatant disrespect for peoples time. Coupled with this is the fact that waiting causes dissatisfied and disgruntled employees and only serves to ruin the culture in an organization

2. Waiting for a proper prioritized list of requirements - so that work can get started.

3. Waiting for resources to become available - generally impacts projects significantly. This one is not necessarily an easy one to solve as there are generally budgetary concerns. But this then begs the question - is the company taking on too much? You can't be successful if you're not focused and properly staffed.

4. Change approval processes - well you don't want to hear my opinion on this. Suffice to say, these processes need to be eliminated entirely. And all Agile processes inherently solve these problems. Shortening Sprints helps big time.

5. Increases in work-in-progress - The more work-in-process, the more developers have to wait before they can deploy their code to production.

6. Delays getting client to sign-off on acceptance tests - We have a services business and we find that this is a huge problem for our organization. Not getting sign-off is just a liability for the company as you're not getting paid until you get sign-off

Take the time to assess where delays are occurring and I can guarantee you that the effort spent doing this is hugely beneficial to your productivity, efficiency and overall bottom line.

Permalink