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

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.

The rest of this series can be found here: Part 1, Part 2, Part 3, Part 4, Part 5.

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.

Written by Jack Milunksy - COO at Brightspark, certified ScrumMaster and Co-founder of Agilebuddy (Agile project management software that lets you easily Create, Estimate, Plan and Track your software development projects). For great Agile tips follow Jack at: www.twitter.com/agilebuddy. To get more info on Agilebuddy please visit: www.agilebuddy.com

Comments

[Dave Nicolette]

I agree that delays between sprints are waste. I think we need to spend some time during each sprint to get ready for what's coming down the pike. Otherwise there's a pause in value-add activity while people figure out what to do next, etc.

In terms of lean thinking, that sort of workflow strikes me more as mura (unevenness) than as muda (waste, or non-value-add activity). It feels as if you're going over a speed bump at the start of each sprint (or at the end, if that's how you perceive it).

[Jack Milunsky]

Thanks for your value added comment Dave.

Much appreciated.

Jack

[Software Development]

that's really a fantastic post ! added to my favourite blogs list.. I have been reading your blog last couple of weeks and enjoy every bit. Thanks.

[Jack Milunsky]

Thanks for the thumbs up. Much appreciated!

[Software Developer]

Nice article.....I really impressed while reading your post.....Thank you so much , it will useful to every one....