Lean or Kanban or Agile

This content is syndicated from VersionOne by VersionOne. To view the original post in full, click here.

This post originally published by Mike Cottmeyer for Agile Chronicles, May 2009. Here I am.. Sunday afternoon.. Mother's day. Just got back from taking the family out for a low key Mother's day celebration and now I've got a little quiet time before the week begins. The conference last week was quite a rush... had a great time... met a lot of great people. Before the week gets going I want to sort through some of my thoughts on this whole Lean/Kanban thing. A bit of history... Mary Poppendieck was one of the first few authors I ever read when I got formally introduced into the agile community. I recall how much her book resonated with me then... and looking back I can see how much it influenced how I think about agile... and the agile movement as a whole. I tell you guys that to say I have never made much of a distinction between agile and lean. To me... it was just a different way of looking at the same fundamental truth. A buddy of mine recently told me the story of the blind men and the elephant. The general idea of the story is that we have a bunch of blind guys in a room with an elephant (sounds like a problem waiting to happen to me). These guys are each touching the elephant on different parts of its body. The guy touching the tail says an elephant is like rope... the guy touching its leg says the elephant is like a tree... the guy touching its ear says it is like a giant leaf. You get the idea. The point is that without being able to see the whole... they each describe the elephant from their own particular point of view. As I watch people debate over what it means to be agile... it seems we were a bunch of blind men arguing over the nature of the elephant. If your point of view is small, colocated teams... scrum brings a valid perspective. If your focus is more technical... the practices of XP tend to resonate. If you come from a larger more structured organization... you might need AUP or DSDM. If you have a really small team of experienced developers... let's talk Crystal. Context is everything. It seems to me that much of our debate is out of context. When we get dogmatic about one methodology... about one set of practices... we are often not taking the other person's context into consideration. That is why the Agile Manifesto was so powerful... it was a set of value statements... it was a set of principles... that was broad enough to be applied in a situationally specific way. We have to take the local context into consideration. I don't think the Lean/Kanban proponents are saying they have found a better way... I think that we are continuing to learn and to grow and to better understand what it takes to deliver great software. It seems to me that the Lean/Kanban movement is not out to replace XP or Scrum or DSDM but to help organizations that are having trouble adopting these practices... or have adopted them and need something else to increase their productivity. Here is a quote from the Schwaber and Beedle book "Agile Software Development with Scrum"... "Empirical process control models are elegantly simple. They employ feedback mechanisms to monitor and adapt to the unexpected, providing regularity and predictability. The actors in a Scrum team empirically devise and execute the best processes possible based on their skills, experience, and the situation in which they find themselves" The line about the team devising the best processes possible based on their slkills, experience, and the situation in which they find themselves has always resonated with me. I think that Lean and Kanban give us another set of processes and tools that can help the team improve. I do not believe Lean and Kanban are at odds with Scrum... nor do I believe that Lean and Kanban are going to be successful without the engineering discipline encouraged by XP. We are just another set of blind men looking at a different part of the elephant. My personal take... Kanban is a visual process control tool that helps teams effectively manage the flow of work through the sprint. Scrum gives guidance that the team decides what they can do... and the team decides how it will get the work done. Kanban gives the team another way to inspect and adapt and to learn how to get better. I am not hung up on the fact that Kanban is iterationless... I can apply it within the iteration. If I determine that the iteration has become waste and no longer need it... I'll get rid of it. My goal has never been to do Scrum... my goal is to build great software as fast as possible. In Scrum process improvement is implicit... the team inspects and adapts and find ways to get better. In Kanban we put specific visual controls in place that help the team better understand the flow of work through the sprint and make targeted improvements as necessary. To me the idea of Lean is a bit broader... lean deals with the enterprise. Lean is about managing the flow of work across teams. How do I take an idea that comes from biz dev... turn it into a product idea... get the work assessed and approved... built... tested... delivered to the customer... billed... and supported. Lean can give us some guidance here for how to manage the flow of value through the organization. Kanban is a tool... Lean is a philosophy. A team could use a Kanban board to manage the backlog item through the development phases... analysis, design, code, and test. An enterprise could use Kanban board to manage the flow of an idea from inception through development to billing and support. The principles of Lean can be applied within the team and across the teams. Understanding value streams... identiying constraints... eliminating waste are all explicit ways of helping the team get better. These are principles and tools that explicitly help the team inspect and adapt and make better decisions. As a founding member of the Lean Software & Systems Consortium I hope we continue to build on what is out there and resist the urge to make this something wholy new. Remember... agile is all about uncovering better ways of developing software by doing it and helping others do it. Lean/Kanban gives us another set of tools to help that come about.

Leave a Reply

What is 3 + 6 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”