You don't have a PRIORITY problem, rather a CLARITY one
"I totally understand and agree this is needed, but how does that stack up in priority against [the big strategic business priority going on] for the upcoming quarterly planning"?
Those weren't exactly the words I recently heard in a meeting, but that was the meaning. And most people will find it a very valid and honest question. It would be, if the context was one of comparing two business priority demands, a clear-cut case of conflicting priorities. But it wasn't the case; the new request was related to setting expectations around engineering excellence stuff, so more on the process improvement side of things.
That's when we enter the realm of the rather intangible. And more importantly, it's not even a fair question towards stakeholders because we are not comparing "apples to apples" at all.
I found myself reflecting on all of that, and eventually it hit me! It is a question with an impossible answer as long as we frame it as a priority matter in the typical sense of what stacks up over what. This isn't a matter of priority in that sense, yet it is somewhat related to priority in a broader sense (which in context might mean selection, sequence, schedule, or class of service).
But perhaps it is better not to take a priority frame in the end, and look at it from a slightly different angle. I actually wrote about it before in the post: Is it a priority issue? Or more like lack of transparency?. Although here I would like to suggest going yet deeper on it and calling it a matter of CLARITY.
Allow me to walk you through what I mean…
It is a matter of CLARITY because of the risk, as John Cutler points out in his tweet below.
And I honestly don't believe teams out there aren't aware of it. That's not typically where the problem is; rather, how can they ensure not to be pushed around to keep adding and doing more and more new requests? How to go about it without risking becoming a largely emotional discussion.
That brings me to my main observation…
It's a matter of CLARITY because clarity means transparency and understanding. So it is not enough to be transparent that you need to take care of more stuff than just accepting new demands and adding new capabilities. It has to be accompanied by an understanding of the underlying "rules of the game", so to speak.
Thus, the real question, the problem we should try to solve, is how to build that understanding, how to make the "rules of the game" clearer. My personal suggested approach for that would be built upon a few enabling concepts:
Make rules (or policies, if you prefer) explicit.
Limit WIP (at all relevant levels), already defining as well as at level of the different nature of work you need to take care of (e.g., new demands, improve existing functionalities, process improvements)— that is, by the way, the first rule to be made explicit.
Agree within the team on useful patterns to dynamically deal with the practical allocation of people (e.g., anyone can take up some process improvement item at any moment of time, but only as long as additional help is not needed to make progress on the more urgent things like new demands).
All of that together, more or less, means to use CLASS OF SERVICE as a basic overarching concept. And here is how that could look in a more visual manner:
And I know, I know… That will somewhat sound idealistic to some, and it is definitely much easier said than done (and yes, I am done with the clichés for now). But it is far from impossible; there are people out there using such patterns, and it is absolutely worthwhile. And the results in the long run should be even more appreciated by stakeholders, although at first they might have an issue with the additional constraints on their demands.
Definitely worth the try…
By Rodrigo Sperb, feel free to connect (I only refuse invites from people clearly with an agenda to ‘coldly’ sell something to me), happy to engage and interact