The year is a continuum, of course, and I can’t say that I didn’t do anything with respect to Kanban all year. My knowledge about the team and the method improved throughout the year, culminating in a Kanban “relaunch” in the new year. That’s been going well, and my current approach is much more in line with what the method prescribes, but that’s a subject for a different post. Today I’ll reflect on what did and didn’t work in the past year, and why.

First, I’ll cover the highlights. Even the very limp version of Kanban we were doing afforded us some structure to build on and learn from. With a visualized workflow and explicit work in progress limits, the team engaged in conversations around how much parallelization was too much and what the appropriate size of work items was. The beginnings of explicit policies emerged, blocked items were noted and prioritized, and the team successfully delivered on their commitments.

Now for what didn’t work. Explicit policies were few and far between, which led to the rehashing of several topics as well as too much unnecessary management intervention (tie breaking, direction, clarification, etc.). Metrics about lead time, cycle time, and work in progress were not kept – I always thought there would be a better time to start, such as the beginning of the next project, and worried about missing important metrics or recording useless ones. The lack of classes of service also provided some discouragement for data-gathering, as two different tasks in progress could be two orders of magnitude apart in difficulty. Without such data, our Kanban system was being used primarily for task management instead of as a process of evolutionary change. Finally, with a dedicated, embedded customer / product owner on the team, and with an existing culture of openness, there was no cadence at all. Releases, retros, and queue replenishment were all ad hoc, which prevented any rhythm from forming.

Although our work system is still, and will always be, a work in progress, all of the above difficulties have been addressed. I now have a month’s worth of data, spread across 5 classes of service. We have a weekly cadence for queue replenishment and retrospectives; we’re in the middle of a large project, so we no release cadence right now.  Policies are explicit and are up for review during the retrospectives, or during the week if the policy is wrong or dangerous.

My next post will outline how the team’s system works, some problems we’re still trying to address, and what we’ve learned so far.

I’ve done a few posts this year entitled This Week in Kanbandev. The stated goal of this series was to get me writing more and get me reading the excellent Kanbandev mailing list. It accomplished both of those things, but I don’t see a future in the series in its current format. I find now that, after killing off my backlog, I’m interested in reading Kanbandev again, but I’m now putting it off because the thought of boiling down an interesting, 80+ comment thread into a few sentences is not a pleasant one. Because of this, I’ve not done a post on the subject in two weeks, and haven’t really missed.

That all said, I really do enjoying reading the list and sharing what I find. However, sharing is a two-sided coin – I’d like what I’m sharing to be somewhat useful to people. My current format is so short that the only benefit I think someone would get out of it is to be pointed to the list. People who are interested in subscribing to the list will do so. People who aren’t interested in reading the whole list probably can’t glean enough useful tidbits from my summaries. People who are already reading the whole list will continue to do so and not bother to visit the site.

So, here’s where the Request For Comments comes in:

• What have you thought of the series so far?
• Do you have any suggestions for Kanban-related topics I could write about?
• Do you have any suggestions for a different format (perhaps a “best of the week” instead of a summary)?
• Do you have any Kanban questions that I could help you with?

Please leave a comment below, and thanks in advance!

• Inspections?

The originator of this thread has a client who introduced inspections at various parts of the process, with the stated purpose of improving quality. His is the only team in his organization that’s using Kanban, or any sort of Agile for that matter, so he’s trying to find a way to convince his client that his  process already has mechanisms in place to prevent defects. Eventually, it was pointed out that this conversation wasn’t directly related to Kanban. After all, since Kanban says nothing explicit about technical practices or defect prevention, saying that you’re using Kanban isn’t sufficient to pacify customer concerns about quality. The good news is that since the last project his team shipped did not use inspections – nor did it have any reported defects – this could be the start of a conversation about trust and metrics-based decision making.

• requesting help on myths of Kanban

Alan Shalloway is preparing a poll about commonly held Kanban myths. I love the idea of clarifying what Kanban is, not so much to maintain any sort of ideological purity, but instead to ensure that anyone trying Kanban benefits from the best practices established by the community. There’s discussion of common myths, some of which can be easily dismissed and some that require a bit more reasoning. I’m interested to see the end result of this work.

Following up on the Incremental Change thread from last week – the conversation did get better. People offered more clarity on their positions, and the tone improved. Several good concepts were discussed, such as the idea of “good practice” (analysis- or evidence-based) versus “best practice” (a community accepted standard / off-the-shelf solution), and the Cynefin framework. I had heard of Cynefin before but never really investigated it – I’m happy to see that creator David Snowden is a confirmed speaker at this year’s Lean Software and Systems Conference, which I hope to attend. All in all, the thread is likely a good reference for anyone struggling with the concept of standards, their proper place in a development / IT organization, and the difficulties that one can encounter when trying to manage shared knowledge.

Finally, it’s worth noting that the Wikipedia page on Kanban has been updated by several people, including myself. It was in a sad state before, but it’s looking much better now. Feel free to contribute if you have something to add!

• Incremental Change – How?

This huge thread is an offshoot of the “BVI was MMF” conversation that I touched on last week. The sub-thread originator raised some legitimate questions about whether the types of change that can be made  are different than, or perhaps even a subset of, the types of change that can occur through Big Change Up Front. The basis of incremental change in Kanban (standardized work that can be continually improved via experimentation) is challenged, going so far as to say that without a skilled coach Kanban is actually more difficult for a team to use successfully than a more comprehensive and prescriptive method such as XP due in part to the lack of standardized work. Of course, this dodges the fact that XP is a software development methodology whereas Kanban isn’t.
There’s some good conversation on this thread, specifically about the utility of standards (are they dangerous? required? a good idea? impossible in software?), but I found that it devolved a bit too much into mincing terms and arguing over definitions. Some of the side conversations were good – such as the discussion of how Lean is more of an evolution of Taylorism than a complete departure –  but I felt that this thread lacked a lot of the useful, experienced-based discussion that I’ve come to love from this group. That said, the conversation is still going, so maybe it will pick up.

• Emotions to motivate change

This thread was a spin-off of the Sense of Urgency post that I discussed last week. It’ s somewhat  on the same subject material, but it delves much deeper into the into the nature of resistance to change from psychological and experiential perspectives.

• using Kanban to improve flow in appointment booking

With only three posts, this was a very short thread, but I thought it was an interesting example of how Kanban (and Lean thinking in general) is applicable to situations outside of software development – in this case,  scheduling appointments for a consultancy firm. The original poster relays some changes that they plan on making by applying queuing theory and allowing slack in their booking system. David Anderson suggested a talk by John Seddon about Lean in a service organization, which I managed to dig up and add to my ever-growing “talks to watch” list.

Links this week – only a few, and I’ve already mentioned John Seddon’s talk above.

• A sense of urgency

Kanban is an evolutionary change system, and as such it takes time to decide and act on change. This thread questions Kanban’s incremental focus, as compared to literature and anecdotes that prefer a “big bang” change. Larger organizations may be interested in having a common development process, thus discouraging incremental improvement, and sometimes (such as when an organization is in dire need of immediate change), Kanban should not be the preferred method of change. This is followed by some interesting discussion of learning as a motivator (as opposed to urgency), examples of how Kanban can be a fast (though not instant) change agent, and the emotional aspects of change, including a reference to the Satir model of change that I’ve mentioned before.

• BVI was MMF

This was the most popular thread of the week, with over 40 posts at last glance. The crux of it was whether BVI (Business Value Increment) should replace MMF (Minimally Marketable Feature) as the dominant term used for a small, complete, useful bit of functionality, and whether there should even be a definitive term for such a concept. The concept has some detractors, who note that BVIs are almost necessarily variable in size, and such variability can disrupt flow. Several alternates are proposed, from replacing the term with “Smallest Responsible (or Valuable) Feature” (with the caveat that “feature” may be too heavily stressed for teams such as mine that have maintenance responsibilities), to supplementing the term with concepts such as a “Minimum valuable feature”, an idea borrowed from the lean startup movement. In the end it may just be a nomenclature thing – as long as the idea is well understood and explained, the exact term may not matter. Consultants, and those trying to convince others of the value of such an idea, may want to converge on the best possible term, but for people like myself who only have a small group to work with it’s the idea behind the term that’s much more important.

• Cycle time independent of story size? How can that be?

This was a rather short thread, highlighted by an experience report that saw cycle time (that is, the amount of “active time” spent on a task) vary independently from estimated story size, but instead saw it correlated to the start date – stories that were started later into the Kanban trial were uniformly shorter in duration, regardless of estimate. This calls into question the usefulness of estimates, which were being measured in story points (2, 3, 5, 8, etc.). Although the value of estimates may be an issue here, with too much faith being based on the precision of numeric estimates instead of a “big/small” comparison, the real issue could be that as time went on, WIP decreased. When WIP decreases, the cycle time of each item in progress decreases, as a direct consequence of Little’s Law.

In addition to the thread summaries above, there were some links of note this week.

• Bringing Excellence to Service Delivery (David Anderson, LESS 2010)
• Alan Shalloway’s blog post on Big Change Up Front
• A new Yahoo! group, Kanban for IT/DevOps

The initial goal of this series is pure self-improvement. It will get me writing, and it will get me reading Kanbandev, two things I’d like to do more of. Summarizing and explaining my reading will also help me solidify what I learn. These posts may be useful to some people, but that’s purely by accident . I can’t promise not to color my commentary with my own personal worldview, knowledge or experience (or lack of any of these), but I’ll try to call out any relevant biases when I can.

Now, onto the first week!

• Why should we size?

The value of estimation gets discussed quite a bit on Kanbandev. This thread reinforces the fact that Kanban doesn’t actually say anything about whether a team should estimate or not – if it provides value, keep using it. That said, there’s a heavy bias (possibly justified) on the list against using detailed estimates for planning. Personally, I’ve gone away from doing estimates for small, flow-based projects, and for larger batches of functionality I’m trying to shift towards using “t-shirt sizes” (Small, Medium, Large).

• Working on one item vs. multiple items

Limiting work in progress is one of the Core Properties of Kanban, so of course it gets a lot of mind share on the list. This conversation quickly turns into a pretty standard checklist of the steps to go through when trying to determine a WIP limit – keep policies explicit, measure lead time to gauge effect of changing the WIP limit, and keep stakeholders involved in the process and informed of the results.

• John Seddon about “Lean”

This thread got into the semantics of Lean, a mindset and series of tools that are in many ways a spiritual predecessor to the Kanban Method. The thread got a bit derailed by cries of commercialization, but it did spawn a great discussion on the topic of leadership – who are the leaders of Lean community? What does it mean to be a leader?

• Batching up releases… necessary or just patching over a symptom?

This was the most interesting thread of the week, in my opinion. I first heard of the concept of continuous deployment when I saw Eric Ries speak 18 months ago at the Agile Vancouver Lean mini-conference. The idea makes sense, especially with the “Stop Starting, Start Stopping” focus of Kanban, but there are differing opinions as to whether single-issue deployment is always a worthwhile goal to try to attain – for my current team, I prefer batches, albeit small ones. This thread also forked off into interesting discussions of the negative aspects of the phrase “Kanbanista” (summary – don’t use it, it fosters cliques and ossification), and what to do when your Kanban board says you’re overstaffed (summary – layoffs are sometimes the answer, although give new products a shot too).

Well, that’s it for week one. Next week, I’ll take notes as I go so I don’t need to re-read every thread of interest!

Kanban is pretty simple (with respect to core rules / definition), but it’s not as simple as “just put up a board and some numbers.” Just visualizing your workflow can be a catalyst for change, but a Kanban system needs more than that. Straight from the horse’s mouth, the core practices of Kanban are:

1. Visualize the workflow
2. Limit Work-in-progress
3. Measure and Manage Flow
4. Make Process Policies Explicit
5. Use Models to Suggest Improvement Opportunities

This is coming from the guy who literally wrote the book on Kanban and has toured the world popularizing its use, training people, and watching Kanban successes and failures.

My friend’s company routinely violates WIP limits (“it’s been this way for several months” or something to that effect), and that never provokes a discussion about changing the limit or analyzing the cause of the broken limit. Product management has not fully bought into the system, seeing it instead as a generalized queue. Developers are rather independent (no development manager), and apparently sales has not been pushing for any SLAs, so no one has bothered to analyze flow, measure lead / cycle time, or anything else that can drive toward systematic improvement based on what the board is telling them.

Now, this is not to pick on my friend’s company – he’s a bright guy, as are others he works with. I’ve seen this within my own company as well. I routinely walk by other people’s Kanban boards and say “Hrm, WIP limit 4, 5 items – what’d you decide to do about it?”, which usually prompts some action. Some teams are trying to implement specific policies / standardized work, and I’m the only one that I know of trying to analyze lead and cycle times. Even there, I’m not doing everything that I could do. And yet, I still here Kanban being touted throughout various bits of the organization as “the next big thing”.

Why does any of this matter? Well, it doesn’t, really. Unless, of course, you actually want to get the most out of your system. Presumably, these teams adopted Kanban for a reason – they liked the idea of flow, had seen success stories, and wanted to see what they could do to improve their organization. Is that not still the case? Using Kanban “properly” isn’t that difficult technically, it just requires a bit of buy-in, social capital, and a willingness of people to examine the situations they find themselves in and look for improvement. It doesn’t personally bother me if you’re doing Kanban “wrong”, any more than it would bother me if you were a birth-control using Catholic or a beer-swilling pork-eating Muslim. I just think that Kanban, when used properly, can be a very powerful change catalyst, so if people have a passing interest (enough to adopt the term “Kanban”, at least), I’ll help them out if they want me to.

I’ve given quite a few talks, but they’ve always been to groups of students, and usually groups of students who aren’t necessarily interested in what I’m talking about. I’ve given several talks that amount to a basic introduction to Agile, but often this was to a class of students who weren’t in the process of learning about software development methodologies so the material didn’t resonate. My most recent student talk was to a software engineering class, so that was a bit better, but I found that I was simply explaining what Agile was to a group of people who have never experienced the problems that Agile is trying solve.

The Vandev presentation was about using Kanban as a way to improve your software development process, and the material was directly relevant to people with experience in the software world. This was also the first time where I’ve really tried to move away from that old standby of PowerPoint, the *shudder* bullet point. I had only 13 slides total, including my title slide and a “more info” slide. The slides contained much less text than previous presentations I gave, and I felt they really served as a multimedia element to the talk (animations illustrating Kanban flow) as opposed to a visual crutch.

I’ve got another student-focused talk coming up in November, and a UBC Alumni Series talk lined up for March. I plan to continue to move away from boring slides, and am looking forward to how my new presentation style goes over with both students and professionals.