I presented the attached PowerPoint at the last Lean & Kanban Socal meetup describing our success using Kanban for both our release process and for software engineering.  Unfortunately images have been removed since I do not own rights to them, but there’s still some good information there along with a timeline describing our rollout.

We’ve had pretty amazing success with Kanban so far so this is more a success story than anything, but we still had some interesting lessons learned that were worth sharing.

Very funny DailyWTF today: http://thedailywtf.com/Articles/In-a-Barrel.aspx

Doug’s PMO has begrudgingly agreed to move from the Waterfall model to Agile. They’ve been working through a project plan to make the transition, but unfortunately, it looks like they’re still a long way off..

Click through the link for the punchline.

I’ll be presenting a case study on my experience rolling out Kanban at CityGrid Media (both for release management and for software development) on the 14th. If anyone is able to make it please come by and say hello!

More details at http://bit.ly/cb9go0.

My engineering teams recently switched over to Kanban, and we’ve been having great success ever since.  One of the things I never fully understood until today, though, was how you tune your WIP limit.  My team had been using a WIP limit factor of 1.5, meaning that for every developer there were 1.5 stories in progress.

We felt this was a reasonable approach; that keeping a high WIP limit would ensure that there was always something for everyone to do and people wouldn’t end up idle.  We were using three service classes to organize the work – production support, product development, and maintenance class.  Things seemed to be going pretty well, and they largely were, but this approach carried significant risk that we ended up paying for today.

I track cycle time as well as a total completed story points for every release, and I noticed that with today’s release we had a significantly higher cycle time and finished about half as many points as we usually do.  Shocked, I took a look at our work in progress on the board and noted that we were at our standard WIP limit of eight.  What was different this time, though, was that almost every story on the board was large: 13 points or more.

For six developers, we had 66 points in-flight.  Digging deeper, our cycle time on a per-story basis had gone through the roof.  Because the stories were so large, and there were so many of them, we ended up leaving a lot of work on the floor when the release, which occurs on a regular two week cycle, arrived to pick up whatever we had finished by then.

As students of Lean, I’m sure many of you have seen this type of diagram before.  It illustrates that by completing work serially rather than in parallel, you can deliver value to your customers faster.  Well, today really brought this point home and in doing so I learned a lot about WIP limits in Kanban.

Part of the benefit of keeping as low as possible WIP limits is that you allow your developers to swarm around as few large in-flight items as possible, ensuring you:

  • Get more eyes on a single feature to ensure quality and shared understanding.
  • Reduce cycle time on individual stories (maximize developer participation), both reducing the average amount of time spent on stories and ensuring that as many items are deliverable to customers on a given day as possible.

Because we transitioned from Scrum, our product team was used to seeing a large body of work in progress that had been committed to at an earlier date that would end up getting delivered as a release; to them that’s what a team being successful at delivery looks like.  In an effort to ease the transition into Kanban, and also because I didn’t see the risk, I went along with higher work in progress limits so that things generally looked similarly to what they saw as efficiency.  Now I realize this is a dangerous approach that should be avoided.

Instead of using the classes I mentioned above (production support, product development, and maintenance) we are now organizing the WIP rules around the size of the stories (we’re using fibonacci numbers, and this is roughly what breaks down to large and small for us).

  • Large Story – Any story that is 8 points or larger can be worked on with a WIP limit factor of 1/3, rounded down.
  • Small Story – Any story that is 5 points or smaller can be worked on with a WIP limit factor of 1/3, rounded up.

Our WIP limit factor is now significantly smaller – instead of 1.5 developers per story, we now have .66.  Any excess capacity on a day-to-day basis is soaked up on testing automation, but under this new approach I expect to see cycle time return to normal levels and a much reduced risk of incomplete work at code freeze.  Additionally, we’re balancing our work around the way we actually do work – we want more smaller stories in progress since typically a single developer can work on them, but at the same time we want to see developers swarming around the larger, more involved stories.

I learned two things here.  First, that Kanban really does either require stories to be a consistent size or, if you do want to use size variants on a single board, that you account for this in your rules.   The second thing I learned is that when you keep artificially high WIP limits, even with good intention, you are not likely doing anyone any favors.

I came across a great presentation on using Kanban for video game production on InfoQ, and I have to say it was quite refreshing to watch.  It’s great to see industry veterans like Clinton Keith recognizing the need for continuing evolution in process at a time when many companies seem to have come as far as Scrum but have not quite continued to innovate.  As cost of development continues to skyrocket, there’s an opportunity for effective, Lean and Agile-minded leaders to step up and trailblaze a new path.

Watch the presentation at http://www.infoq.com/presentations/kanban-video-game-dev.

Registration has opened for the 2010 Lean & Kanban conference in Belgium this summer, and I’m lucky enough to be attending this one.   The lineup looks great, with David Anderson, Mary Poppendieck, Alan Shalloway, and many other great Lean thinkers giving presentations over a two day course on September 23rd and 24th.   Check out the program, and definitely let me know if you’ll be there so we can arrange a meetup!

The first Lean Software & Systems Meetup (SoCal) will be on July 12th at the CityGrid Media offices where I work.   There should be some great discussion on Kanban and other engineering/technical process.  Hope to see you there!

I came across a good article on building technology teams at http://leanstartups.com/putting-together-strong-technical-team.html.  In particular, I thought the foundational principles that the author listed were great:

Strong talent in a small team can be far more effective that average talent in a larger one.
Well directed and motivated expert teams execute effectively. They tend to need more tender loving care because they can be precious about their output, but this is a small price to pay for the results that can be delivered. You will expect to pay that expert talent more, but you can offset that by recruiting fewer people.

Try to operate like the team is a small start-up
The by-product of creating this environment is that the team feel they can operate outside of the “red tape” that besets many larger organizations and start to get creative and innovative. Typical examples are removing all the “lock downs” that most corporate organizations enforce on company provided hardware. This doesn’t mean that it’s a free-for-all – the environments should be well thought through and consistent. Also allow the team to work on a flexi-time basis.

Have a strong leadership team that is transparent
If the team know their leadership have their support and trust them then they are less likely to want to fail and will go beyond the cause to get things done and done right. A leadership team that shows they have direction and can speak to the team about it, can be open an honest about how things stand will have the respect and therefore the backing of the team – this loyalty is an extremely valuable commodity.

Cultivate the environment where everyone matters
Empowering the team and ensuring that everyone feels more than comfortable to give an opinion to anyone in the group at any level. This creates an environment where people get passionate about their work and team.

Shield the team from corporate noise
Avoid team members getting caught up in meetings etc. that take away their time from doing the work they love. This is a value add that they will respect you for.

Communicate!
Create effective communication strategies – canvass the team about what sort of information would be useful. Have at least one team meeting a week and consider having a “beer Friday” once a month – take the team outside of the work environment and let them talk. It’s amazing what you’ll find out!

Check out the article for more tips, including specific advice for hiring various roles.

First of all, I wanted to announce that the scope of this blog might be growing a bit; I was recently promoted from the Release Manager at Citysearch to Engineering Manager for several teams working on our advertiser platform. A lot of the reason I was promoted was because of my experience in process development, so there will still be a lot of correlation between the original content and where we go in the future, but I’ll definitely be growing and talking about new subjects with relationship to the broader organization.

In that light, I wanted to talk about my experience moving my software teams from Scrum to an iteration-less form of Kanban. My CTO, Christophe Louvion, provided a nice high level summary at http://runningagile.com/2010/05/31/a-few-weeks-of-kanba/ based on feedback in a presentation one of my teams gave, and I’m going to expand on the list:

Stand ups differ – going story by story, not based on individuals
The story-based focus, where we start at the right of the board and focus on how to move stories into the “complete” column, has encouraged the team to be more collaborative in analyzing, executing, and testing their story implementations. Previously, the teams were going down the list on the first day of the sprint and assigning items out one at a time in an effort to essentially maximize their work in progress. Unfortunately, this was pathological in that it ensured that only one person knew the implementation for that story (and that you were done if that person ended up getting sick) and that it discouraged the team from swarming around one or two items. Now, everyone on the team is aware of what the entire team is working on and can share the load as needed.

Less Rules: No roles prescribed, More Dynamic
This speaks to the core Kanban idea that the process itself is something that is being engineered and tailored to the team; the team feels that they don’t need to have roles (such as the Scrum Master) that the team has in many ways grown out of the need to have. If they are mature enough to self-organize, they are more than welcome to do so – and they are.

Backlog more Flexible
If you’ve ever worked in advertising you know there are a lot of stakeholders out there and when deals get done they need to be implemented irrespective of any two or four week sprint cycle. The flexibility of the “to-do” list in Kanban allows our product team to reprioritize any work that the team has not already started development on, which in turn gives the product team the ability to ensure we’re always working on the latest requirements from the business. Everyone knows they are working on the latest and most important features and that means real value when we deliver.

Pros: Better Team Focus, Less Meetings More Time to Deliver, More Flexible Work Process
Again, the second two points here speak to the ability of Kanban teams to tailor the process to themselves. The first point, however, is really worth digging in to. In my opinion, the increased team focus comes from the participation of the team in engineering their work process. Prescriptive methodologies such as Scrum, although good general rules for many teams, do not necessarily require the team to understand the why behind many of the reasons that the process is the way it is. In fact, they are designed so that even teams who do not understand the whys can be effective. In contrast, because Kanban drives change from within the team, the team is encouraged to experiment with the process (even making mistakes, as long as there are lessons learned), which results in a team that understands at a very deep level what works for them, and why. On my team Kaizen events have jumped significantly now that the team understands the process and knows that they are empowered to make changes in a safe environment.

Cons: Less Structure Could Cause issues with Some People
This is one item that I’m still learning a lot about. Kanban does seem like, much more than Scrum, it requires leaders at all levels in the organization to drive the positive process change. I’ve been on a couple different teams that were learning Scrum as they went – I’m not sure that Kanban is capable of working for teams at that level. It simply provides too much flexibility to the team and much of the guidance asks you to analyze your specific situation rather than reading out of a playbook. That said, I haven’t actually tried Kanban yet with a less mature team so my data is incomplete here.

How Its Working Out: Feels Good, Increased Our Collaboration, Communication Has Increased, Forces Follow Up to Eliminate Blockers
“Feels good” is another important component. If you saw the last video post I made, you know that two of the major elements that motivate people are autonomy and mastery. Kanban provides these in that it trusts the team to engineer their process in a way that works for them – the methodology is not from “on high” and passed down to them to execute; instead they are an integral part of the process. We hire smart people who are good at engineering software systems, it turns out those kind of people have an intuitive sense for engineering process as well. The Kanban board and metrics provide a visual way for the team to see that things are getting better and to know that they are leading themselves to an increased level of mastery.

All in all, moving to Kanban has so far been great for the team. We’ve only been experimenting with the new process for a few weeks now, but already it seems like things are on an exciting new trajectory. I’ll be updating this blog with more details on how things are going as we continue to learn and grow.

Follow

Get every new post delivered to your Inbox.