Working practices

This category contains 101 posts

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

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