Working practices

This category contains 79 posts

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

Maintaining the momentum into BAU

How do we ensure that when a product launches and moves into BAU (business as usual) mode it doesn’t become a second class citizen among our work? We all acknowledge that releasing a product isn’t the end of the story—sometimes we say “it’s just the beginning”—because now when we understand really how people use it … Continue reading

Winning hearts and minds for meaningful change

I was struck by a comment last week from a security vendor. The article appeared on Ars Technica, and the journalist, Rupert Goodwins, was deploring the fact that most vendors of security tools cannot say how effective their solutions are. “If vendors were doctors, then indeed many of them would get struck off the medical … Continue reading

Being trusted and verifiable

Of all the GDS governance principles for service delivery, the one I probably repeat most often is “Trust and verify”. As written it’s directed at managers—it’s to ensure they give the team more freedom (“trust”), but to also to let them know they can still have some assurance (“verify”). Yet despite the positioning towards managers … Continue reading

The Siren call for consistency

I often come across the call for consistency… it sounds sensible, but can often be more damaging than people expect. Here I am talking about enforcing consistency across teams, projects, departments, etc. It might be about using the same user-story tracking tool, having different teams’ iterations in sync, reporting project progress using a standard template, … Continue reading

Antifragile book review: Useful but painful

I recently finished reading Antifragile, by Nassim Nicholas Taleb, so here my thoughts on it, as its message is strongly related to a lot of what I write about on this blog. In short, it’s a book with useful ideas and a very practical perspective on the world (organisations, economics, daily life), but it suffers—severely—from … Continue reading

The power of running like clockwork

In a lot of the work I do people value their flexibility to respond—hence the word “agile”. But being agile relies a lot on things that are fixed and regular—in other words, things that people can rely on. And most important of all is a regular schedule. This includes the length of an iteration or … Continue reading