Geek Philosophy

This week was a bit of a slow one on the list, but it made me realize that I’ll never be able to summarize every interesting thread on busier weeks. As such, I’ll commit to commenting on at least three. 

• 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

Buoyed by the success I had in sticking to a post-a-day schedule in November, one of my “end of year personal goals” (new year’s resolutions, you might call them) is to write more. Another goal is to keep more in step with the current state of the art of the Kanban community. Combine the above with positive feedback I received about my summarization ability, and you get a new series - This Week in Kanbandev, a weekly update where I discuss some of the happenings on the always-interesting Kanbandev mailing list. 

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!

After seeing the pile of books I want to read grow and grow, while not actually reading anything due to indecision of what to start next, I’ve decided to implement a reading kanban. I’ve never really used a personal kanban, but I thought that having the titles I want to read laid out in front of me (sorted by category) could spur me to action.

To start out, I think I’ll have allow myself to have three titles in progress - one fiction book, and two books out of the three categories of technical, business, and personal growth. I’m already well into a personal growth book (How to See Yourself As You Really Are), and I’m just starting a business book (The Five Dysfunctions of a Team). I have a raft of technical and business books to choose from, but limiting my WIP will ensure that I actual finish some of them. I only have 2 or 3 fiction books that I’m considering, so I’m less concerned with burning through those.

I’ll try to write up my thoughts on any books I find particularly interesting, and will also try to report back in a few months to see how the book kanban is going.

A quick Google chat with a friend of mine today about his company’s implementation of Kanban got me thinking - how many people out there who say they’re using Kanban actually know what it is? They may know there’s a board, and maybe some limits, but is that it? Of course, I can’t change what people in general think, but I can certainly work to influence those around me. This post is part of that effort.

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.

Last Monday I had the chance to talk to Vandev about Kanban. The talk went pretty well (Meetup even gives a rating and feedback system), and there was a lot of interest in the room. It was a rather short talk, 25 minutes plus a half hour or so for questions afterwards, but the crowd seemed to really enjoy it and there were a ton of good questions. What’s interesting is that this is the first time (that I can remember at least) where I’ve spoken to a group of professionals.

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.

David Anderson