When to use Agile?

When do you use Agile? When shouldn’t you Agile? I get this question often in my trainings, and I believe that’s a very valid question to ask! Is Agile a one size fits all solution? No, of course it’s not! Is it implemented like it’s a one size fits all solution? Yes, I see that quite often as well, however, that should not be the case! On the other hand, complexity keeps increasing within organizations and the frequency of changes in the market, government, at competitors and at customers keeps increasing as well, so you should probably do something about that… Whether or not Agile should be the solution? Well let’s find out!


As a reference model, I often refer to the Stacey Matrix in my trainings for determining whether or not Agile may help you out. The Stacey Matrix is a model that may help you in determining the best approach or way of working for your context. In this model, we look at 2 important perspectives: Requirements (what to do) and Technology (how to do it). Dr. Stacey has created four domains in the Stacey Matrix, called the Simple, Complicated, Complex and Chaos domains. In order to determine in which domain you are operating, you should look at the stability/predictability of both the Requirements and Technology aspects. In my trainings, I often also take the “People” perspective into account, since people may have an equal impact on the success of projects, if not even bigger. So before we determine in which domain you reside, let’s take a look at the meaning of Requirements, Technology and People.

Requirements – Regarding the Requirements perspective, we consider everything related to “what” needs to be done. For example: What is the vision? Wat is the purpose? What are the goals? What are the business requirements? What are government/legal requirements to be taken into account? What company policies need to be taken into account? And of course, will these elements be stable over time? Are you sure the customer won’t change his mind during the project? Can you be absolutely sure that the requirements will not ever change during the project?

Technology – Technology is all about “how” we will perform the job to be done. For example: Will our (project)approach be stable? Will our equipment be stable? Do we have all the equipment/devides needed in order to create the product? Will new technologies emerge during the project that might provide us with opportunities or threads? Will the technology require updates or new versions of software? Could it be beneficial to adapt to new technologies, applications or software?

People – The People perspective is about the availability of people, their knowledge, skills, experience, commitment, emotions and (personal)interests. Are we sure we have all the people needed to complete the project? Are we sure these people are the right people? Are they motivated? Could we continue in their absence for holidays or illness? Do they have all the qualities needed to get the job done? Will their interest and motivation be stable over time? Will they remain available throughout the entire lifetime of the project?

Considering the three perspectives as described above, try to determine your context based upon the following questions:

  1. On a scale of 1 – 10, how stable/predictable are the requirements for my project, during the entire lifespan of the project? (1 = very stable, 10 = very unstable)
  2. On a scale of 1 – 10, how stable/predictable is the technology to be used for my project, during the entire lifespan of the project? (1 = very stable, 10 = very unstable)
  3. On a scale of 1 – 10, how certain am I that I have all the people, knowledge, skills, availability and commitment for my project, during the entire lifespan of the project? (1 = very stable, 10 = very unstable)

The table below can be used as an indicator (it’s an indicator, not a scientific calculation) for the domain you’re in.

Requirements Score Technology Score People Score Total Score
Simple 1 – 2 1 – 2 1 – 2 0 – 6
Complicated 3 – 4 3 – 4 3 – 4 6 – 12
Complex 5 – 8 5 – 8 5 – 8 12 – 24
Chaos 9 – 10 9 – 10 9 – 10 24 – 30


Okay, so now we’ve determined the domain, let’s take a look at the best approach for each domain:

Domain Characteristics Best Approach for domain Examples
Simple Repeating work, no or very few changes regarding requirements and technology, most work is automated or production work Just Do It – Since work is very predictable, there is no urgent need for analysis, planning, validation or adaptation. Factory work, like producing furniture, cars or other physical products that require little human interventions to keep coming off the assembly line.
Complicated Work is complicated, there are some factors that have an impact on the end result and some of these factors/variables will change over time, but can be managed when you have a solid analysis and plan for the project before starting. Follow a plan – Work requires analysis and planning in order to start, creating a proper analysis and solid plan for the project will result in a good product or successful project, when managing scope, timelines, budget and quality. Building a house, building a new assembly line, road construction, creation of physical products based upon a plan, typically these projects are some kind of building projects.
Complex Work is complex, innovative, hasn’t been done before or has very little repetition. Requirements are certain to change over time and requirements, technology and people have a major impact on the success of the product or project. Empirical approach – the Scrum Framework is based upon Empiricism and resides best in the complex domain. In order to be successful, you will need to frequently inspect and adapt. This domain requires some analysis and some planning, but in order to increase success, you will need to deliver value to customers, get feedback and improve (build-measure-learn) continuously. Software development, innovation, new product development and all other project where the requirements,  technology and/or people factors are very likely to change during the project.
Chaos Very little is known, both requirements, technology and the people factors are extremely uncertain. Adhoc – By continuously building, measuring and learning in extremely short cycles, you will learn over time what you need to do, how to do it and if you have the right people on board. Very short time to learn cycles may be required in order to make progress. Start-up organizations need to validate extremely fast that they are doing the right stuff, doing it the right way and that they have the right people. Also accidents or disasters reside in the chaos domain, since there is always much more unknown than known.


The table above shows that the Scrum Framework best resides in the Complex domain, whilst other domains require different approaches. Agile and Scrum aren’t the same thing however. There is also no way-of-working, framework or method that is called ‘Agile-Scrum’. Although I hear ‘Agile-Scrum’ being mentioned in many organizations, it is actually a misunderstanding. If you want to learn more about Agile and Scrum, and their differences, please read this blog.

Coming to a conclusion, we can state that Scrum is a framework that best resides in the Complex domain. Agile on the other hand is a mindset, containing four values and 12 principles. These values and principles can also be found in this blog, as mentioned above. And the values and principles of the Agile mindset can be applied in any given context. It isn’t suitable for the Complex domain only. The values and principles could also be applied in the Simple, Complicated and Chaos domain. And to illustrate this, here are some questions for you: Isn’t it always valuable to focus on the customer? Isn’t it always a good idea to deliver value? Would it hurt to ask people for feedback? Probably not. And that’s why an Agile mindset could be a good idea in any given context. But remember: Agile isn’t the same as Scrum! And don’t implement Scrum throughout your whole organization! Use it for work that resides in the complex domain.

I hope this blog helps. Good luck in your Agile Journey!