#LK2009 Vale, Cook, and Landes

The day has certainly gotten off to a strong start. We are seeing lots of great practical advice on how various organizations have implemented Kanban systems in their organizations. I enjoyed the first few session of the morning and am looking forward to the next set of talks. This set bridges the morning and the afternoon. After this set… we’ll have three more speakers and close out the day.

Alisson Vale: Practical Experiences and Tools Applied to a Kanban Sustaining Engineering System

Alison is taking the conversation up a notch. His talk is explaining a very sophisticated approach to managing his Kanban process. There is no way that I am going to be able to explain to you guys the depth of complexity here… but I think I can share with you a few key takeaways that will augment some of the earlier session overviews.

I didn’t talk at all about David Anderson’s class of service discussion in his earlier talk. It was a really interesting point… but was discussed late in the talk and not fully developed. The main idea is that a Kanban card can have a class of service… an indicator that speaks to the risk associated with that feature. Does the feature need to be delivered by a certain date… is it an emergency request… is it a nice to have? All that kind of stuff is a class of service.

The reason I bring up David’s class of service idea is that Alisson had a slightly different take on class of service. Alisson sets up the conversation by establishing the idea that long term relationships require long term agreements and defines four types of agreements in his organization: problem solving agreements, support agreements, improvements for stability, and new value agreements. Alisson defines his class of service around the agreements he makes with his customers.

Interesting concept and I think you can see how these might play out in scheduling… and defining work in progress queues.

By establishing work in process limits around each class of service… we create predictability… we create flow… around each class and can mitigate risk by deciding how much to invest in each particular class. One interesting outcome of taking the Kanban approach is that you create a policy driven… metrics based… organization. Setting limits on work and giving the teams guidance about what to work on… when… and how… you actually empower the team to work without management intervention.

Another theme of Alisson’s talk… and this is starting to be an emerging theme across the talks… is the distinction between allocation vs. prioritization. This idea can be applied to classes of service AND for different types of business activities of features. If I am hearing correctly… what this tells me is that the team is allocated based on class of service and feature type… and then prioritization happens within those allocations.

Prioritization is not absolute across the entire backlog but only relevant within the context of a particular feature or service class. This is an important distinction because it allows the business to mitigate risk and apply resources to risk mitigating activities that might not otherwise make it to the top of a priority driven product backlog. Like most of what I am learning about Kanban this week… this approach gives us explicit mechanisms for managing our sofware organizations and get’s us past the typical handwaving about letting the team decide.

This is all about the appropriate level of constraints… and the appropriate level of guidance… constraints and guidance that actually empowers the team to operate in accordance with the overall business objectives. Alison’s talk was deep and detailed… it was impressive. Personally… I am still struggling to see how to apply this level of detailed management to the kinds of organizations that Dean Leffingwell is talking about.

Linda Cook: Crack that WIP – Introducing Kanban into an Organization

Okay… this was a really interesting talk. For one, the talk was centered around two infrastructure projects…. most everything so far has either been software or non-IT. To add another wrinkle, Linda’s last project with this team was done using Scrum but Scrum created too much process overhead for the team. She decided to introduce Kanban as a way to eliminate waste and to right size the process.

As I am listening to the setup of the project, she describes the team as a set of experts that didn’t want to estimate, didn’t want to do any documentation, didn’t want to use any user stories, didn’t want to do retrospectives, did not want to do sprint planning, and had no need to review their outcomes. They did not have… or need… a Product Owner and did not have a need for a ScrumMaster. I was left after the setup wondering what separated this kind of process from just an ad-hoc get-it-done attitude.

The team did track and measure task completion on the Kanban board and they did do a daily stand-up meeting. As Linda explained the process further, it seems that her team was really going for aggressive elimination of waste, measurements around the flow of tasks, and making sure the team was getting to done by minimizing the amount of work in progress. With no process controls, no estimating, no understanding of the backlog, and no baseline against which to measure flow… how would you ever know when you are going to be done.

That is probably more my problem that Linda’s problem. Linda’s method sounds great for a support team with a continuous flow of requests… I can’t get my head around how such a lightweight process would apply if there were any sense of constraints or controls… or if the team was less expert in getting their work done. I am hoping that either Linda or someone else from the conference will weigh in and help me understand this a little better.

Eric Landes: ChaMP Continuously Improving and Enterprise Development Group

Eric Landes has an environment that seems to lend itself pretty well to the kind of process I described in my summary of Linda Cook’s talk. Eric’s team was made of of 10 or so developers that were tasked primarily with handling a steady flow of services requests into the IT organization. The request… something he called a change request… is really what they were tracking as part of their Kanban process.

After implementing Kanban processes he was able to reduce the cycle time of a request from 41 days to around 9 days. This was done through the basic implementation of Kanban first and then by continuous improvement of the process and the focus on eliminating waste. Listening to Eric talk… the key to the success… like on most of these other talks… centered around limiting the amount of work in queue… and then subsequently work in progress.

Eric introduced a concept called a parking lot to keep track of all the work the team could potentially do. This work was pulled into the backlog, and at the point the item was in the backlog, it became in progress… this was the first and primary buffer. At this time they are not limiting buffer size within the WIP states. This seems to be because the entire team was developers. Eric is building disciplined practices around analysis and QA and could move to tracking intermediate states at some point… this could result in further improvement.

We had a pretty interesting side conversation around whether it is important to have a real visual board or is it better to use an electronic system. One guy in the audience… a master black belt… was a strong advocate for manual visual controls… Corey Ladas spoke up and talked about the use of large LCD screens in the team room area. Like most things… the answer is likely to be to very situationally specific. David suggested yesterday we use both as a best practice.

Kanban seems powerful… but is not rocket science. The common themes being expressed are really interesting. It is encouraging that we seem to have a somewhat common understanding of how this should be done. That said… the amount of variation driven by team characteristics and the local environment is powerful as well. We need to remember that none of this stuff… lean… kanban.. agile.. .is a one size fits all strategy.

Getting ready for the last three sessions of the day…