To some, it is bold to assert that waterfall fails in technology management 90 percent of the time. But, where you do not know the answer, it does. Unless you know the outcome with certainty, you need a variant on Agile with its inspect & adapt control method. In Technology Management, installing physical devices and executing automation are examples of "we know the answer" that lend themselves to Waterfall. All else is creative and requires exploration.
Dave Farley is an Agilists who seeks to demystify Agile. In a 2021 video on agile philosophy, he seeks to filter out the agile rituals from the Agile philosophy. I think his video clears up the friction I've seen in creative project management. His entire video is worth the 15 minutes as he unpacks his argument. I like that he give me a new way to express the friction.
He talks about the Defined Process model of control where "given a well-defined set of inputs, the same outputs are generated every time" where "the defined process can be started and allowed to run to completion, with the same results every time." He makes the point that software development with waterfall succeeds only when it circumvents the waterfall defined process.
Then Farley talks about the Empirical Model of control that provides and exercises control through frequent inspection and adaption, which works for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs. This is software development: solving imperfectly understood problems through exploration that yield to unpredictable results. This is the Scientific Method, where we do not know the answer but through a process of experimentation we can get there.
Dave Farley is an Agilists who seeks to demystify Agile. In a 2021 video on agile philosophy, he seeks to filter out the agile rituals from the Agile philosophy. I think his video clears up the friction I've seen in creative project management. His entire video is worth the 15 minutes as he unpacks his argument. I like that he give me a new way to express the friction.
He talks about the Defined Process model of control where "given a well-defined set of inputs, the same outputs are generated every time" where "the defined process can be started and allowed to run to completion, with the same results every time." He makes the point that software development with waterfall succeeds only when it circumvents the waterfall defined process.
Then Farley talks about the Empirical Model of control that provides and exercises control through frequent inspection and adaption, which works for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs. This is software development: solving imperfectly understood problems through exploration that yield to unpredictable results. This is the Scientific Method, where we do not know the answer but through a process of experimentation we can get there.
I have read dozens of articles from various Agile purists who decry the flaws of methodologies they view as heretical. Scaled Agile (SAFe) is a perfect example of agile heresy, with an article saying Scaled Agile is a marketing framework. The argument of that article is SAFe is "safe" for management by not making them change behavior. But, this is ignorant of SAFe recommendations, practices and intent. I would agree SAFe is unduly focused on hiring SAFe trainers to evangelize, but if you take SAFe at its word and apply its core tenants, it is Agile and can solve Empirical problems.
Farley reminds his reader that a core tenant of Agile is Inspect & Adapt, which is important enough to SAFe that they dedicate a page to the topic. I do not want to turn this article into a SAFe polemic. I'm an advocate of understanding the creative problem you have to solve, and establishing a repeatable defined process for addressing that problem. We have the advantage of eXtreme Programming, Scrum and Scaled Agile to give us established practices.
All organizations evolve differently. I previously discussed how Basecamp created their own empirical creative methodology and claimed it transcended the waterfall/agile conflict. Competent Agilists identify a basic methodology that fits their organizational culture, then through Inspect & Adapt evolve that methodology to simultaneously aligns and transforms the culture to one that uses scientific engineering principles to monitor and control creative endeavors.
If you are not Inspecting & Adapting...then you are not doing Agile. If your process of creation are not improving over time, you are not doing agile. Blindly following Scrum without adapting it to your organization's changing needs is not Agile.
--
Ben
In tenebris solus sto
Farley reminds his reader that a core tenant of Agile is Inspect & Adapt, which is important enough to SAFe that they dedicate a page to the topic. I do not want to turn this article into a SAFe polemic. I'm an advocate of understanding the creative problem you have to solve, and establishing a repeatable defined process for addressing that problem. We have the advantage of eXtreme Programming, Scrum and Scaled Agile to give us established practices.
All organizations evolve differently. I previously discussed how Basecamp created their own empirical creative methodology and claimed it transcended the waterfall/agile conflict. Competent Agilists identify a basic methodology that fits their organizational culture, then through Inspect & Adapt evolve that methodology to simultaneously aligns and transforms the culture to one that uses scientific engineering principles to monitor and control creative endeavors.
If you are not Inspecting & Adapting...then you are not doing Agile. If your process of creation are not improving over time, you are not doing agile. Blindly following Scrum without adapting it to your organization's changing needs is not Agile.
--
Ben
In tenebris solus sto