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.

(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.

I’ve written many many times in this blog about Dialogue Sheets. On the whole I offer dialogue sheets as a retrospective technique. However they have other applications, for example:

• The Agile Discussion sheet serves to help teams decide what Agile practices they wish to adopt. I use this to close training sessions and I’ve seen teams move straight from training into using some of these practices. I credit this sheet with some of this success (Oh, and my brilliant training course of course, plug plug.)
• The Planning Meeting sheet helps guide teams new to Agile planning meeting through the planning process.

I’ve long believed Dialogue Sheets can help on the requirements side too but until recently I’ve not had a chance to try this. Now I have.

Last month the Victoria Wiggins and Rosie Curran at Nature.com offered one of their teams as guinea pigs to try a new sheet. The session went well, the team had about 2 hours of discussion and they even provided lunch. Thank you very much!

After observing the team discussion around this sheet I’ve made a number of modifications. Primarily I decided to focus the sheet on the customer question, i.e. who are you customers? and what are their problems?

I now offer this sheet for free download. The Customers sheet is available on the Dialogue Sheets pages.

Now the catch: I still consider this sheet to be in beta test. I really really really would appreciate some feedback on the sheet – please please please. If you try the sheet please let me know how it goes – for better or worse.

Until recently I had all the sheets behind a registration page. This allowed me to known who was downloading the sheets and in the past I occasionally e-mailed people to find out about their experiences. I got feedback.

But I also got feedback from people who said they didn’t like putting their e-mail address into a system. So I removed the registration process. Now I have no feedback.

I find it very ironic that despite all the talk of the importance of getting feedback (particularly in Agile circles) very few people offer feedback without prompting. Consider this your prompt.

Please, try the sheet, and please please, tell me what you think!

Last time (“Waterfall works when…”) I promised to discuss some of those common objections to “Agile.” (Actually, reading back this this post I’m struck by how like my “12 Myths of Agile Development” which was originally a blog post 2 years ago called “11 Agile Myths of 2 Truths”.)

(Apologies by the way, “Waterfall works when…” was misposted the first time, I’ve just fixed that.)

“Waterfall is most appropriate because our requirements are known and stable”

So what? Agile works brilliantly with stable requirements, it also works pretty well with changing requirements.

“Scope cannot be flexed”

See above.

If scope can’t be flexed than so be it, you will do it all. Scope is flexed all the time on traditional projects. No matter how much traditional projects say “scope is fixed” once they get near the end and no more money, people or time is available scope always flexes.

“We work on multiple projects at the same time”

And? Its all work to do. If you want a full discussion see Xanpan.

I think some of the Scrum texts talk about “dedicated” or “ring fenced” teams. I’ve never yet met a team that doesn’t have some baggage. As John Lennon might have said: “None project work is what happens to us while we are making plans.”

“The thing that is being built cannot be decomposed into smaller pieces”

Well have you tried to decompose it? – many teams jump to this assumption without trying to decompose it. Decomposing work is a skill, just because you tried once and it didn’t magically happen doesn’t mean it can’t be decomposed.

If you couldn’t did you ask for help? Did you ask someone (like myself!) to help? – breaking things down isn’t always easy, it might help to have some help.

What if you can’t break it down but your competitor does?

I believe almost everything can be broken down if you approach it right. And if you can’t break it down then perhaps it isn’t something that can be implemented in software.

“Agile works on greenfield projects but we have a legacy system.”

and

“Agile works on legacy systems but we are building something new.”

(Now I really am repeating myself – see “11 Agile Myths of 2 Truths”)

They both can’t be right? I’ve seen Agile work on both new and legacy development and I’ve heard both sides say “It won’t work because…”.

The grass is always greener on the other side.

“Our project finance model does not allow Agile”

So what? There is plenty you can do which has not finance implications.

Stop pointing at other people who stop you, do what you can and take one problem at a time.

 

I frequently find myself in situations where someone says something like: “Waterfall is appropriate when…”

Some people out there think there are occasions when an Agile (mainly iterative) approach is “best’ and other occasions when “Waterfall” is “best”. Most of the time I let this line of argument go because its boring, I can’t be bothered arguing. (I’ll look at some of these common objections next time). Right now lets get something out in the open:

• Before you make any decision on Waterfall or Agile define what you mean by “Agile” and “Waterfall”.
• The decision to work Agile or Waterfall should not be based on which is more appropriate.
• The decision on whether to work Agile or Waterfall should be a based on an examination of the business benefits.

Briefly, let me define “Agile” as working and delivering in short iterations and “Waterfall” as delivering in a single pre-planned event.

In cold hard cash the benefits to the business are:

1. Agile working produces a far higher return on investment because benefits are delivered sooner.
2. Agile reduces risk because risk is spread across many independent (consecutive) deliveries.
3. Agile further reduces risk because failure can be identified sooner thereby saving money and time (Fail fast, fail cheap).

Without any other changes I can prove those improvements: they are objective. Using just mathematics without reference to any subjective opinion I can prove those three claims.

There are some other business benefits which are I can show logically although this opens the possibility that some will see these are subjective:

1. Agile creates options for businesses and options have value (see Black-Scholes)
2. Agile creates opportunities to incorporate feedback and incorporating feedback leads to better products
3. Agile (when done properly) improves quality (fewer defects) and fewer software defects leads to short schedules (reduced time) in software development, shorter schedules leads to reduced costs

The question of “appropriateness” is an engineering concept based on the idea that one approach is better for the problem in hand than another. If instead we examine the problem from a business perspective it can be rephrased as:

“How can I maximise the return on investment from this work?”

Given that Agile delivers a greater return on investment than Waterfall surely Agile is the most appropriate method every-time?

Of course “which is better Agile or Waterfall?” has never been about cold rational arguments because as individuals, and as businesses, decisions are very rarely made in such rational terms, despite what one might hope or event claim.

Many teams have some sort of very regular reviews. I’m not thinking personnel reviews or budget reviews, I’m thinking code reviews specifically but it could be test reviews, documentation reviews or some other. Reviews that need to happen every day but which frequently get delayed.

Lets stick with code reviews because they are the type I encounter most often.

Code reviews are good, by some accounts they the most effective means of removing bugs early – although I haven’t seen code reviews compared with TDD. But, code reviews loose their efficacy when they are not conducted promptly. The longer the period between the review being requested and the review being conducted (and by extension the review comments being acted on) the less effective the review.

The effect reduces because: a) the person who requested the review has moved onto something else, b) issues found in the review may be repeated until the review is conducted and c) the review will either inject a delay into the delivery process or the delivery will happen without the review in which case, what was the point?

So: if you are going to conduct reviews you want them to happen soon.

And it is not just the code and the developer who wrote it who have problems. The designated reviewer feels the pressure to “do reviews” when they have other – important! – work to do.

One team I know came up with a simple solution to this problem. I recently recommended the solution to another team who promptly adopted it and are delighted. One developer said: “I’ve never been so relaxed about reviews before.”

The solution is….

Make reviews the first item of work after the stand-up meeting in the morning. And let people do them before the stand-up too.

Thus, as soon as the stand-up is finished everyone undertakes any reviews which are needed before they start their day’s work. Review work is prioritised before new work: after all, yesterday the thing that now requires review was the priority, it is probably still the overall priority and the only thing standing between it and “done” is a review.

Reviews don’t typically take very long so today’s work isn’t delayed. And the recipient of the reviews comments can act on the comments before they get into today’s work.

Better still, knowing that reviews will happen right after the stand-up meeting means that it also makes sense to do the reviews BEFORE the stand-up meeting. This also addresses the question of “how do I usefully use the time before the stand-up meeting when I know I’ll have to stop doing whatever I start.”

So for example, imagine on Tuesday afternoon Bob asks Alice to review the code he has just finished. If Alice is available she might just do it there and then. But if she is busy she will wait. Now if she arrives at work at 9am and the stand-up is 9.30am she can get on with the review before the stand-up, if she finishes Bob will have his feedback and can act on it before 10am. If Alice doesn’t get to Bob’s code then she will do it at 9.45am when the meeting finishes.

Either way, Bob isn’t left waiting.

In part this works simply because it keeps the review queue short. If reviews are done soon, say within 24 hours, then the queue is never allowed to become too big and thus its easy to keep the queue short.

One of the teams actually put a column on their board where tasks awaiting review could rest. In the stand-up everyone could see what was waiting for review and arrange to do it.

Simple really.

While we are on the subject of code reviews let me comment on something else.

There is often a belief that only senior developers, or only “architects” should conduct reviews. I think this approach is mistaken for two reasons.

Firstly in this model it is normal that there are far fewer reviewers than there are review requesters. This frequently results in queues for reviews because the pool of reviewers – who also have other work to do – is small.

Second this model assumes that only “architects” can make useful comments on code. I believe most, say 80%, of the efficacy of a code review is the result not of having an expert review the code but simply the result of having another person review the code.

Indeed I even go as far as to say junior people should review senior people’s code. Code reviews are a two way learning process – one of the reasons I like to see them done face-to-face. If an experienced developer is writing code that a junior cannot understand (why do I think of C++ meta-templates?) then the experienced person should know that they are writing code other people cannot maintain.

Anyway, there you go, let me know if you try this idea and what the result is.

In this social media age I am often surprised by the reaction to what I say online. Usually this is not by the reaction to what I say but rather the lack of reaction. I’ve lost track of the number of times I’ve written what I think is a killer-blog post, or a super meaningful tweet, pushed it out in great anticipation and…. well…. nothing.

Just goes to show: what you think is good and what your “customers” think is good can be two completely different things.

And once in a while the reverse happens. I push out a something I think curious, of minor interest, something unobjectionable and bang!

A week or two back I put out what I thought was a slightly humorous tweet which would be agreeable to many:

“If you manager doesn’t know what technology you are using then they probably shouldn’t be your manager.”

And bang! People – techies! – took exception and rushed to defend managers – usually that is my job!

In a way I was delighted that so many people rushed to defend managers – and to say how managing wasn’t about technology. Most of the IT community damn managers without a second thought. Thanks guys!

Well I feel the need to reply and explain myself more fully. First lets clarify what I mean, then I’ll explain why I think its important.

I friend of mine recently delivered an Agile Introduction course to a client. Before the course the team leader/manager couldn’t tell him what technology the team were using. That is: which language (C#? Java? PHP? Scala?), which operating system (Windows? Linux? MacOS?) or which database (SqlLiite, MySql, SQLServer, Oracle?). Sure we could guess because we knew it was a web development but beyond that…. Anyway, not critical.

This confusion continued at the course itself. Apart from the coder (and possibly the tester) none of the others involved with the work knew which technology was being used.

My interpretation of this situation is: those who didn’t code were disconnected with the work of the technical staff. A gap existed, if they were ignorant of the central technology then what else might they be ignorant of?

(I once heard of a UK Government/BigConsultancy project where when asked “Where are the coders?” a project manager replied “I don’t know, Bangalore I think”. It later transpired they were in Newcastle-upon-Tyne.)

I also take it as a sign that those people do not have a technical (specifically coding) background. I can’t imagine a former coder who doesn’t have some interest in what technology is being used.

The situation clear?

So why is it important?

Lets point out: I’m not for one minute claiming the manager, or requirements analysts etc., need to be able to use these technologies. An appreciation of the technology can be useful, and if they can code they might be able to help, but, too much knowledge can be dangerous. It can lead to the non-coder trying to second guess the coder and tell them in too much detail what they need to do.

I once managed a C# team: as a former C++ and Java coder I could understand and join in the conversations but if I ever felt the urge to reach for the keyboard or tell them how to do their job I knew I would make a fool of myself.

The first reason I think management types should know the technology is exactly as I’ve said above: it shows they understand what is going on. One of the big problems faced today is disconnected managers. This is the reverse of micro-managing, this is what Professor Henry Mintzberg calls macro-leading: ‘people in senior position who try to manage by remote control, disconnected from everything except “the big picture”.’ (Simply Managing, 2013)

That is what I was getting at in my original tweet. If managers don’t know what technology is being used they they are simply too disconnected to be able to manage it. But I will go further….

The second reason is I think management types absolutely do need to understand programming and technology if they are to manage such efforts. I’m fond of saying: “In software development work the devil is in the detail.”

If managers don’t understand the nature of the coding process I don’t think they can manage it. And if they have never coded I find it hard to understand how they will know the nature of coding work.

If managers don’t understand how software is developed – in the real world – then they will impose models of development and management which undermine the work.

If managers don’t appreciate the difficulties that can arise in software development then they will not be in a position to use their authority to help the technical staff. Indeed they may have problems even talking to their technical staff if they lack knowledge.

I don’t believe “if you can manage you can manage anything” – it is a lie. Such advice is a recipe for the kind of mis-management we see all too often in the IT world.

The fact is: if you are developing technology you need to get your hands dirty with technology.

I’ve long been guided by the words of Fred Brooks:

“In many ways, managing a large computer programming project is like managing any other large undertaking – in more ways than most programmers believe. But in many other ways it is different – in more ways than most professional managers expect.” (Brooks, 1975)

(Indeed I chose these words to open Xanpan 2: The Means of Production.)

When I studied management I found much of the advice and good practices were highly applicable to software development. Indeed my Masters dissertation is an examination of how some management ideas map directly into Agile software development. (And yes, that dissertation opens with the same words from Brooks, “Software Development as Organizational Learning” is available to download and formed the beginnings of “Changing Software Development: Learning to be Agile”.)

There is a lot of good management practice and advice out there that many people inside IT and software development would benefit from knowing. But asking a generalist manager to manage a software development effort (always a complex effort) is going to result in problems.

Let me quote again from Henry Mintzberg:

“Managers deal with the messy stuff – the intractable problems, the complicated problems. … put together a good deal of craft along with the right touch of art alongside some use of science, and you end up with a job that is above all a practice, learned through experience and rooted in context.” (Simply Managing, Henry Mintzberg, 2013)

If you are managing a software development team I do not see how you can have the requisite experience and context if you have not programmed yourself. Managing does not exist in a context of its own, all management is rooted in the thing being managed.

I’m just putting the finishing touches to a new Requirements Dialogue Sheet for a trial run this week with some guinea pigs (see my Dialogue Sheets update blog last October for more about this). And something thought provoking has come up I want to share.

If you’ve seen my dialogue sheets you will know that around edges I place quotes: some humorous, thought provoking, some (hopefully) inspiring and a few all three! As I edit this sheet two quotes have come next to each other and it is making me thing.

From Sergey Brin, of Google fame:

“It’s important not to overstate the benefits of ideas. Quite frankly, I know its kind of a romantic notion that you’re just going to have this brilliant idea and then everything is going to be great. But the fact is that coming up with an idea is the least important part of creating something great. It has to be the right idea and have good taste, but the execution and delivery are what’s key”

And from Leo Trotsky, of Russian revolution fame:

“Learning carries within itself certain dangers because out of necessity one has to learn from one’s enemies.”

Then add in another Trotsky quotes from his time as Commissar for Foreign Affairs:

“We will issue a few revolutionary proclamations to the peoples, and then shut up shop”

The interplay of the quotes interests me. (If only Trotsky had had Brin’s advice!)

For those who know a little about the history of these two men there is an added depth.

While you think about that, if anyone would like to volunteer to test one of the new requirements dialogue sheets please get in touch.