31 Days in May — Day 17 — What am I Looking at?

Tell Me What You See

So when I’m thinking of the OODA loop (which I kind of have been doing over the last sixteen days), I’ve been highlighting that the most important part of that loop is the “second ‘O’” — the Orient part. Orientation is understanding “where we are” and making sense of what we’re looking at, of what we have observed. And I suppose the thesis of these pages — although they have meandered considerably is this: if you improve the quality of the culture and education of the people who are involved the orientation phase of the OODA loop, this will improve the overall quality of decisions that are made, and this will improve the overall quality of the actions.

One of the early things that will get thrown out as part of an OODA loop process is what I called yesterday “Bricks without straw” obstacles — issues that the team discover that mean that they aren’t going anywhere until those issues are fixed. A good leader recognises these issues and addresses them, a bad leader ignores them and continues to imagine that the teams’ goals are achievable. In Scrum, these “bricks without straw” obstacles are called “impediments” — and they are definitely one thing that comes out of the Scrum process.

Another thing that is supposed to come out of the Scrum process, at the end of every week is “working software”. What is “working software”? Er, software that works. OK. But where does it work? On a single laptop? On a test server? On the live site? If the software divides into back-end and front-end, is it OK to show the front-end working without the back-end?

The idea of a show and tell at the end of a Sprint is a powerful idea. But it is dependent on the education, intelligence and culture of the person to whom the “working software” is been shown. Let’s go with tradition and call this person the product owner. What sorts of thing does the product owner need to know, in order to know what they’re looking at?

1) How long things take

I was in a stand-up which was taking place just after a “gate review” — where a working prototype that we’d created had been reviewed by a committee of the “great and the good” inside this organisation. Half-way through the stand-up, out of nowhere and, to me it seemed, in relation to nothing, the product owner announced “well, in the gate review they said we were fifty percent slower, so I think we have to speed up.”

Not covering up my fury at the product owner using the stand-up as an opportunity to berate the team, I tried to at least grasp the point she was making.

“Really? Fifty percent slower than what?” her face fell.

“Oh, I don’t know! I’ll have to go back and ask.”

This was a very clever woman — she was a defence lawyer — but her comment had unearthed a large gap in her education and culture. Not only did she not know how long software was supposed to take, she didn’t know how we might go about measuring how long it would take. I suppose this brings us onto a second, third and fourth point — but we’ll continue this tomorrow.

2) How much software costs

“the blood-bedewed halls of their first terrible development. But be imagined — as little.”

Edgar Allan DevOps @DevOpsPoe

3) The difference between wireframe, a mock-up and working software (and different kinds of working software)

4) The value of working software

Like what you read? Give Mark Stringer a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.