Kanban and software production

A colleague of mine suggested this week that we attend a SyncNorwich event on Kanban.
We all really enjoyed the evening, although some of us found the round-robin introductions a little uncomfortable.

As a team, we had introduced the Kanban approach back in February this year, and it seemed to be going well, but we were curious to learn how far we might have strayed from the rest of the herd. Before the presentation at the Kings Centre, in the company of our MD and Principal Architect, I was feeling a little excited, and a lot nervous. We were about to find out how esoteric our implementation had become (yes, I do mean bad).

For the uninitiated, Kanban is of the "lean" school of thought. Of all the methodologies it is the least prescriptive, in that more or less anything goes. The essence of Kanban are the "signal cards" and the rules that we attach to their transition. Kanban is extremely easy to pickup, and has more than a thing or two in common with the kind of card based drinking games you might have played at Uni, or in my case, hosteling.

I picked up the Kanban bug 2 years back whilst I was working at RBI. There was one particular team that struggled to implement Scrum due to the unpredictability of their workload and decided to try Kanban instead. This team was widely known within RBI for being a bit grumpy, and a kind of fatalistic culture had taken a hold. Scrum, wasn't working, if anything it was actually damaging the team. Eventually, Mr Rami Hatoum was brought in as a consultant and he introduced the team to Kanban. What surprised everyone, including the team in question, was how very quickly this beleaguered team transformed it's opinion of itself, and how this new wave of positivity was felt throughout the business. Just before I left RBI, I went and spent a few hours with that teams principal developer, Mr Rob Callaghan who gave me a very detailed walkthrough of their implementation and how it had gone for them. I still refer to those notes even today! Thanks Rob ;)

I'm not suggesting for a second that Kanban is a panacea, or bandwagon for everyone to jump aboard. The purpose of my anecdote is to underline that on this occasion it was the right tool for the job. There was a team who perceived themselves as failing principally because Scrum said so.  In reality, the nature of their work didn't fit the Scrum mould, their customers couldn't be marshalled into the discipline required by Scrum, and it was the team that felt the adverse effects of this.

The thing I really like about Kanban is that its so flexible, so non-prescriptive. You are positively encouraged to "make it up" as you go along, to evolve your practices over time. Of course, this is more professionally termed "Continuous Improvement". The business of CI is crucial to the success of a Kanban implementation, and should be conducted as scientifically as possible, with every alteration subjected to some form of peer review and conclusions supported by empirical evidence. You need something more substantial than mere "opinion" as to whether something worked better, or worse than before. Without concrete evidence to support a claimed improvement, reputation and morale may suffer.

But, the key to Kanban is not to obsess over it, its just cards, and simple transitional rules. Most Kanban implementations, ours included, beg borrow and steal from more prescriptive methodologies like Scrum . We have taken only what we need to get things done. The rules? Are literally made up as we go along! Or to sound more professional, the rules evolve over time using a process of Continuous Improvement (Kaizen). We borrowed from Scrum the "retrospective",  a fortnightly team forum to discuss and evaluate our practices. We also borrowed the daily stand up, another quick forum that helps the team to solve or better-yet, avoid production problems.

So when it comes to Kanban, just throw some columns up on a board or a wall. You can expect it to change radically in the first few hours, days and weeks, gradually evolving into a well-honed workflow.

Our Kanban board is now 8 months old, and we've not made any changes to its structure in a good long while, but in the early days it was tremendously fluid. Is it perfect? of course not! I think we need to review our WIP limits and do more to overcome the work-push mindset that still endures, but, everything in time.

So, back to Benjamin Mitchells presentation on Thursday. Ben's presentation was funny, thoughtful, engaging and even a little self-deprecating. I particularly liked the impromptu Kanban board he thew up on the wall to track the progression of his presentation. If that didn't hammer home the simplicity of Kanban to the audience, I'm not sure what else would!

If I hadn't heard of Kanban, Ben's presentation would have surely tempted me to try it out. I particularly liked how throughout he put the emphasis on people, how something affected them, how it helped them, all to often this aspect is over-looked when thinking about how people should work. As a survivor of my own nervous breakdown, I can't welcome Ben's humanist approach enough.

One thing I'd really hoped for at the talk was to learn more about how to deal with the politics of change, and Ben certainly had a lot of knowledge and experience through his consultancy roles of implementing radical change into a resistant culture.

Sadly, Ben's talk didn't quite get that involved in the psychological aspects due to the strong audience participation during his introduction in to the mechanics of Kanban. After a rapid exchange of Tweets, Ben provided me with plenty of material on the psychological aspects of implementing Lean and Agile methodologies.

Ben provided me with a link to this video,  LSSC12: What comes after visualising the work? Conversations for double loop changes in mindset - Benjamin Mitchell.

I need to watch this video before Monday, as I feel a big push is coming.

Apologies if you'd read an earlier version of this post, I thought I'd merely saved it for later! :)