December 12, 2015

...Learn TDD with Codemanship

The "Just F**king Do It" Manifesto

I've noticed there's a new manifesto doing the rounds on social media. Well, not so much a new manifesto as a reaffirmation of one part of an old manifesto.

The "12th principlists", as they're calling themselves, are putting their names to a manifesto based on the twelfth Agile principle - that teams should be self-organising and empowered.

Who, among Agile developers, disagrees with that?

The problem, I feel, is not that developers and teams don't sign up to the 12th principle. Signing up to things that sound good is easy.

The problem has always been that - even with their best intentions - it's beyond the power of teams to make it happen. Or so many teams seem to think.

A core Agile value is courage, and you need a big set of brass balls to manage upwards and outwards so that your team really is given the trust and the authority to decide how development needs to be done.

Don't make excuses. Don't look to Mom & Dad to give you permission. Stand firm and take responsibility. If you think you should be writing tests first, then write tests first. If you think developers should be working in pairs, work in pairs. If you think you need to agree acceptance tests with the customer, then make it absolutely 100% crystal clear that if there isn't a test for it they ain't getting it. If you need whiteboards, get whiteboards. If you need two monitors, get two monitors.

I'm being glib, of course. You may not have the authority to buy a second monitor. The customer may feel their time is better spent doing anything else except agreeing tests with you. And so on.

And this is where the rubber meets the road. In my experience, if development teams don't have the authority to decide how best they should work - within reason, of course - it's because we let things get that way.

At home, who decides if you can have a second monitor? You do. And how big a decision is it? It's trivial. Whip out the old credit card and you'll have it tomorrow. Because you are a grown-up.

At work, though, there's a tendency for teams to be treated like children. Want a second monitor? Ask Mummy and Daddy. Want to pair program? Check it's okay with mummy and Daddy first.

Teams must not seek permission from above for the way they work. That's the road to infantilisation and micromanaged madness. Agree as a team on what needs to be done, and then just f**king do it.

The other side of that equation is delivering. Do what needs to be done, but you have to deliver. Teams failing to meet customer expectations is why they put Mommy and Daddy in charge in the first place. Your team has to demonstrate that you are grown-ups, and that Mummy and Daddy aren't needed. And what better way than by consistently delivering value?

Here's the rub: Mummy and Daddy's way of doing things may not be conducive to delivering working software that satisfies customers' expectations. So, ironically, if you do it their way, you may lose even more trust, and be micromanaged ever tighter. And round and round we go.

When I come across teams who have almost no say in how they do their work, there's usually a long backstory of micromanagement leading to disappointment leading to even worse micromanagement, until developers have to go through a long chain of command to get a pack of index cards.

The kind of personality who can manage upwards to prevent or reverse that situation is relatively rare. We're not famous, as a community, for attracting non-risk-averse assertive individuals with the necessary people skills to protect the team from interference. Typically, those kind of people - often from non-technical backgrounds - are hired to be Mummy and Daddy, and tell the team what to do. It's also a personality type that likes to be in charge and likes things done their way, and teams are easily dominated and exploited by them.

This may stick in the craw of the many free market capitalists working in software development, but what teams need far more than strong leaders is solidarity. Leadership doesn't have to be one person calling all the shots. A team can be democratic. We can throw many ideas around, then form a consensus on what direction to take. And then present a united front on that consensus.

Yes. Software developers agreeing with each other. The impossible dream!

So, teams don't get empowered. They empower themselves. And that does, regrettably, mean that your bottom line will need to be "if you don't want us to work this way, then find someone else". The moment you flinch and show that, really, you'll do whatever they tell you, you're sunk - at least as far as the 12th principle is concerned.

Posted 4 days, 7 hours ago on December 12, 2015