Why Your Project Team Sucks: Your Stand-Ups are Alive, with the Sound of Jargon

On a Discord server that I frequent, we began discussing our “your project team sucks part 3: everything is an emergency top priority.”  It warmed my heart to hear how many PMs and Devs were pushing back against the “this is a top priority” shit.  I was dismayed, however, to hear that the business folk have evolved.  I was further disappointed to hear how many PMs whole heartedly embraced this evolution.

Critical Priority by Any Other Name Still Smells of Shit

The evolution that I speak of is discussing priority, without saying the priority.  It’s things that any work that accomplishes these things, are considered highest priority, and things that encompass these things are always the highest priority… and so on.  It’s created a loophole whereas they can just say it fits one of these types of work, and automatically it’s a fucking critical problem.

Not catching on?  Let me give you an example.

KTLO work (keep the lights on) is always considered critical priority.  Knowing this, requests that come in are deemed to fall within the definition of KTLO, even when it’s a net new ask.

Anything that would be net new wouldn’t be something needed to keep the lights on, right?  Well, it’s all in how the business spins it, but that doesn’t really matter, because they have another work around.

Stemming.

This is the first I’ve ever heard of this, and while there were only two PMs who actively use this on their project team, it’s still two more than should exist.

Stemming is a reference of the idiom “stem the tide,” where something is done to stop or avoid a troubling trend.  Therefore, stemming work, is anything that is needed to break this trend that the company finds troubling.  It’s therefore considered… critical priority.

Other jargon shared that triggered the critical priority treatment included: B.U.G. (business unit goals), strategic alignment work, P.F.R. (process foundation requests), and (my favorite) fly paper (work that would prevent a descent into savagery, ala Lord of the Flies).

But, Jer… I don’t understand, isn’t this just calling everything critical priority with extra steps?

Fucking-A-right it is.

Here’s the thing, there is a difference.  It’s subtle, it’s damn near imperceivable, it’s fucking diabolical.

What’s the difference?  It’s a shift.  A shift in who is responsible for determining priority.  Priority goes from client side to project side, and project teams are eating this fucking shit up.

It became clear based on the initial conversations with the PMs who were implementing this, was that they were blinded to devious machinations behind this process.

“It gives us more freedom to do what needs to be done, we have broad priorities, and we just assess that based on the need of the request.  It’s totally legit, I swear.”

There was a lot of arguing, name calling, and strawmanning, but where we ended up was this:

• The definitions for each of these types of work was poorly defined and meant that latterly everything would fit into one of these categories.

• Any work that doesn’t have categorization can be considered to be lower priority.

• All work coming in has a category.

• All categories are considered to be critical priority.

• This is somehow better than when the business just called everything a high/critical priority.

Quantifying Work Using Spidey Sense and Vibes

I probably wouldn’t have paid it too much thought, had it not been for stemming.

Stemming is the most ridiculous thing I’ve heard come out of a boardroom in a very long time. 

This troubling trend, is it actually a trend?  Is it just a blip?  An Anomaly?  Potentially caused by something outside the company’s sphere of influence?  Doesn’t matter, it just feels troubling.   

You see, the trend has tattoos, and wears Iron Maiden t-shirts, and drives a motorcycle, and plays D&D, or is sacrifices baby chipmunks in its spare time, or some other corporate satanic panic based BS.

Why is it BS, what’s my problem really?

If it was honestly a troubling trend, they would be able to adequately prioritize it.  They could look at where the issue is trending towards, make an assessment, determine what is the most important aspect of the work, KPIs, etc.  The business would then return with work that had been prioritized in a meaningful way.  But, no…

Instead, they just call it stemming, and send it off with what translates as critical priority.

Some of you are seeing a bigger issue here with prioritization.

It’s all based off of vibes.  Is something actually a critical priority?  Well, to the guy whose bonus is riding on getting this change implemented, yeah, it is a critical priority.  Is it actually going to cause the slow steady failure of the company if it doesn’t get implemented right away?  Probably not, you can calm your tits, we’ll get around to it eventually.

Even Though the Process is Evil, It Does Come with a Free Frogurt

Prioritization by categorization probably isn’t going anywhere.  In fact, it’s something that I would probably advocate for, with a couple of caveats.

First of all, if the business doesn’t want to prioritize the work, then they aren’t’ allowed to categorize the work.  Second, the rules that govern what category a request falls in needs to be defined in as much detail as possible and understood that categorization doesn’t automatically default the request to critical priority.  Lastly, every single request would need to be categorized.

From the top: if the business isn’t categorizing the work, then who is?  Well, the analyst who captured the requirements, of course.  During the requirements gathering, the analyst would ask the questions that would allow them to determine chat category the request best falls in.  This is where the second part is so important.  You need to have each category defined to the point that there is little ambiguity between categories.  The more defined it is, the easier the analyst will have categorizing it. 

While we are eliminating ambiguity from the category definitions, we also need to have an understanding of what their priority is.  Beyond just low, mid, high, critical, project teams will need an understanding of what category takes priority over the others.  If you have 20 categories, you need 20 priority steps.

This is where I lost many on the Discord channel.  You see, the argument was that in order for this to work, then the business would need to be deliberately kept in the dark on how the prioritization process worked, and that would need to be enforced with an iron fist. 

Which is true, sort of.

It’s true, in that, you would need to keep the business side’s feelings and vibes out of the categorization process, and you would need them to be ignorant enough that they wouldn’t manufacture requirements to always land their requests as a top priority.  Big picture, however, the business needs to be knowledgeable of the request process that is established, that they won’t be surprised when their pet project that they have super good feelings about gets bumped for the thing that is actually losing the company money.

Which brings me to the final point.  Everything would need to be categorized, regardless of how minor the request is. 

This achieves several things; it prevents the inadvertent gaming of the system.  Everything gets prioritized, and therefore everything is placed under the same scrutiny when requirements are gathered.  Second, it provides a way to prioritize backlogs in a meaningful way, because let’s be absolutely fucking honest, items pulled into sprint are never as clean as one would like.  Shit is going to wrap early; shit will go long.  Prioritizing these lesser requests in a meaningful way allows work to be pulled into sprint in a way that works for the project team.

Would Prioritization by Categorization Actually Work

Maybe?  I don’t really know.

I can understand why so many project teams would glom onto this new-fangled way of prioritizing.  It removes one of the biggest frustrations surrounding prioritizing; getting the business to provide meaningful feedback on what is most important.   Now they don’t have to, they just provide a category.  The failing is in how the category translates to priority, in that, everyone who has adopted it has admitted that every category is considered a critical priority.

Even with proper category to priority definitions, it becomes likely that business types will evolve to know to make all requests fall within specific categories to ensure they are treated with the highest priority. 

There are work arounds, and ways to work through the limitations that might exist, and there are some problems that would just need to be accepted.  But we can all agree that this new strategy is a novel way of fixing an issue that leaves many a project team enraged.

And so, the only thing we can do is wait and see if acknowledging the risks and potential pitfalls will provide a seamless move to this new prioritization strategy.