Musings on measuring

Nothing happens just because you measure. You don’t lose weight just by weighing yourself. Or maybe I did not stand there long enough? (Bjarte Bogsnes on Twitter, 16/02/2014)

Count something (Atul Gawande, Suggestions for becoming a Positive Deviant, in Better

We’ve all learnt from lean that measuring is good. But the passion for measurement is sometime, not matched by actually doing anything meaningful as a result of having that data. Ten out of ten for data, minus several million points out of ten for not actually using it.

What’s more, I’ve seen folk insist that data (x) is the most important metric, then the next week it’s ‘ah, we need to be tracking (y)’, after a few weeks you end up with a mountain of data and no sense of either what any of it means, nor what you would do in response to that data, or the experiments you’d run to move the needle. Not just standing on the scales, but skipping from scale to scale, buying a new one every other day, then deciding that what you’re really interested in is your shoe size, not your weight.

I do see two uses for measuring, though. The first is the scientific, experimental use. We hypothesise X, decide what to measure that will validate or disprove the hypothesis,

There’s also measuring for monitoring. Not just strong signals (hey, the internet’s down), but also weak signals (mmm… the engine sounds slightly different today, I wonder what’s going on). This kind of operational measurement is just as important.

We need both kinds of measurement: the first to guide us to where value lives, the second to keep us close to how that value’s being delivered.

Features or Flow?

I’ve done a few product workshops in my time … One thing I see over and over again is a focus on features. “We could do this”, “Hey, how about that”, “I’ve just had a really cool idea…” And so on. There’s clearly a time for this. But if you’re not tuned into a user’s perspective, it can get frustrating very quickly. All these features! All these stories!

At some point in the proceedings I’ve taken to calling a halt, picking up a device or pointing at a screen, and saying, “OK, so I’ve just loaded the app for the first time. What next?”. And when we have an answer to that, then “OK, so now - what next?” Gets people focused on the actual use of what you’re trying to build, and in particular starts people realising that the last thing a new user wants is complexity. Get it out of the face of the user!

Seems obvious, but the number of times I’ve dealt with teams which one would have thought had significant product experience who’ve needed this gentle guidance would suggest that it ain’t necessarily so.

The original Mindstorms

At Educating Programmers I talked to several people about Mindstorms. Not LEGO (though there’s a great deal to be said about that too), but the book, published in 1980 by Seymour Papert, in which he sets out a vision of learning inspired by the use of computers. It’s a book which most people present had heard of, of course, but I can’t recall anyone saying they’d actually read it. I encountered it in the mid-1980s, when my children were young, on the back of exploring many different programming languages and coming across Logo. It left a deep impression on me, and I was enthusiastic in talking about it, and lending my copy (too enthusiastic — would the last person I lent it to, please give it back? Thanks).
Read the rest of this entry »

Educating programmers - suddenly everywhere?

Odd how an idea that brews for a while is suddenly thrown into prominence.

With some 30 others I was delighted to be part of the Educating Programmers summit, organised by Jason Gorman and held at Bletchley Park last week. The very next day (it really couldn’t have been timed better) Eric Schmidt, in the McTaggart lecture at the Edinburgh Festival, generated significantly more awareness of the woeful state of computing education in this country:

You need to start at the beginning with education. We need to re-ignite children’s passion for science, engineering and maths … I was flabbergasted to learn that today computer science isn’t even taught as standard in UK schools. Your IT curriculum focuses on teaching how to use software, but gives no insight into how it’s made.

Read the rest of this entry »

You can’t do it like that!

“You can’t do it like that!”

“Why not?”

“We agreed at the beginning of the release that you would do it like this

“Ah, but doing it like this makes no sense now.”

“Look, in the meeting minutes. You agreed!”

“So? We’ve learned a lot since then…”

“But you can’t do it like that!”

Bureaucracy hates self-organisation.

(I’m pleased to say that this little exchange was inspired by a happy experience of a team deciding that they could do it like that)

Refactoring is not Rework

Prompted by a brief twitter exchange, it’s worth reminding ourselves what refactoring is.
Read the rest of this entry »

On coaching and being coached #acguk

As last year, the UK Agile Coaches Gathering was both a great community-builder, and a total ideas-fest. In particular, Tobias Mayer (Presentation is not Facilitation) helped reinforce the poverty of presentation as a training technique, and Petra Skapa’s question about what we can learn from other coaching disciplines elicited some great stories about experiences of coaching and being coached.
Read the rest of this entry »

#spa2010 reflections 1: Maurice Mitchell on complexity, fit, the human dimension

Ever since hearing about the architecture of rapid change and scarce resources I’ve wanted to talk to Maurice Mitchell, one of its leading advocates. I was delighted when he agreed to give an invited talk at SPA2010.
Read the rest of this entry »

Refactoring in the wild

I’m please to see James Shore’s chapter on No Bugs online. It’s a great explanation of how the XP practices reinforce each other to support the development of excellent code.

Read the rest of this entry »

Michael Jackson: a Lost Masterpiece

But thankfully found again. Through a series of circumstances too complicated to relate, I’ve recovered (after its perambulations of six years or so) my copy of Michael (A) Jackson’s Software Requirements and Specifications: a lexicon of practice, principles and prejudices. (SRP in what follows)
Read the rest of this entry »