Monday, December 13, 2010

Kanban Training with David Anderson

Interested learning more about Kanban?  Why not learn from the best?

David Anderson has announced he has available seats for his 3 day intensive Kanban Coaching Workshop in Los Angeles, CA on January 12 - 14.

I attended in May. The course is an absolute game-changer for project managers, team leaders, and recovering scrum masters.

Contact me if interested. I can get you a discounted rate.

Wednesday, October 20, 2010

Easy On The Eyes Please

I'm having some thoughts and reactions tonight that don't fit easily into Tweet-sized bites, so thought I would get back into this blog thing.

I've recently been poking around various software projects, tutorials, and blogs, trying to brush up on some recent technology. It's been the usual fare.  Pull the latest code and then muster a good 15 to 20 minutes of straight concentration time to get my brain wrapped around what this developer is trying to accomplish.

_-_  complexity [1]

Well, I had an incredibility refreshing experience today.  I contacted a coworker for some advice on technology and technique.  He offered example code from his current project.  So I cloned the repository and cracked it open.


Simple magic

What a refreshing change.  The project structure was clean, organized, and intuitive.  Ok, maybe I'm biased because I know this person, I've worked with him for 2+ years, and I know how he thinks.  But everything just made sense and it was simple! I opened the build file, and I could read the entire script without scrolling.  Imagine that.  Oh, and it's not like he was hiding complexity by using the latest and greatest build tool.  This is an old-school XML build file, you know, the stuff that gets the snarky laughs at the conferences? Well, it didn't matter because it was simple and understandable.  And I'll take old-school any day when it doesn't cause me to run through a mental boot camp just to understand how the damn project is built.

So, to the community of book authors, bloggers, open source developers, thank you for your efforts.  If you are interested in advice on how to further expand the reach of your examples and projects:

1. Keep it simple (seems obvious, but very few achieve simplicity).
2. Get off your architectural high horse every so often and take time to smell the flowers.
3. Make your intent as clear as possible.
3. Keep it simple.

Thanks Lee!

Tuesday, July 13, 2010

Topeka DNUG Panel Discussion on Agile

Thanks to those who attended the panel discussion on Agile methodologies, the other panelists, and Don King for organizing the meeting.  I thoroughly enjoyed the discussion.

I referenced a couple of books that I wanted to relay here.  Anderson’s book is the best source for understanding Kanban.  Poppendieck’s book contains very good information about value streams and funding models (product development).

Kanban by David Anderson

Implementing Lean Software Development by Mary and Tom Poppendieck


Monday, June 21, 2010

KCDC Kanban Presentation Slides

My Kansas City Developer’s Conference presentation slides are available for download (“Why Kanban?”).  For those who saw my LSSC10 presentation in April, the slide deck is very similar, with just minor modifications for the intended audience.  This talk is designed as an introduction to Kanban, so advanced topics like classes of service are only touched on briefly.

I failed to mention the local Limited WIP Society chapter ( during my talk.  If you are interested in participating in the continuing discussion with other local Lean and Kanban practitioners, then join the mailing list. We try to meet on a monthly basis for a casual lunch or dinner.

Thanks for the interest in Kanban!

Wednesday, June 16, 2010

Speaking at KCDC on Kanban for Software

I'm honored to be speaking on Kanban at the Kansas City Developer's Conference on Saturday, June 19, 2010.  Details are here:

Interesting in attending?  It's free!  They will feed you (free again) twice during the day.  And there are some great speakers.   Register here:

My talk will be a variation of my presentation for the Lean Software and Systems Conference in April.  Attend the conference, enjoy the networking opportunity, and ask me some tough questions!

Wednesday, April 7, 2010

Topeka DNUG Kanban Talk Slides

Thank you to those who attended my Kanban talk at the Topeka DNUG. We had a good turn out, but just a little short on time for questions.  If you have any follow-up questions about the presentation, please feel free to post in the comments section here.

Also, if you have any feedback on presentation, please let me know through this blog or by email:  troyltuttle [at] gmail

Slides Download

Tuesday, March 16, 2010

Kanban at Topeka DNUG

I am excited to be speaking at the April 6 edition of the Topeka DNUG (.NET User Group) at FHLB Topeka in Topeka, KS. 

My talk will be about Kanban for software development.  I really enjoy talking software process with an audience primarily made up of software developers.  They usually are the most passionate.

Where:  Federal Home Loan Bank Topeka
When:  April 6, 2010 at 11:30 am
What:  Learn about Kanban!
Food:  Yes, lunch is provided, but please register to attend

Wednesday, February 17, 2010

Guerrilla Kanban

After speaking to a few local Kanban practitioners (and aspiring practitioners), I thought it would be helpful to demonstrate how you can use Kanban to improve your software development process in small, incremental ways.  So much of what we learn about Kanban and Lean software online are implementations in relatively open and conducive work environments.  Or at least they are implemented by people with the authority or influence to make the change.  We see photos of large, gorgeous Kanban boards and we read about profound accounts of successful Kanban projects.

If you work in a corporate structure that seems too dysfunctional or too rigid to adopt agile processes, you may feel helpless in your current role to affect change.  Maybe you work on a small team in a command-and-control environment.  Maybe you work as a single developer in your own project silo with more work assigned every week than you have the capacity to complete.

This blog post is to challenge your assumptions about your ability to affect change, and hopefully give you the tools you need introduce positive change in your organization.

Project X is currently in production, but has some significant challenges. It has suffered from the lack of developer availability since it went live.  Bugs were discovered in production and often there were no developers available to fix them.  This later caused the product owner and users to overload development staff when they were available for support work.  The code was originally developed in project silos, with no automated test support.  The code base is only 2 years old, but is effectively a legacy code base.

Making Improvements
David Anderson, a leader in the Kanban community, has recently talked about Kanban as a “change management” system.  Since Kanban has a low barrier to entry compared to other popular Agile methods, your goal should not be to make grand, sweeping changes in your environment.  Allow Kanban to show you and the other stakeholders where you need to make changes.

Mechanics of Kanban
Your immediate goal is to visualize the value stream.  This can be on a white board, but any wall with appropriate fasteners will do.  The value stream for Project X (bug fixing) is:
Needs Prioritized –> Prioritized –> Dev –> Ready for Test –> User Testing –> User Accepted –> Released
Represent the value stream on your board and track every work item (figure 1).

Figure 1. 

Next, start limiting work in progress where possible.  At the time of the board photo, there was one developer fixing bugs, so the WIP limit for development is 1 (yellow highlight).  Notice the two large batches of bug tickets at either end of the board.  We'll explore what that means a bit later in the post.

As soon as you can track work items on a board, keep an electronic copy in a spreadsheet or tool of your choice.  The critical piece of data to track is the actual cycle time per work item (figure 2).  You will notice this sheet shows "Dev Cycle Time".  Since the code base doesn't have automated tests, large numbers of code changes are typically batched up for user acceptance testing and manual regression testing.  Given the technical and testing limitations, the project has very little end-to-end flow.  So, to help with project planning in the near term, development cycle time becomes more useful.  It allows the product owner to plan when a full regression test and subsequent release can occur.  In Lean terms, this is not ideal, but in the context of Project X, there is value in measuring a subset of the full cycle time.

Figure 2.


Once your work items are captured, and cycle times are recorded, you will need to capture that data on a regular basis.  For most projects, a daily project "position" is adequate.  At the end of each day, record the total number of work items in each state (figure 3).  Unless you have a very busy Kanban board, this should only take a few minutes each day.

Figure 3.

This historical data can be used to generate a simple Kanban dashboard in excel (figure 4).  At a minimum you should include information to answer two basic and related questions: how fast are we going, and when will we be done?

Once again, in the short term, Project X is primarily concerned with calculating cycle and lead time values for the development stage.  
  1. Average cycle time is easy:  (sum of cycle times  / count of cycle times).
  2. Lead time measures the backlog and average cycle time:  (backlog count * average cycle time).

For Project X, this simple dashboard is posted beside the Kanban board (figure 1 red highlight) and emailed to stakeholders every week. 

Figure 4.

The Goal
We have two immediate goals with our Guerrilla Kanban implementation: 
  1. Generate useful metrics to assist with immediate project planning needs.
  2. Provide visibility to make observations and improvements to the process over the short and long term. 
For Project X, providing metrics around development effort helped the product owner make more informed decisions about release cycles and project coordination with other systems in the portfolio.  Questions about developer estimates diminished quickly, and were ultimately replaced completely by cycle and lead time metrics.  A byproduct of this change was a significant increase in trust from the customer.

The Kanban board (figure 1) and cumulative flow diagram (figure 4) both serve as conversation starters with project stakeholders.  The only “good” aspect of the cumulative flow is the thin yellow ribbon of development work.  The WIP limits for dev work are effectively enforced.  The rest of the diagram exposes a large backlog and high counts in the testing states.  Work is batched up before and after development work.  Even though items are moving through development at a steady pace, there is very little flow of value since bug fixes are only tested and released to production in large, infrequent batches.

To further make the point, we could contrast the average development cycle time (2-3 days) with the average end-to-end cycle time (2 – 3 months).  If we desire a healthy software product and project, 3 month cycle times for bug fixes are unacceptable.

One of the top software project killers is lengthy feedback cycles.  The conversation around improvements for Project X could center around ways to reduce the feedback cycle between development and testing.  A potential solution would be to explore methods of automated testing.  The ultimate goal for our testing phases would be an enforceable WIP limit that would ensure flow of value to the customer.

You may be wondering why Project X uses such low fidelity tools (white board and spreadsheet).  There are very capable digital Kanban boards available.  Use whatever works for you!  White boards and Excel spreadsheets have a unique advantage, almost everyone has access to both in the workplace.

If you decide to try your own Guerrilla Kanban, realize that your effort is simply to create an environment where stakeholders have the tools to observe and make improvements.  As you begin to replace developer estimates with actual metrics, you will begin to build trust.  Once you have project visibility through the board and cumulative flow diagrams, you have catalysts for future process improvement conversations.

I hope this inspires you to start your own Guerrilla Kanban!

Wednesday, January 20, 2010

LWS Kansas City Dinner

We are having another Limited WIP Society KC meeting on Jan. 20 at 6:00 pm in the Overland Park, KS area.  Email me at tuttle.troy at gmail for more details. 

Tuesday, January 19, 2010

Speaking at the Lean Software and Systems Conference 2010

I was quite pleased to learn my Why Kanban presentation submission was accepted for the Lean Software and Systems Conference 2010!

I am very excited to meet and learn from some of the brightest thinkers in the Lean software development community. 

Want to learn more about Lean and Kanban?  Check out the speakers and topics at LSS2010: