Agile

This category contains 131 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

Feedback happens, whether we respond or not

The other day I was listening to BBC Radio 4’s Thinking Allowed, which on this occasion focused on “Platform capitalism”. This is the world of Uber, AirBnB, and TaskRabbit, in which the company in question acts as a broker between those able to offer a service and those seeking it. Being Thinking Allowed it focused … Continue reading

Delivering incremental value in an investigation

How do we tackle a piece of investigation in an incremental manner? It’s much easier when we’re delivering a tangible thing—we stand up at our show and tell, and say “Last time we showed you we could do X, now we can show you we can also do Y.” But for investigation work it’s not … Continue reading

There’s trouble in MoSCoW

Most project teams I work with prioritise their work in a simple order: most important, second most important, etc. But sometimes people still use the MoSCoW method, and I find this leads to problems. MoSCoW stands for Must, Should, Could, Won’t—it’s a way of categorising deliverables into one of four buckets. The Musts get done … Continue reading

Being accountable for delivering value

There are lots of things that make an effective team, but one of the most important, I’ve found, is to make sure they have a clear and meaningful goal. Part of this is to separate the goal (or the benefit, or the value)¬†from the way they’ll achieve it (the solution), and then make them responsible … 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

Moving from “if” we’ll deliver to “when”

On too many projects it’s easy to get caught in a debate about if we’ll deliver. There is some fixed point at which we’ll be judged—very likely a specific date—and when that happens we’ll look at what we’ve produced and see whether it matches our pre-defined threshold of “acceptable”. If delivery of “acceptable” is in … Continue reading

Frequent delivery is the test of a plan’s quality

There are many ways to measure a plan’s quality. Some of these are: flexibility, how realistic it is, and the number of internal or external dependencies. But in the end for most people a plan is about delivering some end result within some stated time. A plan shows both approach and time—How and When. It … Continue reading

Prefer a backlog to a scope

I was speaking to a colleague recently about how her teams were getting on, and she said, “I’m pleased that we’re talking more about prioritising a backlog, much less about what’s in scope. That’s really good.” And it is good news. It shows that the teams are thinking much less about a single large edifice … Continue reading

If you can’t measure, prioritise

When planning a piece of work we can often find ourselves trying to measure or score the various features according to their value. For example, if our project is to attract new users to our product then Feature A might be measured as expecting to bring in 800 new users a month, while Feature B … Continue reading