Awaiting An Agile/Scrum Rescue

 

When I was a younger manager, and would find myself in a meeting with peers and superiors where some notion would be put forth that struck me as singularly dopey, only on rare occasions could I resist the temptation to point out its failings. The vast majority of the time I would be quick to point out the ideas’ flaws, typically using rather direct language to do so. Some people would appreciate my honesty and insight, but the majority would resent the daylights out of me. At the time I felt strongly that I had an intellectual duty to my employer to point out the follies of those who would set the technical agenda for a given project, but clearly lacked the experience, education, or intellect to do so. It wasn’t personal – to me, it was always business, and doing PM right is serious business.

After a while it finally penetrated my thick head that, while dopey ideas would always be presented in such meetings, and would often seem to gain some level of traction with participants, I didn’t necessarily have to be the person to point out the folly. I belatedly began to realize that, if little ol’ me thought that what was being expressed was dumb, in a room of intelligent people the odds were pretty good that at least one other person thought so, too, and that person could probably convey the rational opposition better than I could.

Meanwhile, Back In The … Hey, Wait! We Never Left The Project Management World!

Seasoned members of GTIM Nation know all too well my rejection of risk management (no initial caps) theory, since I have regularly referred to its modern-day practice and techniques as openly fraudulent management science. Rather than go back over my (rather lengthy) list of reasons why risk management (no initial caps) as currently practiced is a monumental waste of time and money, I’m going to restrain my poison-pixel pen, and let the Agile/Scrum approach (ProjectManagement.com’s theme for September) aficionados take over.

First off, consider how Agile/Scrum PM got its moniker in the first place. According to Dictionary.com, the first three listed definitions of “agile” all have to do with being “quick,” or “active.”[i] It’s pretty clear to me that naming a PM strategy “agile” in the first place emphasizes its ability to spontaneously adapt to changing circumstances, in a way that demonstrably surpasses traditional Project Management techniques. In essence, rather than spending the time and money to develop a risk analysis document, and use it to generate the risk management plan, using decision tree, Monte Carlo, or wild guesses expert opinion in an ultimately vain attempt to quantify the future, Agile/Scrum addresses programmatic risk by relying on the Project Teams’ abilities to recognize problems and, ahem, deal with them. It really is that simple. It’s also why you won’t see risk experts performing their kabuki theater analysis techniques on software projects. Information Technology PMs know which aspects of traditional PM will help them bring their scope in on-time, on-budget, and risk management doesn’t make the cut. Yes, I know that Agile/Scrum’s main claim to fame is its ability to effectively streamline the configuration management cycle in such a way as to not introduce a vulnerability to that most lethal yet insidious of project-killers, scope creep. But I also know that it’s worth pointing out that, of the traditional vestiges of PM that were notably left out of the new paradigm, risk management (no initial caps), once considered one of the four “core” chapters in the PMBOK Guide®, has to be the most conspicuous.

In fact, back when I was doing my column for PM Network, I did a piece entitled “PMBOK, Schmimbok,” (PM Network, January 2007, pp.14)[ii] where I discussed the appropriateness of each of the then-chapters of the famous PM guidance. I challenged the notion that communications, quality, procurement, human resources, and (of course) risk were truly germane to project management, as opposed to any other kind of management. Flash forward to 2020, and what does Agile/Scrum do with each of these? Communications and quality are still major components, but specifically modernized for Information Technology projects’ environs, while procurement, human resources, and risk have fallen off the back of the epistemological truck altogether.  None of this is to say that each of these disciplines isn’t a vital aspect of conducting business; rather, I’m only challenging if they belong in a PM model streamlined for IT projects that, by the way, actually works pretty well.

So it would seem that all of that time I’ve spent challenging the risk managers’ (no initial caps) worldview on its merits was unnecessary. All I had to do was to await the more streamlined, agile variants of PM to gain traction, and merely note that they had jettisoned risk management (no initial caps) theory in its entirety. At the massive conference room table of PM codex development, I could have just shushed, and let the more intelligent and outspoken people take up the challenging of the dopey ideas while enduring the resentment of those who disagreed.

And it happened! I’ve been rescued by Agile/Scrum!

[i] Retrieved from https://www.dictionary.com/browse/agile?s=t on September 20, 2020, 20:-2 MDT.

[ii] http://www.pmnetwork-digital.com/pmnetwork/200701?pg=26#pg26