Roman Agile Development: Decimation

Roman Agile Development: Decimation
===================================

Modern software developers increasingly have to work in teams. But developers, by nature, are often solitary creatures, carefully hoarding the complexity of their code from the uncaring eyes of management and the theiving fingers of other developers.

How then are we, as managers, expected to motivate them?

There are lots of ways, of course - free pizza, flexible work hours, expensive day trips... these are perks and cultural approaches. But for some developers - for example, contractors or "rock star" developers who have no sense of company loyalty, or permanent employees who are only interested in their own job security, these methods may be ineffective, or, counterintuitively, actually hinder collaboration between new team members and longer term full timers.

Of course, nobody likes to be the one to sack anybody - but sometimes termination is the only recourse available to a C level employee. As a thought experiment, some colleagues and I recently considered a radical new approach to motivating developers: the threat of decimation.


Marcus Licinius Crassus was, and remains, the wealthiest Roman who ever lived. His business model was based on capitalizing from poor planning when it came to fireproofing. He would maintain a private team of firefighters, and when a building caught fire, he would show up, offer to buy the burning building (at a highly reduced rate) then, if the offer was accepted, has his men put out the fire.

Contractors often complain that their jobs often consist of "firefighting" - a vague term to describe the general practise of solving other people's problems quickly and at high cost. It is from this that we draw the link between Crassus' private firefighters and modern day IT contractors.

Crassus was later placed in charge of a large Roman military force during the Third Servile War - and some historians credit his military success to reviving the then-ancient practise of decimation.

When a legion was decimated, up to one-tenth of the soldiers, who were randomly selected by drawing lots, was put to death by his comrades. This punishment was derived by ancient Roman commanders as a less severe collective punishment than simply killing an entire legion - usually for the sorts of crimes that can only be prevented by an entire military unit or team, such as looting, desertion, and other war crimes or acts of willful disobedience or cowardice.

Each legion was divided up into groups of five or ten soldiers, and one of each would be put to death - by the other nine. As you can imagine, the mere threat of this horrifying punishment did wonders for unit cohesion, and quickly prevented any murmurings of dissent or disobedience.

Could Crassus' harsh methods be learned from today? Maybe!

Imagine you have a team of developers. Each one has their own skills, and areas of expertise. Each one is really only concerned with looking after their current job, or perhaps the next job. What if, for an entire team, the managers threatened to decimate the software team? That is, if a key milestone is not met, or several sprint is not delivered, or whatever the conditions of failure are, one team member SELECTED AT RANDOM (not by virtue of finger pointing or on a first-in-last-out basis) is immediately dismissed.

Suddenly, maybe people aren't so keen on not properly documenting that API. Suddenly, maybe people are less concerned with checking their facebook and doing the minimum amount of work? Suddenly, maybe people are less inclined to use untested new technologies so they can put them on their CV.

Everyone is focused. Everyone is terrified. But they were terrified anyway! This is tech, not the civil service. Now if someone is decimated, it's not their fault - it's just bad luck. Now, blaming someone else doesn't help you - it just endangers everyone's job.

This might sound harsh and sadistic - but consider the alternative: the project fails and the company goes out of business. Then EVERYBODY loses their job anyway! Although at first glance it seems unnecessarily harsh, the threat of decimation MIGHT actually help to motivate your team. Fear is a great motivator - look at any politician for proof of that.

Will YOU be the first manager to introduce the threat of decimation to your agile team? If so, I'd love to hear how it goes!