Nik

Nik has written 396 posts for niksilver.com

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

Specific risk guidance is troublesome

I’ve been (re)reading a bit about “risk appetite” again recently. Some of the reading includes messages saying it’s a confusing term, it’s a bad idea, or that it’s a good idea that’s really important to manage properly [pdf]. One of the things that occurred to me during this is that it’s actually very difficult to … 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

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

Expressing value statements with measures

A short time ago I wrote about the importance of having a value statement, which is a short statement of the value that a project (or programme or team) is accountable for delivering, and which allows us to measure that value. But in practice it’s often difficult to have a short statement which also describes … Continue reading

The reusable component is the team

I was talking to some colleagues once about how to help a team move on from their current product and focus in a new direction. The team’s latest development was well received, but they were having trouble leaving it behind—they wanted to continue working on it according to their earlier plan when other priorities said … Continue reading

Separate strategic assumptions from goals

Previously I wrote about the importance of having a clear goal, in the form of a value statement. But in practice it’s tempting to confuse a goal with what I call a “strategic assumption”—and we shouldn’t do that. When I ask a project team what their goal is they usually suggest a number of things, … 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