The Kanban paradox

I’m a big fan of David Anderson’s Kanban method, I always said my brand of “Agile” was heavily infused with Lean before David presented Kanban. In the same way that Kent Beck said Extreme Programming was about “turning the dials up to 10” David turned the Lean ideas behind Agile up to 10 and in the process dropped a lot of we (the Agile community) had come to regard as accepted wisdom - stuff like iterations and estimation techniques.

From my vantage point, sitting on the side of the Kanban community all these years, I’ve noticed two trends. Firstly Kanban as stripped itself down. I seem to recall someone saying the way to start Kanban was to “visualise your work in progress and take it from there.” Second, Kanban has relaxed its focus on software development. It now bills itself as a management method or even a “change management” method. The net result is that even as Kanban itself has slimmed its applicability has broadened.

Stripping away non-essential elements makes Kanban simpler to communicate and understand but at the same time says less about what you should actually do. Kanban is getting closer and closer to its Lean roots. I’ve long considered Lean to be more of a meta-method than a method, that is to say: Lean doesn’t tell you how to work (unlike say Scrum) but it tells you how to think about how you work. I sometimes say “Scrum and XP tell you what to do at 9.30am tomorrow morning while Lean tells you how to think about what you will do at 9.30 tomorrow morning.”

I have no disagreement with the way Kanban is going, I still like it as an approach and I think the people who are changing it are doing the right thing. (The opportunist side of me might even reason that as Kanban distances itself from software development it leaves a gap in the market that Xanpan is ideally placed to exploit, but that would be incredibly cynical of me and risks all my credibility!)

(I should mention that while I’ve been invited to a couple of Kanban “Leadership Summits” I’ve never attended, a combination of my natural Groucho Marx tendency and family commitments means I’ve opted not to contibute.)

But… and here is the meat of this blog post…. I think the way Kanban is going creates a paradox.

As Kanban gets briefer and smaller then implementing Kanban requires more expert knowledge.

You can put up a Kanban board and track your flow and work in progress. You can set WIP limits. But if you don’t know how to read the board you don’t know how to act on it. And if you do know how to read the board acting on it isn’t always a rationale engineering discussion: acting on the board often involves office politics.

For example, I once helped a company create a Kanban board with many (too many) steps and (too) many queues. After a few weeks the problems were obvious. But instead of acting to remove the problems the board was used in evidence to apportion blame.

Kanban can generate many metrics: cycle time, lead time, utilisation, etc. etc. But if you don’t know what these metrics mean they are pointless. And even if you do know what they mean knowing how to act on them is another matter.

For example, Kanban relies on queueing theory, some of the things queuing theory suggest you do is counter-intuitive like reducing work in progress, and therefore worker utilisation to speed throughput.

Sure you can learn queueing theory, you can read the books, you can learn about metrics, you can reason about your own board but these things take time. Even then I doubt if any book, course or programme can give you the knowledge and understanding that comes form experience, from seeing it done before and from seeing multiple implementations.

In at full-throttle Kanban teams dispense with iterations and estimation. They substitute statistical analysis for estimation - and I believe that is a “better” approach but that also requires a good understanding of statistics. Most people are pushed to remember one distribution and when they do its standard-distribution but software work is unlikely to follow standard distribution so unless you know there are others you will come unstuck.

Then take value, Kanban - like Lean - aims to enhance value. But how do you define value? What is valuable to your organization? Is value quantity? What do you do when you can’t put a dollar amount on value? Someone needs to understand value and how to work with it.

And then there is software development itself. Implementing Kanban in a software development environment has many more issues. You need an understanding of quality, an understanding of software products (features or solutions) and more - even before you get to the technical stuff!

To my mind this makes Kanban difficult. It requires expert knowledge. Sure you can learn this stuff - book your Kanban course now! - but it takes time. I started studying software development properly in the reading room of Liverpool Library nearly 30 years ago and I still don’t know everything.

And its not only my study of software development that I find essential in helping teams with Kanban. Years spent studying economics, years spent reading management books and yes, time spent at business school earning a degree so many in our profession (not without reason) rubbish but which equipped me with understanding I use regularly. When I help teams with Kanban I draw on all these sources.

Sure this is good news for me, it makes work for Agile/Kanban Consultants (sorry, Coaches) but it also makes harder for non-experts to practise. And most people trying to do Kanban are experts in software technologies not process and flow.

So here is the Kanban paradox again: as Kanban gets briefer and simpler practicing Kanban requires more expert knowledge.

The beauty of Scrum and XP was that you could practice them quite well without expert knowledge. You may never be the greatest team on earth but frankly most businesses don’t care about that, they want something (anything!) better than what went before.

You don’t need to be great at Scrum/XP to get benefit: stick to a two week iteration cycle (most of the time), get a clear steer on work prioritisation once every two weeks, hold some kind of regular meeting, thats about it. Sure its good if the stand-ups a short, if you don’t work from a requirements document, if you do retrospectives, and especially if you do some of the technical practices. But, just doing the basics it is democratic and everyone can understand it.

Scrum and XP made the development process accessible to those who practice it, they can reason about it. Kanban done well is far far better, but Kanban done badly, without understanding? I suspect it is dangerous.

I’m not sure Kanban is the same, I think understanding Kanban requires a lot more understanding, therefore Kanban is not democratic, it is more of a management method, more of an experts approach. And this its a paradox.

And what of Xanpan?

Does my Xanpan approach suffer the same problem?

Well maybe, but I am the worst person to ask, I’m biased. Xanpan is “the way Allan Kelly does it” - well, it was, a few others are now trying it now. Maybe Xanpan does, after all Xanpan tries to have its cake and eat is, I give detailed description of how to do Xanpan but at the same time say “make your own method.” I sincerely hope I can keep Xanpan democratic.

Maybe Xanpan is just a training version of Kanban. Maybe Xanpan is a cut down Kanban, maybe its a neutered Kanban. Maybe when you’ve practiced Xanpan for a bit you can mutate so its more Kanban. Anyway, who cares what you call it.

Managers are not homogenous

(If you are not a coder please bear with me…. we’ll get to the business point in a moment.)

When a programmer finds a class named Manager in a code base they know - or at least should know - that it is probably a smell. It might be innocent but until proven so it should be considered guilty.

For example…

SecurityManager

LogManager

DatabaseManager

I’ve written a few of these myself in my time, and I may even write some more in future. But that does not make them good.

The problem with “manager objects” is that they are usually a vaguely connected set of functionality which either deserves a better name (SecurityValidator, Logging, or some such) or they are worth breaking up into multiple classes each of which has its own clearer purpose (DatabaseUser, DatabaseConnection, DatabaseFinder….). And sometimes, some of those functions would be better off as a stand alone function not bundled into a class because it happens to share part of a name.

Now let me suggest the same is true of job titles and roles which include Manager in the title.

For example: I am writing this on a train, my ticket has just been checked by the “Train Manager”. This is a position that used to be called “Train Guard.” I must assume that the Train Manager’s job entails more than just checking tickets, similarly the Guards job entailed more than just loading the guard van with good.

Does the Train Manager have the authority to order the train driver to pass a red signal? - I don’t know but I assume (and hope) not.

Does a Train Manager have the authority to order the catering crew to reduce prices? - I don’t know but would expect prices to be decided centrally or for catering staff to have the authority - perhaps under standing orders - to reduce prices under some circumstances.

Personally I prefer the old title “Guard” but perhaps there is some reason - other than presentation - why the position is is no longer called a guard. But since I have no deep insights into exactly what actions this person undertakes or what their responsibilities are I can’t really comment.

In the same way that I don’t really know your code base so shouldn’t really comment on your class naming. However, I can say, that given my limited knowledge I detect a smell.

Now there are a lot of people in the Agile community who are very anti-manager. They see self-organizing teams etc. as a way of removing managers. While I have understand their position and think maybe some “managers” would be better removed and the teams allowed to “get on with it” I don’t think its that simple.

But I also think when developing software, when doing many other activities too, and in an organization, be it big or small there are often many vaguely related things what need to be looked after. Big organizations tend to have more of these than small because of their nature. Some of these things that need doing are the result of people inside the team and some from outside. Resolving many of these things requires being in possession of information, it requires a degree of authority and more importantly competence. What do we call someone who deals with all this? Well, a Manager.

For a few years I’ve been trying to find the time and energy to write a comprehensive blog series on the topic of managers in software development but I can’t. I see another land mine, if I weigh in on this debate I expect both sides will attack me and neither will really appreciate my position. So you may have to wait a bit longer but I think the above discussion illustrates an important point…

The formal title of “Manager” (and even the informal use of “Manager”) hides a lot. Some of those roles, like Product Manager or Build Manager, can be quite focused and specific. But many of those roles are catch all roles with mixed responsibilities which may, or may not, be better filled by a specialists or by devolving authority to do the work to others.

Some of these tasks - like checking tickets on a train - should not be needed and should not exist, everyone should buy a ticket and pay the fare! Much of the train manager role is because we don’t live in a utopian socialist society. (Although history shows managers were just more to running of socialist societies as capitalist ones.)

So please, before anyone tries to remove a manager please examine what they actually do, and whether the role would benefit from a better, specific title. Or whether it actually makes sense to have a someone catching all the other stuff in a vaguely defined role.

Agile on the Beach voting procedure

Nothing exciting but to save me from explaining this again and again….

Yesterday the Agile on the Beach conference committee finalised the speaker lineup. I’ve just this morning sent the acceptances and the “Sorry” e-mails. Since there were about 150 submissions and only 41 slots to speak in we cold only accept less than a third of the submissions - even fewer actually because some sessions are doubles.

Here is how we came to our decisions.

We have five committee members - you can see who on the website. Each of these was given electronic copies of all the submissions - including long and short synopsis, speaker bio, travel origin (implying how expensive it might be for us to bring someone in) and other details.

Each committee member independently scored each submission on a scale from -2 (I don’t think this should be at the conference) to +2 (I really want to see this myself.) By making Zero the default any reviewer who didn’t review a session or felt they did not have the knowledge to pass judgement didn’t bias the results. Sometimes reviewers made a comment as to why they had given this score but not always.

I took these scores and added them together. In the first review meeting (two weeks ago) we reviewed the total scores, debated a few sessions and the top scoring sessions were short listed.

In the product track 17 were shortlisted, business 13 and for the team track 27 made the shortlist. Again each reviewer independently reviewed the shortlist. Software was slightly different because we again decided to make extra space to keep our technical side, more to follow. Since Product expanded from one day to two days this year it means the conference has grown again.

But this time instead of scoring the sessions reviewers ranked them. Each track has 9 sessions (if all are single) and each reviewer ranked the sessions knowing this.

For the second meeting I took these rankings and averaged them for each session then in each tack ordered the track. At this point we had some clear accepts. At the 9 mark things became fuzzy, in one track we had a double in position 9, in another track one person had three slots in the top 9 and so on. So some manual adjustments were made. We also made a call on some things we thought should be in the conference or developed mini-themes.

In the end a lot of sessions didn’t make the cut simply because they were out competed. Everything that made the shortlist was strong, a lot that didn’t make the shortlist was strong too. We just don’t have space for everything we would like and can’t expand the conference every time, sorry.

Anyway, I hope that explanations helps.

Thoughts on 6-Sigma and Agile

Question that comes up from time to time:

"Does anyone have Agile project which is Six Sigma? How these two things Six Sigma and Agile complement each other on software product development project? “

My answer:

In theory Agile and 6-Sigma should fit, they both have their roots in the quality movement.

A cursory glance at the 6-Sigma toolset reveals similarities to the Lean toolkit - continuous improvement, root course analysis, statistical methods, so at first it looks good but…

While there are a few stories of Agile and 6-Sigma working successfully together my own experience, and the majority of the stories I hear are that they are contrary.

Let me briefly share my experience....

I did some work with a financial services company which was a big believer in 6-Sigma. Any change had to be set up as a 6-Sigma change, with a business objective, current status measurement, target, approach, etc. Its difficult to argue with such a rational position but it was hard to pull all these bits together.

The change then needed to be signed off by more senior managers as a 6-Sigma effort. And it was hard to get the necessary managers in the same room at the same time. Which meant efforts didn't get signed off.

And with all this effort you needed to put a lot of effort into any change which meant even thinking about change was expensive.

The net effect was to freeze the status quo. Six-Sigma had the effect of preventing change not supporting it.

On a day to day level the attention paid to variance was highly detrimental. Teams adopted behaviours designed to minimize variance (e.g. differences between estimated effort and actual effort) which both made measurements unreliable and made people wary of any change, experimentation or risk. (They had bonuses related to variance reduction.)

It seems there are some big difference between 6-Sigma and Agile, if not in intent then in implementation:

• 6-Sigma is very top down, Agile is traditionally bottom up (although this is changing)
• 6-Sigma is process and plan driven, 6-Sigma demands evidence; Agile is more “experiment and see what happens”, in other words Agile is happier with failed experiments
• 6-Sigma demands study from its devotees (all those belts!) while Agile benefits from study it is a free-for-all when it comes to what to do (this may well be a disadvantage)
• 6-Sigma anoints experts (black belts) while Agile is much more egalitarian (or at least should be)

So while Agile and 6-Sigma may have somethings in common they are culturally incompatible.

And as for the newer mutant form of 6-Sigma known as “Lean 6-Sigma”, well let me quote something I heard Dave Snowden say at a conference a couple of years back:

“Lean 6-Sigma is about removing all the waste that 6-Sigma introduces.”