Random thoughts, observations, and variations

Last night, my wife came home from the new Star Wars movie with a half bag of popcorn.  (I haven't seen the movie, so don't spoil it for me.)  I took a piece and lazily tossed it to the dog, who caught it in mid-flight and silently swore that I was now his favorite.  So I tossed him another.  And another.  And then I accidentally tossed two at a time.  The dog froze- his mouth wide open and poised to leap- as two puffs of popcorn softly floated by either side of his mouth.  He missed not just one piece of popcorn, but two!  

This captured my attention, so I tried a simple experiment.  I tossed a single piece, and he grabbed it from the air and swallowed it before he landed, as he had so many times before.  Then I tossed two pieces again, and he sat nervously as they sailed past his reach.

I called my son over and shared the tale of Buridan's Ass.  Jean Buridan, a French philosopher, told the story of a donkey who was placed between two similar bales of hay.  The ass couldn't decide which bale was bigger or closer, and so it sat indecisively between the two bales and eventually died of hunger.

In the centuries since Buridan gave this illustration, we've reinvented the general idea with more modern descriptions.  In my career, I often reference Cyril Northcote Parkinson's familiar Law of Triviality, in which organizations spend disproportionate time and resources to the least important issues.  Or I might describe Edward Fredkin's paradox, in which two alternatives become more difficult to choose between as they become more equal.  My own description states that the most difficult decisions are those in which there are no wrong answers.  (This is why I always carry a large coin.)

But neither Parkinson nor Fredkin were in my kitchen.  There was only my dog, starving to death because he couldn't choose between two equally attractive pieces of popcorn.  I couldn't help but wonder if Jean Buridan's story was more than a fictional illustration.  My son couldn't help but wonder if we had enough popcorn to torment the dog all night.

This story isn't merely about four-legged animals, though.  Individual persons have difficulty making simple decisions, and it becomes increasingly difficult when a decision involves a group.  But indecisiveness is detriment to people, organizations, and projects.  It causes delays, wastes resources that are better spent on other things, and makes us miss opportunities that our competitors will catch.  

A good decision now is better than a perfect decision later, or something like that... both Roosevelt and Patton said it better.  If I may paraphrase Boyd's Law, the timeliess of decisions can be more important than the quality of decisions.  This is because you won't often know if you made the right decision until you act on it and observe the results.  But small, incremental decisions can be corrected.  The longer you delay a decision, the larger and more consequential it will become.  

Coincidentally, it's almost 2020.  May your new year be full of good decisions, starting with that resolution to eat right and exercise that you'll make again.  Don't let the decision-makers on your projects escape their responsibility by asking for additional, meaningless data or by scheduling a series of follow-up meetings to revisit the issue.  These delays starve your projects to death, and they make an ass of us.

And don't forget to feed your dog.
 

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.

Before I begin, let me explain that the following should be taken lightly.  I'm not going to argue with anyone who takes this too seriously.

I've been a participant in many a conversation about project management "methodologies."  I always twitch- hopefully not noticeably- because I'm a slight bit of a word nerd and this is one of those terms that's often used incorrectly.

Before I argue my point, let me explain why I'm wrong.  The word "methodology" has- depending on your dictionary- evolved to a fancy way to describe a system used to accomplish a specific type of work.  In scientific circles, this is understood as a set of principles used to design a test for a hypothesis.  In other words, the methodology determines the method.  The business world, including project management, has latched on to this term, often incorrectly.  One could argue (and many have) that the PMBOK represents a project management methodology because it describes a set of management tools that, if used correctly, can increase the chance of project success. 

I will grant the use of this term in this unconventional form may be acceptable, even if only borderline correct.  I'll still twitch when I hear it, though.  Here's why.

In the most literal definitions, a "methodology" is a study of methods.  It's an academic exercise.  Most project managers don't actively study project management methods, we practice them.  Sure, we'll read about various methods as a way to sharpen our skills, but we rarely perform actual research (which would require a scientific methodology in order to define how to conduct that research).  

Is "methodology" correct?  Is it pretentious?  Is it cringe-worthy?  Am I just being a jerk?  I don't know.  Leave your thoughts below.

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.