The Benefits of Using Lean Approaches for Software Development


    If Lean can work in healthcare, why not software? Today's guest post is by Eric Landes, who currently works with Lean/Agile techniques in project portfolio management and development environments in an enterprise IT setting. He constantly works to add business value to software projects. Besides blogging, he will be presenting his kanban experiences at the Lean & Kanban 2009 conference. You can contact him using any of the following methods:

    By Eric Landes:

    In reading the Lean Blog in the last couple of years, I had not seen any mention of using lean techniques for software development. A couple of months ago, I emailed to Mark asking if he had heard anything about lean software development. He didn’t know much about the topic, and Mark asked if I would be interested in writing a blog post about it.

    I have been involved using lean techniques in software development for the past 2 years. If you count agile development, as I do, then I have been working with those methods off and on for over 6 years. As most do, I came to lean as a better way to improve our processes.

    For those not aware there have been significant changes in the software development world over the last 10 plus years. A new method of development called Agile software development has become mainstream. It started out with names like Extreme Programming (XP), Scrum, Feature Driven Development and more. These new methods were responses to a cry for software development to deliver higher quality software faster.

    The agile community owes a lot of debt to lean practices, and I have seen that debt deepen in the last 2 or so years via the use of Kanban. For those not familiar with agile development, feel free to check out the Agile manifesto, written in 2001. That document talks about values like customer focus, transparency and empowerment for employees. This of course makes lean an easy fit into the Lean mindset.

    My introduction to kanban in software development came via David Anderson’s writing on his work at Microsoft and Corbis. Others can be credited with introducing lean also, most notably Mary and Tom Poppendieck. This new practice of using a lean tool (kanban) to help drive the software development process has taken hold in many different places.

    Using Kanban brings lean concepts like continuous improvement, continuous flow, and limiting WIP into your development process. These benefits have been used in sustaining engineering software projects, “Greenfield” software development, and most other types of software development. It has also been used in IT portfolio management.

    One aspect of Agile that fits well into Lean theories is the idea of pull. Most Agile teams, allow team members to pull new tasks when completed from a limited set of tasks (or stories) available to the entire team. This is true of the Kanban system as well. Tasks or stories that are on the “Kanban board” are pulled by team members from various queue positions when that team member is done with their current task.

    For instance , when a developer completes their task, they place their completed task in a QA queue. A QA person could then pull that task, or another when they are free to run tests. Meanwhile, the developer looks at the queue prior to development (usual Business Analysis) and can pull a new task from that queue. Not every software development Kanban operates in exactly this manner, but the theory is the same. Allow team members to pull tasks from appropriate stages to keep the flow of each request running smoothly.

    The most important benefit, in my opinion, can be summed up with something agile coach Karl Scotland said recently on the kanbandev mailing list. “It feels like the kanban system is a tool to help a team ‚Ä ¶ get the balance right, by making it all visible”.

    Other benefits include shorter cycle times to deliver features, continuous improvement of your process, and delivery of higher value features to the customer. I have seen significant improvements in cycle times and customer value. These benefits are realized through the use of constraints placed on feature development.

    A major difference between agile and the kanban is the elimination of an iteration timebox. A traditional scrum team may use 2 week “iterations” in which a team commits to finish a certain amount of effort (tasks) in a deliverable state. Some teams have found this constraining, when they have a task that cannot fit within the iterations specified time. The Kanban board allows larger sized tasks to go over that iteration length when there value in doing so. The Kanban team still releases to production on a regular schedule, making delivery predictable, but allows teams the ability to not be slaves to the iteration timebox.

    For anyone wanting to delve deeper into using Kanban or other lean processes with software development, here are some further resources. Check the Kanbandev ( mailing list and the recommended reading list. Also, the Lean Software Development mailing list has a lot of good activity.

    If you want to get ramped up quickly, there is the Lean/Kanban conference for software development in May specifically focused on Lean/Kanban Software development. My blog ( also has blog entries on using Kanban in software development environments. I look forward to seeing a lot of new process improvements coming to light as this methodology becomes a linchpin of software development shops in the future.

    Subscribe via RSS | Lean Blog Main Page | Podcast | Twitter @markgraban

    Please check out my main blog page at

    The RSS feed content you are reading is copyrighted by the author, Mark Graban.

    , , , on the author's copyright.

    What do you think? Please scroll down (or click) to post a comment. Or please share the post with your thoughts on LinkedIn – and follow me or connect with me there.

    Did you like this post? Make sure you don't miss a post or podcast — Subscribe to get notified about posts via email daily or weekly.

    Check out my latest book, The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation:

    Get New Posts Sent To You

    Select list(s):
    Previous articleLean in Government Conference
    Next articleError Proofing Against Pirates
    Mark Graban
    Mark Graban is an internationally-recognized consultant, author, and professional speaker, and podcaster with experience in healthcare, manufacturing, and startups. Mark's new book is The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation. He is also the author of Measures of Success: React Less, Lead Better, Improve More, the Shingo Award-winning books Lean Hospitals and Healthcare Kaizen, and the anthology Practicing Lean. Mark is also a Senior Advisor to the technology company KaiNexus.


    1. In addition to what the Poppendiecks have written, another resource is Lean Software Strategies: Proven Techniques for Managers and Developers, by Peter Middleton and James Sutton, available at
      And for enterprise situations, consider Lean Performance ERP Project Management: Implementing the Virtual Lean Enterprise, Second Edition, by Brian J. Carroll, available at


    Please enter your comment!
    Please enter your name here

    This site uses Akismet to reduce spam. Learn how your comment data is processed.