The 7 Software Development Wastes – Lean series Part 4 – Transportation

Introduction

Previous posts on the first 3 wastes can be found here: In-Process Inventory/Partially done work , Over Production/Extra Features and Extra Processing

It’s both interesting for me on the one hand, yet puzzling for me as to what makes a blog popular or not. The first article I wrote on this topic had close to 5000 reads as compared with only 1000 for the last blog post. I figured that based on the response to the first post, folks would be real keen to understand the rest of the 7 wastes in software development. Never the less, I am committed to continuing with the series. Hopefully there are still some of you out there who can benefit from it all.

Transportation – Hand-offs

Transportation in manufacturing corresponds to hand-offs in software development. Anytime you hand a deliverable off to a different party, there is some loss in the transfer of knowledge.

There are many such examples of hand-offs in software development:

1. Developer hands off to another developer. In this scenario if the first developer never documented the code properly it’s going to take significant addition effort to figure things out. Worse, the second developer may make assumptions and, as a result, introduce bugs in the system.

2. Developers hand off code to testers to test. Many organizations still don’t engage QA early enough. Bear in mind that on Agile projects, QA is involved as early as the requirements phase (not that it’s a phase). If the QA has no idea what the developer did or the problems he faced or the assumptions he made, then the QA is really just shooting in the dark. It’s important that the developer at least includes the QA early on, documents the feature accordingly (no long dissertations), so that an effective transition is made.

3. Handing the code over to deployment teams. Many times I find separate deployment teams struggling to figure out how to get applications deployed. Configuration settings, compile instructions etc if not properly communicated can cause significant delays.

4. Handing-off to customers. If the client is not trained properly, or the software functionality is not documented properly, there will be more support calls for example.

There are many ways in which to reduce transportation wastes in software development:

1. Ensure there is open communication between all parties. Broadband communication (as defined in Agile software development practices) is imperative.

2. Ensure proper, up-to-date and effective documentation is in place where appropriate. Identify these needs up front and ensure there are tasks for this on the backlog.

3. Include all functional areas in the development process.

Be mindful of and identify all these transition points in your organization. This will help minimize costs due to hand-offs in your organization

Next week I will cover the 5th waste in the series – Motion

10 thoughts on “The 7 Software Development Wastes – Lean series Part 4 – Transportation”

  1. Jack-

    I’m enjoying this thread of posts! I’m still learning and immersing myself in Lean, so I find them valuable. I’m guessing you got more traffic to the first one simply because it is the one (so far) that everyone can recognize as a problem they have and need to fix.

  2. The biggest hand off waste is the existence of requirements people that get between the developers and the customers on enterprise projects. Instead of being there to move the conversation forward, they become middlemen in a game of telephone. In addition, they often produce voluminous documentation which increases the cost of change and causes deeper attachment to temporary decisions.

    1. Sometimes customers and developers need a middleman to translate one language and culture to the other’s language and culture, illuminate the important, sort the essence, help the customer focus on what can be done, and let the developer focus on what the customer want.

      Ideally, a “requirements person” distills the essence of what the customer need and help the developers invest the minimum required effort to achieve it. Mis- communication, or just a bad translation job can lead to unnecessary development effort, missed time lines and overall just missing the business target.

      Should I risk all these and let the developers face the customer on their own?
      Hmmm, not always, 🙂

  3. I don’t think I was suggesting that you don’t have to have a middleman. All the article is saying is anytime there is a handoff, there’s an opportunity for information to get lost. So if having a middleman is going to help that process then that will eliminate this type of waste.

    Thanks for your comments
    Jack

  4. Hi Jack..Thank you very much for your series of Posting.Your articles are really making us to realize in wastes of software process and hence we are saving a lot of our precious time as well as money..Keep it continue..bye

  5. Thanks Jack for your effort in bringing clear examples of Lean in software (in contrary to industrial factory samples).

    In my experience this is the kind of waste that harms more our industry. The last outcomes are often projects late on schedule or even suspended (and most of the times exceceeding the budget).
    It’d be greart to learn from this and keep the lessons in mind when defining our (formal or informal) procedures.

Leave a Reply

Your email address will not be published. Required fields are marked *