In previous blogs I have referenced the old saw of “Quality, availability, affordability: pick any two” as it applies to Project Management. This week I would also like to pull in a discussion of Thomas Kuhn’s groundbreaking book The Structure of Scientific Revolution (University of Chicago Press, 1962), and how manifestations of Kuhn’s theories have been exhibited in the introduction and advancement of Agile/Scrum PM strategies in the Information Technology arena.
Briefly, Kuhn pointed out that, while the common perception is that scientific and technological advances appear to occur at a somewhat steady pace, the opposite tends to be the truth. Kuhn actually introduced the term “paradigm shift,” and theorized that scientific advances follow this model:
Phase 1 is the pre-paradigm phase, marked by the absence of a single, widely-held theory that explains the preponderance of occurrences within the given field of study.
In Phase 2 normal science begins, where most problems can be evaluated within the hypothesis-experiment-confirmation/overturning cycle. However, should a series of problems or anomalies occur that the commonly-held theory/theories cannot adequately address, a series of cycles and then epicycles are layered onto the prevailing theory/theories to account for them.
Phase 3 is marked by the occurrence of the commonly-held paradigm proving unable to adequately address an increasing number of problems or anomalies, eventually leading to an entirely new paradigm being introduced that appears to not only explain the previous paradigm’s older problems, but also accounts for the newer issues that the old theories could not adequately explain.
Phase 4 represents the “paradigm shift,” where the new theory begins to displace the previous one(s) while overcoming the inertia inherent in the dramatic modification (or even overturning) of a widely-held belief structure.
Phase 5 is, essentially, a return to Phase 2, just with the new paradigm being used to solve problems, resolve anomalies, and predict future behaviors.[i]
So, how did the introduction of Agile/Scrum for Information Technology PM perform against this model? I believe we have yet to see the final answer to that question, since much of the literature for Agile/Scrum does not appear to present as a direct challenge to more traditional PM practices, but more like cycles and epicycles – distinct but less-than-revolutionary – changes to the current paradigm. For example, Agile/Scrum does not propose to eliminate the change control process, but to radically streamline it.
However, if there were to be a principal associated with Agile/Scrum that did represent a potential paradigm shift within the PM community, I believe that it would have to do with the fourth “value” of The Agile Manifesto[ii], “Responding to change over following a plan.”[iii] “Following a plan,” in traditional PM parlance, is “Freezing the baseline,” and informal changes to an established cost/schedule baseline are, to engage in a massive bit of understatement, strongly discouraged. Conversely, Agile/Scrum represents itself as being on the opposite side of traditional PM on a scale where the extremes are “Adaptive” and “Predictive,” with Agile on the former end, traditional PM on the latter. I have come to the conclusion that the reason Agile/Scrum was so readily embraced by the IT project management culture at large is due to the prohibitively lengthy and formalistic aspects of traditional change control, which typically involve the documented and approved establishment of:
- a change control board, with their authorities and thresholds spelled out in precise terms,
- a nominal schedule for reviewing baseline change proposals or requests (BCPs, or BCRs),
- another nominal timeline for how rejected BCPs/BCRs can be either appealed or amended for re-submission, and
- yet another timeline for how approved changes are to be implemented and reflected in the baseline documents, as well as how these changes are recorded in such a way as to establish an audit trail.
For projects like the ones that make up the brunt of Information Technology work, this process was simply untenable, which is why, for example, each Sprint Planning Meeting functions as a practical, streamlined substitute for the Baseline Change Control Board meetings. I believe that this aspect alone points unmistakably to a trend in Project Management away from the “predictive” models and towards the “adaptive” strategies, and not just for IT projects.
Of course, in the realm of government contracts, the various sponsor agencies have an obligation to provably spend the taxpayers’ money wisely, so the predictive models and traditional ways of conducting baseline changes will never be abandoned in their entirety. However, my prediction (it is, after all, New Year’s Eve) is that, as those project teams who are using the more adaptive approaches to their Statements of Work consistently out-perform those following the more predictive methods’ strategies, the adaptive methods will become more and more attractive and will gradually displace the more commonly- (and currently-) held paradigms, at which point the shift will have begun.
It will be at that point that we can recognize and confidently announce the innovative trend that changed Project Management.
[i] Wikipedia contributors. (2018, December 8). The Structure of Scientific Revolutions. In Wikipedia, The Free Encyclopedia. Retrieved 04:13, December 23, 2018, from https://en.wikipedia.org/w/index.php?title=The_Structure_of_Scientific_Revolutions&oldid=872736571