Management

Fixing agile failure: collaboration over micro-management

I’ve said it before, and I’m sure I’ll say it again: “the agile toolset can be used for good or evil”. Tools such as visual work tracking, work breakdown cards and stand-ups are great for helping teams take more control over their own work (self-organization). But in the hands of someone who doesn’t respect the team, or has micro-management tendencies, those same tools can be weaponised against the team.

Put it this way, what evil pointed-headed boss wouldn’t want the whole team standing up at 9am explaining why they should still be employed?

In fact, I’m starting to suspect that the toolset is being used more often as a team disabler than a team enabler. Why do I suspect this?

Reason 1: the increasing number of voices I hear criticising agile working. Look more closely and you find people don’t like being asked to do micro-tasks, or being asked to detail their work at a really fine-grained level, then having it pinned up on a visual board where their work, or lack of, is public.

Reason 2: someone I know well is pulling their hair out because at their office, far away from software development, one of the managers writes new task cards and inserts them on to the tracking board for others to do, hourly. Those on the receiving end know nothing about these cards until they appear with their name on them.

I think this is another case of “we shape our tools and then our tools shape us.” Many of the electronic work management tools originally built for agile are being marketed and deployed more widely now. The managers buying these tools don’t appreciate the philosophy behind agile and see these tools as simply work assignment and tracking mechanisms. Not only do such people not understand how agile meant these tools to be used they don’t even know the word agile or have a very superficial understanding.

When work happens like this I’m not surprised that workers are upset and demoralised. It isn’t meant to be this way. If I was told this was the way we should work, and then told it was called “agile” I would hate agile too.

So whats missing? How do we fix this?

First, simply looking at small tasks is wrong: there needs to be a sense of the bigger thing. Understand the overall objective and the you might come up with a different set of tasks.

Traditionally in agile we want lots of small work items because a) detailed break down shows we understand what needs to be done, b) creating a breakdown with others harnesses many people’s thinking while building shared understanding, c) we can see work flowing through the system and when it gets stuck collectively help.

So having lots of small work items is a good thing, except, when the bigger thing they are building towards is missing and…

Second, it is essential teams members are involved with creating the work items. Having one superior brain create all the small work items for others to do (and then assign them out) might be efficient in terms of creating all the small work items but it undermines collaboration, it demotivates workers and, worst of all, misses the opportunity to bring many minds to bear on the problem and solution.

The third thing which cuts through both of these is simple collaboration. When workers are given small work items, and not given a say in what those items are, then collaboration is undermined. When all workers are involved in designing the work, and understanding the bigger goals, then everyone is enrolled and collaboration is powerful.

Fixing this is relatively easy but it means making time to do it: get everyone together, talk about the goals for the next period (day, week, sprint, whatever) and collectively decide what needs doing and share these work items. Call it a planning meeting.

The problem is: such a meeting takes time, it might also require you to physically get people together. The payback is that your workers will be more motivated, they will understand the work better and are ready to work, they will be primed to collaborate and ready to help unblock one another. It is another case of a taking time upfront to make later work better.

Fixing agile failure: collaboration over micro-management Read More »

Reworking the risk equation

It is hard to argue with the old project management equation:

Risk exposure = Risk impact x Risk probability

Risk impact is often take to be money, say $1,000,000 and probability a percentage, say 50%. So exposure is also in money, $500,000. There is something rather obvious about it. So, while I’ve long disliked the equation I’ve not taken it to task, I never quite put my finger on it, or perhaps, I couldn’t really articular a winning argument.

That changed last week when I took “Papa” Chris Matt’s dog for a walk, or rather, he walked the dog I just tagged along and discussed the state of the world, and the thing we call agile.

Chris has a better equation:

Risk exposure = Money invested x Time to payback

Probability is out, after all, if something fails then it all fails. You were never going to loose $500,000, although you might loose the whole million. Probability is something of a red herring.

Chris’ insight here is that there is risk until the moment when you start seeing payback, i.e. until the investment starts pay is proven. In retrospect I should have realised this before. I read How Big Things Get Done a few months back and Bent Flyberg has the same idea. He points out that the time of biggest risk starts when the big money gets spent and continues until the project is delivered. Flyberg uses this logic to argue that long, detailed, upfront planning is good – because it is cheap and allows problems to be identified and avoided). Once you start the real work then do it as fast as possible; keep moving fast even if it costs you more because until the window is closed everything is as risk. (A highly recommended book by the way.)

The lesson many people take from this is: spend along time in planning and make sure you are certain about what you are doing before you spend the big money. I suggest a more important lesson is: once you start spending the money get to the point of return as fast as possible. Slowing spending does not reduce risk or save money, it increases risk and reduces benefit.

I’ve pointed out before that one way to increase the return on investment (significantly) is to make sure work starts paying back sooner. For example, make sure that the team deliver something every month (which itself reduces risk because something – anything! – is actually being delivered) and have that thing earn some revenue even if it is less than the full amount you want. When you do return on investment calculations correctly (i.e. account for time) then bringing forward the point where some (even a little) money is returned causes ROI calculations to jump.

Although it might seem too good to be true, the same logic will reduce risk. Both on paper and in practice.

Everyone who has ever argued for measuring and reducing cycle time will be happy right now. But Chris has a second point: today’s endeavours often involve multiple teams, and until all those teams deliver there is no return.

Think of it like ships in a convoy: they move at the speed of the slowest ship. None of the ships arrive until they all do, until they do they are all at risk, and since they are moving slow there is more risk. It also means, that reducing risk, speeding delivery, increasing ROI is going to depend on speeding up the slowest ship. If that sounds familiar its because it is what theory of constrains says: the system is constrained by its most significant bottleneck.

Reworking the risk equation Read More »