Many organizations work differently than others and have different strengths and weaknesses.
No matter where I go, however, one thing is always clear. Priority is always unclear.
What does it mean when something is deemed critical?
You will often hear leaders tell you to switch gears to a different project, because it is higher priority or “critical.”
This is such a loaded comment. Why? You know why. Because EVERYTHING is a priority or critical.
Using a backlog for prioritization
Leaders are notoriously bad at prioritizing work.
The best way to get around this is to establish three things: an ordered backlog of deliverables, a cadenced prioritization cycle, and a well-established P1.
Well-ordered backlog
Having an ordered backlog, with a list of all deliverables sorted by ordered, forces the leader or product owner to determine what is actually the highest priority.
I was recently told that I had to get a developer to work on something, because it was “critical.” However, since we had an ordered backlog, I was able to quickly point to the three other projects that were also “critical” but higher priority that this developer was working through.
Cadenced prioritization
So what is stopping a leader from just changing the order of these priorities on the fly, to suit their agenda?
Nothing. . . unless you establish a cadence with which a leader can re-order the priority of work.
In SAFe, this manifests as a quarterly event called the “Program Increment Planning” activity. Whatever you call it or choose from your cadence, it should hurt the leaders at least a little to make the decisions in these meetings. That is good. It means true prioritization is at work.
Establishing a P1
Emergencies happen and can derail other projects, but establishing rules for the dreaded “critical” or “P1” task is vital to effective prioritization. If you don’t, a leader can just say something is suddenly an emergency and end it there.
You want these rules to be as binary as possibly but also binary to all involved.
“A chief officer said this was a P1/critical deliverable,” is not good, because it is not binary to the chief officer. They have to make a decision outside of the rule.
“There is an issue that is suddenly preventing customers from getting their normal work done,” is an example of something more clear, but it is still not binary.
“The customer cannot access the system,” is more binary. They either can or can’t access the system.
If it is not binary, it is not clear.
As noted above, the best way to make things clear is to make them binary.
Pass/Fail.
By changing the criteria of a problem to pass/fail, it allows you to bring clarity to a confusing request.
Let’s use a real, recent example, where we have to decide when to roll back code during a release:
“When do we roll back the code?”
“If it is critical and can’t get resolved in the next few hours.”
“Can we set a specific time?”
“Sure. If we can’t fix it by 11pm.”
“Okay great. Can you help me understand what ‘critical’ means?”
“When it is really bad and impacts the user in some way. We will just know.”
“How do we know if it impacts the users in some way?”
“We could have someone from the business take a look at it and validate they can use it properly.”
“Can we define really bad? How will they just know?”
“We have some tests we run for general uptime of the site and do some smoke tests to make sure the platform is usable. If it is not usable, that is when it is bad.”
“How do we know it is not usable?”
“If we experience timeouts or if one of the existing regression tests fails.”
From the above list, here are our binary determinations
We will roll back if
We detect a bug.
OR
The system fails at least one test for general site uptime.
OR
The system fails in one of the existing regression tests.
OR
The attending business owner reviews the system and says they cannot use it properly.
AND
We can’t fix or address the bug by 11pm.
Bring some light to the darkness
When things are not clear, ask questions and establish rules that leave no doubt about the right course of action.