The Stacey model is a framework developed by Ralph Stacey that categorizes complex problems into four domains: simple, complicated, complex, and chaotic. The model considers the degree of certainty of the problem and the level of agreement on what needs to be done.

• Simple: These are problems that are well-defined, with clear goals, and solutions that have been tried and tested before. There is a high level of certainty, and everyone agrees on what needs to be done. In this domain, traditional project management approaches work best.

• Complicated: These are problems that require expertise, analysis, and multiple steps to solve. There is some level of uncertainty, but experts can agree on the approach. In this domain, traditional project management approaches can work, but some Agile principles such as iterative development and frequent feedback can also be useful.

• Complex: These are problems that are unpredictable and have many interdependent factors. There is a high level of uncertainty, and no one knows the best solution. In this domain, Agile approaches such as Scrum and Kanban work best because they allow for experimentation and adaptation as the project progresses.

• Chaotic: These are problems that are urgent, unpredictable, and require immediate action. There is no agreement on what needs to be done, and there is a high level of uncertainty. In this domain, Agile approaches that emphasize rapid experimentation and quick decision-making, such as Lean Startup, can be useful.

The Stacey model recognizes that not all problems can be solved with the same approach. Each problem has unique characteristics and requires a different level of complexity and uncertainty to be addressed. In project management, it's important to understand the nature of the problem you are trying to solve to determine which approach will be the most effective.

The simple and complicated domains are more straightforward and can be solved with traditional project management approaches that rely on proven methods and techniques. These domains require a clear understanding of the problem, the goals, and the steps required to achieve those goals. In these cases, a project manager can rely on techniques such as Waterfall or Six Sigma to plan, execute, and deliver the project.

On the other hand, the complex and chaotic domains require a different approach. These domains are characterized by uncertainty, unpredictability, and a lack of clear agreement on the best course of action. In such cases, it's important to use Agile approaches that emphasize flexibility, experimentation, and adaptability. Agile methodologies such as Scrum, Kanban, and Lean Startup are designed to address complex and unpredictable problems by allowing teams to iterate, experiment, and learn as they progress.

By using the Stacey model to categorize projects, organizations can select the most appropriate approach for each project. This can help teams achieve better outcomes by matching the approach to the problem at hand. Using the Stacey model can also help teams avoid using an overly rigid or inflexible approach to a problem that requires more experimentation and adaptability.

In summary, the Stacey model provides a useful framework to categorize problems based on their level of complexity and uncertainty. By doing so, organizations can choose the most appropriate approach for each project, whether that be a traditional project management approach or an Agile approach.

1. Stacey, R. D. (1993). Strategic management and organizational dynamics: The challenge of complexity. Pearson Education.

2. Larman, C., & Vodde, B. (2010). Scaling lean & agile development: thinking and organizational tools for large-scale Scrum. Pearson Education.

3. Schwaber, K. (2004). Agile project management with Scrum. Microsoft Press.

4. Sutherland, J., & Schwaber, K. (2011). The Scrum guide. Scrum.org.

5. Highsmith, J. (2009). Agile project management: creating innovative products. Addison-Wesley Professional.

I watch every few years as someone tries to crown a new king. You know what? Agile is dead, but it is also alive and well.

Here are some personal observations on this contentious topic for those of you who are new to Agile.

The word Agile was never intended to denote prescriptive frameworks. In this context, the word just comes from the Agile Manifesto, which was a conversation between some smart people who shared what was working for them as they managed software development projects. The authors “met to talk, ski, relax, and try to find common ground.” It included a small subset of the people who were following new, non-prescriptive, highly documented approaches. It was never intended to be considered Moses coming down from the mountain—it was written on a three-day weekend!

And don’t get me started on Scrum. It was an accidental success! In 2000, I was a project manager for one of the first documented Scrum projects. It was inherently flawed, but it was still held up as a shining example. Granted, I love the simplicity of Scrum, but as Ken Schwaber is famously quoted about Scrum, “Two days to learn, a lifetime to master.” Too many people have learned Scrum, and too few have any idea what it takes to master it.

I have a confession to make: I SUCCESSFULLY DELIVERED PROJECTS USING A WATERFALL APPROACH! There, I said it. We old-timers, like those who wrote the Agile Manifesto, actually saw success before the Agile Manifesto miraculously was written. We managed mission-critical projects and ADAPTED our waterfall approach based on the changes in the marketplace. In the late ’90s and the dot-com boom, market pressure forced us to think differently. We needed to deliver new websites and functionality every week in order to keep up with our competitors. It was not about “being Agile”; it was about doing whatever we had to do to get something out this Friday. Here is what Agile sounded like back then:

“Hey, let’s meet every day and make sure we are on track,” and “Oh yeah, the development guys say that QA is slowing everything down; let’s start automating the common test cases so we can release faster,” or “Don’t bother writing specifications for three months; we will have missed our deadline by then, so let’s just sit down and design the screen together, and I will show it to you when I have it working.”

IT WAS NOT ROCKET SCIENCE—IT WAS COMMON SENSE AND MADE GOOD BUSINESS SENSE, TOO!

I used the phrase new to Agile earlier. By that I mean that if you have only experienced Agile in the last 10 years, you need to realize that any company that has adopted an Agile framework in that time period is a late, late adopter. Companies that needed to develop software quickly in order to be competitive were being Agile long before without worrying about terminology or frameworks. You don’t hear those companies saying Agile is dead. Agile is now in their DNA, and they don’t even call it Agile. It’s just how they run their businesses. In early 2000, I worked at a company using a RAD and JAD approach to software development. Those approaches pre-date Agile by at least a decade but did not have the appeal of the Scrum terminology. They were similar and better in many ways. We did not call what we were doing Agile. We just called it project management using rapid application development.

I have written this post at least a thousand times in my head as I watch this industry that I love get lost in terminology and frameworks. I am told now that I can’t call myself a consultant. I have to call myself a coach. I feel as if coaching distances me from my customer’s success or failures; as a consultant, I have chosen to be part of the journey. Just my opinion.  I NOW HAVE TO BE CERTIFIED AND LICENSED IN A FRAMEWORK IF I WANT TO TEACH SOMEONE SOFTWARE DEVELOPMENT BEST PRACTICES. My 20+ years of experience is less important than if I can memorize the Scrum guide backward and forward…and don’t even get me started on scaling.

I love what I do, which is making organizations and teams more successful. I am confident that if I had never read the Agile Manifesto or the Scrum guide, I would still be as successful as I am today.  I jumped on the Agile bandwagon because it just made good sense, and it gave me and many other people labels for things we were already doing.

I wish now that there was a new king so I could separate myself from the noise, but unfortunately, the new king would look a lot like the old one.

One last piece of advice—not for coaches but for those of you who are still optimistic that Agile is alive and well:

• Identify the problem you are trying to solve.
• Ask someone with a little grey in their hair what has worked before to solve their problem.
• Try it.
• If it works, great, if it doesn’t, try something else.

An Agile framework can make you feel Agile; only people can make you be Agile.

—Me

Dan is the President of Cape Project Management, Inc. He has been managing software development and other projects since the ’90s. In 2010, he founded a company whose sole focus is to make his clients successful. He is passionate, committed, and works with lots of smart people who think like him. If you are looking for ways to make your business more successful, I suggest you give him a call or drop him a note. Remember, advice is free, until it isn’t.