Passing the buck the right way

A key principle at the intersection of agile and DevOps is to push responsibility down the org chart, as close to the work as possible. Now given my strong views about the heavy obligations that leaders have towards their subordinates, it would seem incogruous to say that they should shift responsibility down onto their subordinates. After all, traditionally the act of deliberately shifting responsibility is known as "passing the buck" and is frowned upon. But the truth is that buck-passing is great for everybody, and should be done in all directions, provided that it is done honestly and constructively.

Handballing risk downwards, with appropriate allowances for your subordinates to send it right back up at you, is key to efficiently flushing out and resolving unforeseeable problems.

In a traditional work environment, when the worker hits an exceptional situation -- say a specification which is discovered to be a bit vague once the time comes to actually implement it -- then the only avenue open to them is to escalate to their manager. This is exactly how computer programs work, by the way: `throw new UnderspecifiedException()` in the leaf node and then propogate that all the way back up until someone knows how to `catch` it.

The person who can catch that exception might be the immediate supervisor, that might be some kind of project manager, that might be the CEO. Then they get involved and use their birds-eye view of the world to reach out to people at their own level and below, to unblock the work and get things moving again. This might involve a point solution or it might involve re-planning the whole project. Either way the decision comes back down the tree and the worker continues working according to the (possibly-revised) plan.

Is that efficient? Well, arguably it minimises contention because someone In Authority is handing down a solution. But it maximises contention in another sense of the word: the poor manager or executive is constantly context-switching between fire-fighting scenes, zooming in and out of their subordinates' projects to try to solve everybody's problems. And real work is rarely as simple as someone In Authority handing down their fiat; there are misunderstandings and politics and competing demands and it's messy.

You may or may not find this written down in any of the formal agile frameworks, but in a well-oiled agile environment you tend to find a different system at play. Instead of work being broken up into a sequence of tasks to be executed, with exceptions thrown back up the tree, work is broken up into sub-components which each deliver some business value.

These might look suspiciously like a sequence of tasks, but the difference is this: when the worker hits an exceptional situation, they can themselves reach out to the people responsible for the relevant sub-components that need to interact with their sub-component. They don't need to escalate to a manager who can talk at level or downwards to the manager of the person working on the other sub-component. They can talk directly. Often they can solve the problem through this direct, horizontal negotiation at a relatively low level on the org chart. If they can't, escalation remains an option. But it's a fallback option, not the only option.

Enjoying the benefits of fast resolution of unforeseen problems -- which are many -- requires certain conditions to be put in place. These include:

• A logical division and sub-division of work in terms of value, not merely in terms of tasks to be completed.
• Access to information about others' work, such as the information provided by backlogs, daily standups and "working out loud" type chatrooms.
• An iteration- or "sprint"-based model where a worker's responsibility can be timeboxed.

The timeboxing of responsibility is an important point that is rarely discussed. If you take a relatively junior person and put them in charge of a particular part of the project for the entire length of that project, that's a huge deal. They have to manage the resourcing and execution of that part of the project all the way through all the ups and downs. But if you hand it to them for a single two-week iteration, with a clearly-defined scope and "definition of done", that's more likely to be manageable. You are giving a person a degree of autonomy that they couldn't enjoy in a traditional environment without first becoming more senior. You are enabling them to grow in ways that are simply impossible in a traditional environment. And you do it without increasing risk.

So we have talked about how an agile work environment makes it easier and less risky to shift responsibility down the org chart, provided that the investment is made up-front to create that agile environment, but in my introduction I also mentioned DevOps.

The link with DevOps is this: a worker's responsibility can only extend as far as their tools allow.

If they need to hand off to another team to have something implemented or tested or whathaveyou, then they are no longer able to take responsibility for the quality or timeliness of that something. Building or buying the tools to extend an individual worker's reach requires an up-front investment. Where tooling or automation to eliminate hand-offs is not feasible, DevOps emphasises the active management of those hand-offs, bringing forward discussions to "shift left" on problems like integration, security and testing. Again, this requires an up-front investment and a degree of openness across the organisation, but the payoff is significant.

With a combination of the all of the above practices, we enjoy a welcome change in how we deal with the problems that are inevitable, yet unforeseeable, in every line of work. Traditionally we would fan work out as a set of tasks assigned to teams or workers, with the expectation that exceptions would come right back up at us to resolve. Whereas in an agile, DevOpsy work environment, we do almost the same thing except we always ensure every task we assign will deliver some business value and that the person we assign it to can probably take responsibility for delivering that value.

You don't have to worry about how exactly they deliver that value, because they have autonomy, but it will probably have something to do with the tooling and culture of openness you put in place earlier (you did do that, right?). And that's what will make your subordinates happy that you passed the buck to them.

Image credits (in the order in which they appear):

• Photo by Artem Kniaz on Unsplash
• Created by Wolfgang Beyer with the program Ultra Fractal 3 and uploaded to Wikipedia.
• Photo by didin emelu on Unsplash