"I'd rather not do this...."
I recently came across Ellen Grove's presentation on "The Life Changing Joy of Saying NO". It's a good exploration of many of the circumstances that often lead us to committing to do more than we can (or want) to do, and the barriers that makes us unable to "simply say NO", even to ourselves.
When discussing potential strategies to say NO, Ellen mentioned the "Priority NO", that is, saying NO by way of prioritizing new requests against other existing work; as she points out, this is a rather well known strategy (moreover, it's arguably an agile backlog management built-in mechanism), yet is not as widely used as we'd like to see.
The topic also came up in a recent conversation I had about teams feeling overloaded, with way too much work on their plates, leading to the need to work long hours, even weekends, and seriously risking burnout. They just felt that they had no ability to say "NO" to a constant influx of work, and attempting to have the prioritization conversation didn't seem to help.
A matter of Trust
Asking someone to make a priority decision implies deciding to delay some work to favour some other work. The options might be to stop or lower the pace or progress for ongoing work, to postpone the decision to start something new, or a combination of all that.
In either case, we're asking the requestor to trust that we'll come back to work that is put on-hold, and that the reasons we can't accommodate both is legitimate and better than the alternative. We're asking also for empathy about our needs for a sustainable pace.
Interestingly, those are all things that have little to do with the prioritization conversation, and much more with the requestor's past experience with the performance of the service we're providing.
Unwillingness on the part of a customer/stakeholder to engage in a prioritization conversation leading later to irrefutable demand can have many different origins, but in the absence of any other theory I'd start by evaluating how much "social capital" (or trust) we have in reserve with this person, because we'll be spending some of it as part of this negotiation.
Identifying the Seeds to Plant
Building and maintaining trust is a large and complicated subject, but if we circunscribe the analysis to just managing delivery, we can think about those things that we do from a delivery perspective that, if sustained over sufficient time, will erode trust and prevent us from building the kind of "social capital" that will later be needed when we're attempting to engage in "priority negotiations".
So, what are those things we could focus on to help build trust?
One of them is quality (both internal and external). Delivering work with lots of small (and not so small) mistakes will cause frustration in our customers, create impatience, and eventually destroy confidence in our delivery capability.
Low quality will inevitably make us slower; it also has the effect of generating lots of "failure demand" (in the form of not just escaped defects, but also manual interventions and workarounds, rework, etc.). This additional influx of work tends to be very disruptive and often irrefutable, leading to an increase of work in progress and context switching. The result of all this is unpredictability, which also erodes trust.
A related aspect is frequency of delivery: the more often our customers get value from us, the more confidence they will gain on our ability to fulfill our promises. We also have the chance to get feedback, learn how well we understood what was needed from us, and make adjustments.
All this helps to build trust.
Moving to Action
Given all that, what concrete actions could you take? Here are some ideas:
Start by assessing your current level of quality (defect rates and types, static code analysis metrics, etc.) and understanding the volume, composition, and arrival patterns of your failure demand.
Decide which practices could be adopted that will help you tackle your most pressing quality issues and eliminate the most disruptive forms of failure demand. The Agile toolbox has lots of these (TDD, Continuous Integration, Pairing, 3-Amigos desk-checks, Spec by Example, etc.)
You will have do something about keeping work in progress under control. Practices like Visualization, Personal WIP Limits, and decision filters like "Prefer Finishing to Starting" can be a good starting point, complemented with explicit policies to handle high urgency work and expedited requests.
Gain insights about your most common sources of delay, so that you can introduce improvements to the general predictability of your process.
Start working on decreasing your "batch size" (the number of "things" that are bundled together to make a delivery to the customer), so that you can eventually increase your delivery frequency. A key first step for this is to make sure you represent the work in customer recognizable terms, as a stepping stone to educating your customers on how to make (and accept) smaller requests.
Afterword: The Recipe for Success
For those of you familiar with Kanban, you might have recognized in the discussion above the "recipe for success" that has been part of the method for the longest time:
The initial "ingredients" in this recipe serve the purpose of achieving relief from overburdening, which creates the space to focus on flow. This combines with frequent deliveries to help increase overall trust, and later opens the door (amongst other things) to an increased ability to balance demand and capability; part of that is the ability to "say NO" by way of prioritization.
Comments