Random thoughts, observations, and variations

Our ProjectManagment.com community discussion board has many recurring topics, one of which is a compare/contrast between PMI's PMP certification and Scrum Alliance's CSM.  I've participated in this discussion on occasion, but I'm a bit embarrassed that I got caught up in it- though not as much as I will be the next time.  It’s really a faulty comparison that we should qualify or avoid.

The first reason the two certifications are not related is because- as I’ve often said- Scrum is not a project management method.  It’s a framework for addressing complex adaptive problems and delivering products.  Although each iteration in Scrum might be considered a small project, and there may be interaction between project managers and scrum teams, there are distinctions between scrum development teams and project teams that we ought to recognize.

Secondly, and more importantly, there are great differences between the roles of project managers and scrum masters.  One has only to read the descriptions in the PMBOK (6^th ed) and the Scrum Guide (2017) to see how different these two roles are.  I won’t attempt to reproduce those here, but let me point out that the entire Scrum Guide is the same number of pages as PMBOK’s description of a project manager.  If the project manager is like an orchestra conductor (an analogy used in the PMBOK), then a scrum master might be more like an assistant to a chamber group.  Because the roles are different, and the career paths are different, the certifications are different.

Third, the organizations’ approach to certifications are different.  PMI, as we know, has strict requirements before granting a PMP.   Prerequisites include degrees, project management education, and documented project management experience, all before taking a notoriously (and purposely) difficult exam under the watch of professional proctors.  By contrast, Scrum Alliance prefers personal coaching and development to proof of knowledge and experience.  The CSM is a relatively short but dense course on Agility and Scrum, and the final exam really exists only to aid the trainer.  My scrum certifications were all earned in small settings, guided by talented coaches who got to know me and who stay in contact with me to this day.  I can’t say the same for my PMP, and I’d wager few of us can.

Finally, we’re comparing different levels of certification.  The CSM is only the start of Scrum Alliance’s track towards a full Certified Scrum Professional (CSP) …and let me tell you that earning those advanced certifications is no joke.  Although the CSP and PMP are still wildly different certifications in completely different career paths, they are at least comparable in that they require proven training, competency, and experience.  In this regard, Scrum Alliance’s CSM is more comparable to PMI’s CAPM.

Let me end with one thing that the PMP and CSM have in common: employers are looking for them.  I can think of no project management certification as widely known and respected as PMI’s PMP.  As of 2018, Scrum Alliance’s CSM still rules the job boards for organizations seeking scrum masters.  But we ought not to observe the popularity of these two certifications and think that they are in competition, or that they are comparable.  They represent different stages of different career paths.

Some of you are familiar with my silly little rants against abused or overused words in project management.  Here's a common and accepted example that I resist: "Waterfall." 

This term is used incessantly online, especially in conversations (arguments) about "Agile vs Waterfall." The term 'waterfall' is used just once in the PMBOK 5th edition, and it's in exactly that context.  It's used multiple times in the PMBOK 6th edition, which could indicate that it has gained acceptance.

My objection to the "Agile vs Waterfall" debate is that "agile" is a set of cultural values, not a project management model.  People who engage in this argument might as well compare apples to screwdrivers.

But my hesitation with the term "waterfall" is that I've never seen a real project that looked like a waterfall.  Have any of you, on the job, ever seen a perfect, serial network diagram that looked like this?

Except for some academic exercises in college, I've never seen a network diagram or Gantt chart that looked so simple and perfect.  I would be immediately suspicious of a plan that looked like this.  Either this project so simple that it has no need for a project manager, or it's in desperate need of a skilled PM to challenge the over-simplified plan!

In the real world, project managers look for ways to accomplish the most work possible in the shortest amount of time.  This is why we're so heavily involved in the planning stages of projects.  We challenge discretionary dependencies and mitigate risks associated with external dependencies.  We seek opportunities for parallel activities so that one member of our project team isn't idly waiting for another.  Our network diagrams don't look like waterfalls, they look like drainage basins, where various streams connect and flow into a final body of water. 

Trivia: Many people attribute the word "Waterfall" as a project management term to Winston W. Royce in his 1970 paper ""Managing the development of large software systems."  But Royce neither used the term, nor did he advocate for it.  Instead, he pointed out flaws in a sequential plan, stating that it is "risky and invites failure."  His diagram also flows both directions, iterating forwards and backwards.  If that still sounds like a waterfall, you should see his final diagram! 

When you're ready to use the word "waterfall," try using alternate (dare I say "old") terms like "plan-driven" or "predictive." I've noticed that this immediately changes the conversation with "waterfall vs agile." After all, a fully Agile organization can use a predictive project plan, given that the conditions support that decision (i.e. the scope is stable, the steps are well-established or repeatable). What agilists in these arguments resent is the ignorance of Agile values. When our most cherished project artifact is just a pretty waterfall, we value a tool over people, and plans over results. 

I promise not to be too big of a jerk about this; I know what people mean when they say "waterfall."  But sometimes, the wrong word choice complicates a conversation or misrepresents the value of the thing it describes.  This is why the PMBOK states "a common vocabulary is an essential element of a professional discipline," and why PMI settled on the term "predictive" and excluded "waterfall" from the project management glossary.  Does is work in some casual contexts?  Yes, but "waterfall" is too often a term that causes misunderstanding, and we'd often be better off avoiding it.

/silly rant

Almost every time I check the discussions on ProjectManagement.com, I find at least one question about doing Agile.  It's often along the lines of "I've been a project manager for two months, already; how can I get a job as an Agile coach?"  (It reminds me of the classic question, "How can I get my PMP and skip all the education and experience requirements?")

These questions typically receive the same general answers, so let me summarize them.  (Note: I've stolen some content from people smarter than me.)

1. "Agile" is not a project management methodology.  It's not a method at all.  It's a set of common values and principles that an organization can either adopt or reject.  The most frequently cited and commonly held set of these are contained in the "Manifesto for Agile Software Development."  It fits on 1-2 pages, depending on your font size, and you should read it before you continue.
2. The history of "Agile" predates the manifesto by decades.  It springs from a rich history of process and manufacturing improvement, such as Lean, and predates the modern "software" industry.  Much has been written about it by people directly involved.  If you look, you'll soon find that businesses are still wrestling with process and management problems that were resolved by others decades ago.
3. Agile is not the enemy of Waterfall, and Waterfall should not be considered the "old" or "traditional" way of managing projects.  (I don't like the term "waterfall," but that's another topic.)  PMI does a good job identifying best methods and practices for managing projects, and continues to revise their standards with new and proven ideas.  However, as I stated above, Agile is a culture, not a management methodology.  
4. Agile is adopted to make organizations more adaptive to internal and external change.  These changes could come from a variety of sources, such as changing market conditions, competition, or new technology.  Major changes require rework (waste) to your project plan.  If your organization struggles to deliver new products because of change, then it should consider Agile.
5. Conversely, there's nothing that says you can't use a predictive plan in an Agile organization.  There may be times when it makes perfect sense.  If a project has relatively few unknowns, a stable scope, and is repeatable, then a plan-driven project might even have some advantages.
6. Agile is not an absence of discipline.  Agile frameworks require at least as much discipline as other frameworks, and often more.  This is one of the reasons why they seem to fail, because organizations lack the discipline required to succeed.
7. Another reason Agile frameworks seem to fail is that they're not properly implemented or supported.  A common conversation goes like this:
   "We tried Scrum, but it didn't work."
       "Did you have a bad product owner or scrum master?"
   "No, we never hired either of those positions."
        "Then who kept your backlog?"
   "We didn't keep a backlog, we worked off our waterfall plan."
        "Then you weren't using scrum."
   "That's what our lead developer said, so we fired him."
8. You, as a project manager, cannot "do" Agile.  You can't implement it, force it on your company, or manage a project with it.  As already stated and repeated, Agile is not a project management method, it's a collection of values and principles that your organization can adopt or reject as a part of its culture.  If you try to be Agile in a non-Agile organization, then you will be operating on a different set of principles and values.  That creates a lot of friction!  If you can absorb the heat, you might be able to sustain an Agile "bubble" in a traditional culture, but you'd better be prepared.
   (This is a third reason why Agile frameworks fail, because the organizations aren't really Agile.)  
9. Agile cultures can be very threatening to those who thrive in the middle management levels of highly bureaucratic cultures.  These are the people who will generate that heat that I mentioned, above.

This is just a summary.  There are plenty of books written about this topic, many of them written by people more educated, eloquent, and serious.  Good luck and happy reading.