Rebuilding the airplane in flight

[Reading time: 1 minute, 16 seconds]

Rebuilding the airplane in flight.

That’s how transitions feel, isn’t it?

And, put that way, it seems like a terrible idea.

But on the other hand, what’s the alternative?

Close your IT department, or indeed your entire company, to leisurely rebuild your systems?

If the first idea was bad, this one is downright ludicrous.

So you have no other choice but to slowly change your organisation, step by step, element by element.

All hail the monolith?

[reading time: 1 minute 57 seconds]

I read the following question the other day:

“Are people still architecting for Microservices in light of some well-known returns to the monolith?”

So, there we have it. Microservices are officially not cool anymore.

What does that mean? That we’ve all gone serverless now (hi Paul ;-) )?

Surely not. It means that the pendulum has started to swing back.

You see, it doesn’t matter whether what you’re building is a monolith, or a microservice, or a nanoservice, or whatever else.

My DevOps research project

[Reading time: 1 minutes 36 seconds]

About a week ago I kicked off a research project.

I had certain impressions and gut feelings about how DevOps was introduced and applied across organisations; in fact I was curious on the general perspective towards DevOps.

In order to move beyond my gut, and towards solid data, I’ve started to approach DevOps professionals to ask if they would share their experience with me. I focus on people perhaps more towards the strategic side of DevOps work: managers, VPs, those kinds of roles.

consistently bad estimates point towards shortcomings of your organisation

[Reading time: 1 minute 39 seconds]

You estimate your work, don’t you?

Are you and your team consistently missing the mark?

That’s a strong signal that something is amiss. And I don’t mean your estimation ability.

Sure, everybody messes up an estimate every now and then. That’s in an estimate’s nature, after all: we don’t know the correct answer, so we’re literally making an educated guess.

But I know of organisations where mis-estimates are just totally the norm.

Making hidden work visible

[Reading time: 1 minute 46 seconds]

Welcome to another installment of mystery week, DevOps edition :-)

Hollywood monster trivia: what’s one way to kill vampires?

Sunlight. Nice, bright, high-visibility sunlight.

DevOps monster trivia: how do you kill hidden work, the bloodsucker of organisational effort?

Automation.

(I know, a bit anticlimactic, but hear me out).

The thing about automation is that no work can hide from it: either a particular step is included, and being executed – or it has been missed, and the whole thing falls flat.

Shadow org charts and hidden work

[Reading time: 46 seconds]

Continuing our famous mystery topic, I want to talk about hidden work.

What’s hidden work, you may ask.

Quite unsurprisingly, it’s work that’s being done, but is happening “under the radar”.

Things that happen invisibly are usually a bad thing in an organisation, because they can’t be planned.

And, as I’m sure your mother told you, unplanned work is the root of all evil.

Unplanned work messes up your estimates, your work pipelines, threatens your success at creating a product: instead of doing the thing you ought to be doing, you spend time on something else.