A Commonplace

What is a commonplace?




A few days ago I was babbling about Alchemy.

I was talking about turning lead into gold - that that is what the alchemist tried and failed to do. In the process, they often made a big stink, sometimes poisoned themselves. But over hundreds of years they came up with what ended up being called Chemistry.

The "gold" in alchemy took a long time to arrive, but when it did, it paid off big.

The I talked about lead and shit.

What initially comes out of this fancy Agile process is not great. In fact it can be really bad in lots of ways.

Whatever initially "working" software comes out of a project probably won't look perfect - if you're lucky, there will have been some design input.

This first "thing" probably won't do much, so, compared to the set up costs, it will be really expensive.

Let's be honest here, this first thing might do completely the wrong thing it might not do what the client had in mind, but it might be that the client just hasn't managed to tell the team that.

Story time. I once worked on a project as an "Agile coach". The project had spent nine months and a lot of money gathering requirements. One of the main things that I'd been pushing for since I got involved in the project was some kind of show and tell. My instinct was that it would be a really good idea for the work that was being done on the project could be shown to the people who are actually going to use it.

After a lot of tooing and froing the meeting finally got arranged.

Oh for fuck's sake the gold. Get to the fucking gold. Enough of the fucking war stories. You've been doing this a long time, you're grizzled and experienced we fucking get it. Show us the fucking GOLD.

OK. Sorry.

Here's the gold.

The gold is connecting what the client and client's organisation values with what their customers value, via the working software. Working software that your team writes.

That's it. That's the whole point of this book.

Why is that so hard to say? Why is it so hard to do?

Well, why it's so hard to do is really what I've been walking through in this book.

The kind of projects that get funded are shiny.

Often the team then has to fight all kinds of bricks without straw problems.

If the team can get beyond the bricks without straw problems and actually make a brick - actually make a little piece of the project work, that is threatening to the big shiny idea, and it's threatening to the people who came up with the big shiny idea and the people who funded those people.

But this point? This point is the absolute crux.

Oh my god! Why didn't I see this before? What you're doing when you're managing any project is preparing the ground for this crisis.