Three Things To Know About When To Use Scrum

When most people think of when to use Scrum – and other agile development frameworks or models – they often think of software. This is partly because the agile manifesto contains the word “software” a number of times, and partly because it has been found to be such a natural answer to many of the needs that the software industry has faced and continues to face. However, as someone who isn’t a software person, I’ve always been interested in how the principles can apply in different environments. I used an agile approach to write my books for example, Team Wikispeed used Scrum to build the first 100mpg car, high schools are using Scrum in education, people have planned weddings using Scrum and we have a home improvement product backlog at my house.

Scrum itself was intended to be a framework for agile product development. Building (admittedly largely software based) products in an iterative and incremental manner. But not every product would be suited to an agile approach such as Scrum. So how do you know when to use Scrum and when not to use Scrum? Well I tend to bear in mind three main factors.

Three Things To Know About When To Use Scrum:

How unknown is the product space?

The more unknowns there are (technology, customer demand, functionality etc) then the more we have to gain as product managers or organisations through the learning opportunity built into agile approaches such as Scrum. Rather than attempt to predict the unpredictable, we instead build quickly and learn through tangible development, experimentation and feedback, evolving the product empirically.

How volatile is the product space?

The more likely that requirements, needs, technology, demand etc are to change during the product development process, the more we have to gain from an empirical approach. By expecting change and welcoming it rather than attempting to avoid change through up-front planning, the more responsive we can be and the less fragile our products will be. If things are predictable and unlikely to change then we get less value from the emergent approach and more value from the predictive planning from a more traditional planning approach.

How possible is it to realise value incrementally?

If it is impossible for a product owner to get any value until the very end of the product development effort then there is little point in taking an iterative, incremental approach. However, I find people are too quick to assume that there is no opportunity to realise incremental value. Firstly, these assumptions are often based on our previous experience – we have always done it this way – and we fail to see the opportunities.

Secondly, we may need to be a little open-minded by how we define value.Value does not always mean revenue. Product owners may find value could come in the form of innovation or creativity, perhaps even fast failure. Certainly, many instances of Scrum providing value come from a product owner getting tangible evidence that a product is unlikely to yield a positive return on investment much sooner than they would have learned this from a traditional waterfall approach.

Every product has at least one big risk that, if it materialises, could kill the value of the product’s proposition. Agile approaches such as Scrum give product owners the opportunity to find out what that risk is early on and then either focus on removing or mitigating it or alternatively cancel the effort before we have wasted too much money.

Can you use Scrum to Build a Bridge?

So, could we use an agile approach to build a bridge? Surely half a bridge is no use. It is only valuable when it is complete, right?

Well, firstly, an agile approach would force us to ask, “why are we building a bridge?”. The answer may be obvious but enlightening.

For example, the answer may be “to get people from one side of a river to another”. This answer could provide us with the opportunity to solve this problem in an iterative incremental approach. Perhaps the first version is a rope swing, or a raft or an inflatable dinghy. Perhaps the second iteration of the solution is a rickety wooden foot bridge that allows one person to cross at a time.

Perhaps the third iteration is a stronger, wider wooden footbridge that allows multiple people, or even cyclists to cross the river. We could then expand and evolve the solution over iterations, adding value along the way.

So, the answer to could we build a bridge in an agile way is YES.

The answer to would we build a bridge in an agile way is probably NO. Why?

Well, if we look at my other two criteria I would suggest that the “product space” of bridges is not that unknown – we as a species have pretty much mastered how to build bridges efficiently. Also, the requirements are not that likely to change either so it would probably be best to not use an agile approach. This is the kind of thought process that product owners and product managers typically go through when deciding whether or not to build their product using Scrum or not.

What’s the most interesting use of Scrum you have seen?

What to read next? Why not check out Martin Lambert’s blog post on Commitment in Scrum.