Working practices

This category contains 95 posts

From visualising data to seeing the work

Visualising data is good, but then looking behind the visualisation is even better. This became apparent to me recently reading a fun piece of research by Justin Matejka and George Fitzmaurice: An effective (and often used) tool used to demonstrate that visualizing your data is in fact important is Anscome’s Quartet. Developed by F.J. Anscombe … Continue reading

Teams and crews

One of the most entertaining sessions at last months’s Agile in the City: Birmingham was from Martin Burns, discussing teams in relation to performing music. And of all the points he made, the simplest and most compelling to me was the distinction between teams and crews. The dynamics of a team, he said, changed significantly … Continue reading

Why measure happiness?

Measurement might sound like it’s some kind of objective process, but that’s not always the case. Last week I asked the audience at Agile in the City: Birmingham to “Quantify Your Goals”. As part of that I showed how on one of the programmes at ONS we assessed progress against a goal simply by asking … Continue reading

Impact mapping using rings

I’ve been doing a lot of impact mapping recently, but when my friend Matt Hosking got involved he noticed a problem: it makes very poor use of wall space. And as a result of that he suggested laying it out differently—in rings. I’ve now had a chance to try it, and I can report that … Continue reading

Agile frameworks do have some merit

Last week I came across a post by my friend Kelly Waters, in which he bemoaned the many competing Agile methodologies, and said that he thought “the best advice is to go back to basics and apply those basic principles without layering over them a whole tonne of processes“. I agreed, but didn’t add my … Continue reading

Is this team the best it can be?

Recently I was part of a discussion on team improvement, and someone asked “How do you know if a team is the best it can be?” My first instinct was to ask why it matters, although I couldn’t think of way of doing so quickly and be sure I wasn’t sounding rude. However, that’s definitely … Continue reading

Justifying the time to collaborate

I was speaking to my friend Matt Hosking, recently, about the problems with making the time to collaborate when an organisation is in the process of adopting agile. We often speak to people who feel that collaboration, as emphasised by agile approaches, is an additional time sink. They feel they need to do all their … Continue reading

The problem with “best practice”

I often hear that we should do something “because it’s best practice”. This raises alarm bells with me, as it sounds a lot like “because other people say so”. It’s more productive to avoid the phrase “best practice” and instead be explicit about why the practice is valuable. I was reminded about this today when … Continue reading

Showing release progress

For many teams continuous deployment is a long way away, and releases are time-consuming affairs, often involving a lot of people working intensely. Often that means the release is significant, because a consequence of a lengthy process is that it’s performed infrequently, which in turn means that the new version carries a lot much-anticipated functionality. … Continue reading

Innovation from standardisation

My colleague Nic Price pointed me to a page on the BBC GEL site, which talks about the value of standardisation and consistency. GEL is the BBC’s “global experience language” and described as “the BBC’s shared design framework which enables us to create consistent and delightful user experiences across all of our Digital Services.” The … Continue reading