Moltke on leadership

Here's another post I wrote on our internal blog some months ago. I refreshed and updated it somewhat. Enjoy!

Lately, I've been reading a certain series of short stories and novels (Falkenberg's Legion, by Jerry Pournelle). I'm not really a fan of military novels -- fiction or non-fiction -- but I found some aspects of this series quite fascinating.

While software development is perhaps not as lethal as war, we have a lot to learn from the military organizations when it comes to leadership vs. management, unity of command, and organizational theory. Let's face it, armies are subject to heavy darwinistic selection. Survival of the fittest.

Towards the end of the series I found the following quote. Pournelle is in the habit of quoting long passages from various military theory and history books and I got in the habit of skimming those fairly quickly. The following quote is actually one of the shortest in the book and thus one of the ones I actually read, but the implications are worth discussing here:

"The advantage which a commander thinks he can attain through continued personal intervention is largely illusory. By engaging in it he assumes a task which really belongs to others, whose effectiveness he thus destroys. He also multiplies his own tasks to a point where he can no longer fulfill the whole of them."
-- Helmuth von Moltke

Note that Moltke says "intervention" not "attention". The fact is that our most effective leaders are those who pay attention to the work of their subordinates. A good manager sees what is going on and adjusts the system to promote correct behavior (such as distributed decision-making) and dampen incorrect behavior. Or as Ronald Heifetz says, "attention is the currency of leadership".

Our least effective managers (no-one named, no-one forgotten) are those who personally intervene in the work of their subordinates. By continuous intervention the manager is sending one message upwards and another downwards in the hierarchy. Upwards, the manager is saying that he is personally taking heroic action to ensure that the team is moving forward in the face of overburdening technical challenges. To the team, he's saying "I don't trust you to do the right thing". Any initiative taken by team members is subject to review and approval. Self-motivated individuals will search for opportunities elsewhere. The manager becomes the bottleneck that prevents the team from delivering, thereby closing the self-reinforcing loop.

If you were a mid-level manager and had two projects, one delivering regularly and effortlessly and the other subject to continuous difficulties overcome only by heroic efforts from the project manager and the team, which project manager would you consider more effective? Which one would you reward for doing a good job? Would you grease the squeaky wheel and let the silent wheel go uncared for... until it also starts squeaking?

The iron triangle

This is an updated repost of a blog entry I wrote in June 2010 on our internal blog, combined with some material I wrote earlier this week as a result of a good discussion with @duarte_vasco. Enjoy!

An interesting thought occurred to me last Thursday. You all know about the "iron triangle": out of scope, time and quality, you can pick any two. The reason why you can't nail down all three is the unpredictability inherent to software development.

If you have read your Fred Brooks, you know that software is invisible. Walk into a factory and you perceive noise, activity, movement. But walk into a software development office and you perceive silence, inactivity, stillness. A lot of things are happening, a lot of work is being done, but it is invisible to the naked eye. Fred Brooks says in his infamous essay "No Silver Bullet" that software is an abstract construct of interlocking data sets, data item relationships, algorithms and functions. It is "pure thought-stuff, infinitely malleable", complex, changeable, and invisible. These essential and inherent attributes makes software virtually impossible to visualize, model and understand.

Orthodox plan-driven methods attempt to nail down all three parameters. Since quality is the least visible of the parameters, it will be the one that fluctuates. Therefore in a plan-driven project, you set a Quality Manager to "manage" the problem of quality. Unfortunately quality management is a post-facto task; there's nothing much relevant a Quality Manager can do himself to improve the quality of the product. It's not like he's going to go and fix the bugs himself, right? He can try to prioritize change requests and bugs and increase visibility into where the product is. Another problem is that depending on how long your development cycle is i.e. how often you integrate your product and how long the system testing takes, the picture that emerges doesn't show where the product is, but where it was.

In Scrum and other Agile methods, we do it the other way around. We require high quality in a short time and let the scope float. The quality is defined and controlled using automated tests, and the timebox is defined as the maximum time we can keep change out of the project (or even better, as the minimum time needed to make something we can demonstrate and invoice the customer for). But we don't send out the scope to sea to float freely around, oh no! The key is that instead of letting the scope fluctuate randomly, we set a scope manager (actually, let's call him e.g. the Product Owner) to actively manage it. And this must be done ahead of implementation.

You see where this is going? Paradoxically enough, the Product Owner also prioritizes change requests and bugs (read: backlog items) and increases visibility into where the product is going.

So what's the difference between the PO and the QM? The difference is that the QM works in a system based on predictability, while the PO works in a system based on unpredictability. Since software development is fundamentally unpredictable, the QM tries to salvage the product afterwards, while the PO is effectively managing the product one step ahead.

And that, my friends, is it.

So it has a name: personal Kanban

For a while I've been trying to find a way to manage my tasks. I usually have dozens of projects running in parallel, each with a number of small tasks that tend to be forgotten. Visibility has been a problem for me and likely for my colleagues too. Basically I've wanted a personal Kanban board.

So yesterday I evaluated a bunch of free online Kanban tools, on the assumption that a well-written AJAX app should work on my laptop as well as my two cellphones. I ended up with www.kanbantool.com mostly because it supports swimlanes and downloadable webcals. The UI is fresh, simple and uncluttered, and although it's not optimized for mobile devices, it's at least usable. For the moment this seems to work fine. To keep things simple I've opted for a three-step workflow consisting of Backlog - In progress - Done. The web page stays open and credentials are retained even if the IP changes, so I don't have to log in all the time. And the WIP limit does wonders. The webcals don't seem to work properly, though.

I presented this to a colleague and he said "Oh, you've started using Personal Kanban. Good for you." I didn't know it had a name. ;-)

Lessons learned as an Agile Coach

Yesterday I spoke at Turku Agile Day 2011 about my lessons learned as an Agile Coach. I was asked to talk about large-scale Agile adoption from the coach's point of view and I happily agreed as I have lots of stories to tell. It didn't turn out that way however. The new company strategy made my presentation obsolete and I subsequently spent some time on analyzing, generalizing and extracting the lessons learned.

In other words I frantically rewrote my presentation on the train to Turku yesterday morning. My slides and possibly some live material (horror film at eleven!) will be available on the Turku Agile Day web pages... as soon as the guys have recovered from their hangovers.

Anyway this seems to be an excellent opportunity to stop for a moment, take a breather and look at what I and the others in my team have achieved over the last several years. Lots of small and large wins, a couple of defeats and of course what we could call the ultimate defeat: failure to deliver within a reasonable time. I'm going to look for things that worked and didn't work and try to find patterns and supporting theories. What to do with that information I don't know yet. However you can expect more updates on this subject later, and perhaps some presentations on SlideShare or maybe even a booklet. Time will tell.

With those words, over and out.

F1rst psot!

Yay! Welcome to my blog! And this is my first post, to celebrate the occasion (and incidentally to have a placeholder to check what it looks like). There are many reasons to set up a public blog, including but not limited to:

• I have things to write down
• I need to hone my writing
• I want to reply to what other people blog about

That's it! Let's see how this works out.