The Stacey Matrix Revisited

We’ve been spending more time helping non IT teams think about applying agile. In doing this we’ve come to realise just how much IT jargon exists in much of our usual teaching materials. One example is the Stacey Matrix. The Stacey Matrix is commonly used in agile/Scrum training to explain where agile is most appropriate.

The traditional Stacey matrix maps the domain of projects according to their requirements and technology.Recently when explaining this to a non technical audience the struggled to understand what requirements and technology mapped to in their world. I used a simpler explanation of the axes.

Instead of requirements, I called the y axis – What. Basically what you want to do. It can either be well understood and agreed by all, or it can be very vague or there could be a lot of disagreement about what you should be doing. Instead of technology, I called the x axis – How. How you will do the work. It will vary between a well understood way that you have used before to something completely new or unknown to you.

The group seemed to intuitively grasp What and How a lot better than Requirements and Technology. Especially since there projects were things like organising Roadshows, or marketing campaigns. With these new labels, we can classify 4 different types of projects as is done in the original Stacey matrix. Projects where everyone agrees and knows what needs to be done, and how it will be done, and it has been done that way before, would be classified as simple.

[blockquote align=”center” variation=”green”]Weird Fact: Turns out that Ralph Stacey, the person who created the Stacey Matrix, is South African![/blockquote]
Projects where there is something unknown in either what will be done, or in how it will be done. For example maybe working with a new vendor on something, would be complicated. Projects where you simply have a difficult goal like doubling market share , but no idea what to do to achieve that or how to go about it would be considered chaos. Everything else would fall under complex.

Once you understand where your projects fit, you can decide on the best approach. Traditional defined approaches with a plan defined at the beginning with tasks, people responsible and deadlines, work well for simple, and sometimes for complicated. Agile approaches where you plan a small piece, execute it and then see where you are against the goal, and adjust your plans accordingly are a much better fit for complex and chaotic project.

Thinking like this can help you identify where agile might help you the most. That’s a good place to start. If you apply agile to simple projects you probably won’t see massive benefits as the project was likely to be successful however it was done. To see the greatest benefits from agile you should look to trying it out with complex projects.