Agile

This category contains 132 posts

The map is not the territory

My daughter and I are currently reading Lemony Snicket’s very entertaining “Who Could That Be At This Hour?”, a book in the series of “All The Wrong Questions”. And there is a constant refrain I think is very useful: The map is not the territory. The book tells the story of Mr Snicket’s apprenticeship as … 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

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