Adventures In Lean

In the last six months, my team has undergone some very radical changes and has turned into a full blown Agile team. I’m very happy with our success and I consider this team to be the shining example in our company, at the moment.

Now, in keeping with the tradition of this team in changing at least one thing every few weeks, we are about to embark on a new journey in our project management processes: Lean Software Development.

Starting at 1pm, Central Time, today, my team will be kicking off the following processes:

I am going to be posting a series of entries on each of these specific items over the next few weeks, and will most likely keep this post updated as the index of entries for a while. So stay tuned for a whirlwind of opinionated posts on our next great experiment!

Table Of Contents For Adventures In Lean

Here are the articles that I have written or am writing for my Adventures In Lean series:


  1. Kanban – Pulling Value From The Supplier – In this post, I am laying the foundation of what Kanban is along with a couple of other important terms that I will be using throughout the series. Kanban is only one of many tools, techniques and philosophies found in lean, though. Trying to sell kanban as lean would be like selling a steering wheel as an entire car – you’re only getting part of what you really need.
  2. Kanban in Software Development
    1. Part 1: Introducing Kanban Boards and Pipelines
    2. Part 2: Completing the Kanban Board with Queues, Order Points and Limits
    3. Part 2.5: A Variation on Queues – Pipelines for WIP and Done
    4. Part 3: Andon and Jidoka – Handling Bugs and Emergency Fixes in Kanban
  3. Our Kanban Board and Process 
  4. Release Per Feature – Delivering Value As Soon As Possible
  5. Just In Time Retrospectives – Fixing Problems As Problems Occur

There are likely to be other articles added to this list as well. Please check back now and then to see what has been added!

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs - the amazingly awesome podcast audio hosting service that everyone should be using, and where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in Agile, Lean Systems, Management, Retrospectives, Standardized Work. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Derick,

    > we are about to embark on a new journey in our project management processes
    > today, my team will be kicking off the following processes

    In “Decoding the DNA of the Toyota Production System” (Harvard Business Review, Sept 1, 1999), the authors discuss the common scenarios under which lean efforts have failed in the west.

    The most common failure mode was in seeing lean as a process, and in seeing lean adoption as a process effort.

    While your enthusiasm for lean is great, adopting lean in a team is fraught with pitfalls, and adopting it as a process improvement effort (rather than adopting lean for what it is intrinsically) is a well-known way to hurt an organization.

    What are you doing to avoid the same unchallenged presumptions in yourself that have wrecked havoc in the past for other businesses?

  • @Scott

    I’ll have to read the article before I can create a complete response. Do you have a link to an online version of it?

    In general, though – I understand the problems associated with surface level process fixation. the same problem has occurred with every good philosophy in software development. scrum, xp and the other agile methodologies fail constantly because people only look at the surface process.

    lean is a philosophy and long term vision, not a process. i’ve held the philosophy of continuous improvement for a while now, not “follow a process”. kanban is the process that we are starting with, but i’m not stopping with simple process changes.