I'm sorry to say the Stacey Matrix as presented did not help me at all. The explanation seemed like Agile hype. And I'm a big proponent of Agile! I now have a CSPO certificate and a year of experience watching Agile and Waterfall teams work together. However due to the mentioned culture clash I was very much on the lookout for any kind of hype or religion. I needed sound arguments for why any methodology, in part or in whole, should be adopted or avoided.
Here's how I remember the diagram:
Really? Do you think you could get Waterfall proponents to agree to that? The same folks who develop little programs like operating systems and database engines? Again, I'm an Agile proponent, but I am faced with a challenge of addressing the morale of software developers with a long history of successful Waterfall projects. Developers in general are typically smart folks. Repeating any kind of hype or religion would only remove me from their list of trusted sources. There was no explanation
So after the course I did a little research and was not surprised to find that Ralph D Stacey himself had no intention of using his Matrix to make this decision. On the Ralph Stacey Wikipedia page it says that Stacey "dropped the diagram and now argues against it's use". As much as I like Agile I can't explain why the methodology appears to have such a need to sell itself and to inflate the importance of it's origins.
Well as long as everyone else is mis-using the Matrix I may as well join in. I figure once you put a concept out there you can't take it back. From my experience I propose that Waterfall methodology does have a place, and it is in the upper left quadrant of the Matrix (this is where you have agreement on what, but now how). The lower right quadrant is better for Agile methodology (where you have agreement on how, but not what). The upper right quadrant (chaos) is just as bad for both methodologies, and the lower left quadrant (simplicity) is equally good for both.
Let's start with the biggest reason I like agile: it makes things easier for me, the Product Owner/Product Manager. Yes, requirements do change. Yes, after years of Waterfall Product Management I had a stack of un-implemented requirements documents. The truth is we had a combination of successes and failures. We did deliver several major releases - I won't say on time but with good explanations for the delays - each with significant new functionality. We also delivered a User Interface that was such an abysmal failure it practically put the company out of business. In hindsight it seems apparent where we were succesful and where we failed. Wherever there was a lot of technical designing with dependent features not exposed to end users, we were successful. Where we tried to build rich user-facing features, we failed. So I propose there is a time for Waterfall, I'll call it the "upper left corner".
My first hypothesis is that when you know what to build, the requirements don't change as much over time. Often this is the case when the functionality is not exposed to end users. Take an example such as a complex solution like an Operating System where you want to add a feature, let's say support for a new file system just to pick an example. The point of the example is that success or failure of the project is very binary - either the system supports the standard spec or it doesn't. You only need Product Management / Product Ownership at the beginning to confirm this is indeed a priority. Once the decision is made to begin implementation of that feature, the Engineers can research the IEEE specifications and build it.
However the engineer's job is tough, they have to figure out how to build it. A corolary is that when you don't know in advance how to build something the design does change a lot over time, even if the requirements don't change over time. This means there will be a lot of refactoring. And if the nature of the solution includes layers of logic built on top of other layers, the impact of refactoring is significant. Agile assumes the cost of refactoring is low, however this is not the case when there are large stacks of dependent code. Also Agile does not promise software will be developed faster, it just promises it will bring the most valuable functionality to the market faster. This benefit is missed when the market value is binary.
The antithesis is the "lower right corner". For an example let's take a complicated User Interface. The point of this example is that there are a lot of end user-facing features, and success or failure is far from binary. There are different contexts and user types, and what works in some situations may not work in others. It is possible to be 60% successful, 80% successful, 99% successful. There may be a plethora of functional features that all need to be prioritized. And the requirements do change over time as the software is exposed to different users with the new functionality. The job of the Product Owner / Product Manager is very difficult.
Meanwhile the engineer does not need to spend as much time figuring out how to build it. I've seen teams work through the technology selection in less than a week. They pick a web server like Tomcat or Apache, they pick a back-end data store like MySQL or PostgreSQL, they pick a front-end technology like HTML5, add some third-party frameworks, etc. Over the course of the project it is unlikely these technical (non-functional) requirements will change. And most features, while dependent on these technologies, are not neccesarily dependent on each other, so refactoring can indeed occur without major setbacks.
My next hypothesis is that the other two corners of the Matrix are equal with respect to development methodologies. I'm not saying the development methodologies are equal, I'm just saying the Stacey Matrix does not provide any reasoning for why one method would be better than the other. To me logic from the Stacey Matrix alone says that if a project is very simple, either methodology will be successful. If a project is very complex, niether methodology will be successful.
Again I do not believe the two approaches are equal. First it is rare that an application has a deep stack with lots of dependencies and little user-facing functionality. Second if one ever has a choice of architecting code with more or less dependencies, one should pick less dependencies! Maybe that's obvious but the point is that Agile methodology promotes better software design. In my experience at software companies that have mixed methodologies, 90% of the teams are Agile. Third, even if you do have little user-facing functionality, Agile proponents suggest building in small increments and testing as you go as a means of showing progress. So Agile methodology promotes better management as well. Fourth I like Agile because it is in-line with requests from two major sources of experts: User Experience experts and Testing experts. Every expert I know from both of these fields always plead "don't wait until the end of the project and then bring in the UX/QA teams." Finally I like Agile because it makes my job, the Product Owner / Product Manager, easier.
So what should you do if you find that 1 in 10 project that calls for Waterfall? I would suggest going as close to Agile as possible with two modifications. First put a large design spike at the beginning. Maybe call it a Design Tower. Once the engineering team is through the design, they should be able to put together a plan like they usually do - but without a gantt chart. They should call out milestones along the way, however these milestones may not fall onto any sprint rhythm.
But then they can start sprinting. Not every sprint will show something demo-able to end users, but there should be some way to show a rhythm of progress. Maybe passing certain tests, or finishing an API that other developers can begin using. There should be something that can be verified by team members other than the ones who created it. One important aspect of the Agile rhythm is that the team can efficiently change direction at the end of any sprint. What I have seen happen in classic Waterfall projects is that other requirements come along in addition to what the team is working on, but the original requirements are still required as well. For this the sprinting methodology can help a waterfall team. I would suggest that the team strive to have sprints where the work is saved in a manner so that the team can efficiently be interrupted, go fix other problems for a sprint or two, and then return to the original project plan - with all the dates sliding to the right by the length of the interruption. (The alternative with standard Waterfall methodology is to just pile on the additional requirements which leads to a lot of inefficient resource swapping and a slippage of dates without clear reason).
The second modification is to limit requirement changes with the same process that would occur under a Waterfall methodology. Keep in mind the assumption for this project is that the requirements are easily understood and binary. If the requirements do change, the Design Tower at the beginning will likely be invalidated.
Well I have to apologize to Professor Ralph Stacey for mis-using his matrix again, but hopefully it can be one tool for developers to think through the kind of methodology they choose.
Brad Kekst has over 20 years experience in the software industry and is currently a Product Owner in Silicon Valley.
Says Stacey "dropped the diagram and now argues against its use".
Great objective, non-religios comparison of the methodologies.
Another great tool for choosing methodologies, the requirements-resources-time triangle.
Here is the common application I've seen of applications of the Stacey Matrix to Agile/Waterfall methodologies:
By Jimi Fosdick | Posted 2010-10-29
Jimi cites Stacey Matrix as a linear scale.
Says when to use which, but again a linear scale.