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:
- http://feeds.feedburner.com/aspadvice/lhVO (Blog)
- http://www.linkedin.com/in/ericlandes (Linked In Profile)
- http://twitter.com/ericlandes (Twitter)
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 (http://finance.groups.yahoo.com/group/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 (http://aspadvice.com/blogs/elandes) 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.
Don't want to miss a post or podcast? Subscribe to get notified about posts via email daily or weekly.