The Agile Architect

Delegated Authority: An Agile Trust Experiment

Our Agile Architect experiments with Delegated Authority. How far do you trust your team to make decisions?

• By Mark J. Balbes, Ph.D.
• January 22, 2014

It was the middle of the night and I woke up in a cold sweat. What had I gotten myself into? My team was in chaos. I had too many chiefs and not enough Indians, each with their own ideas about how the team should be structured and the work organized. They didn't like my ideas about a self-organizing team that changes structure to meet emerging needs. They wanted structure! A leader in charge! Subteams with subleaders! A prescribed chain of command where decisions are made by the person in charge. Jawohl!

Well, it wasn't quite that bad. But it sure felt that way to me after emotionally draining discussions with little progress toward a common vision as to how things would work on the team.

Delegating Authority
Enter "Management 3.0, Leading Agile Developers, Developing Agile Leaders," a book by Jurgen Appelo. While I personally didn't enjoy the author's writing style or pseudo-scientific approach, once I got past that, I found there are some excellent ideas in this book, and it is worth reading.

One of the chapters dealt with the notion of delegated authority. In other words, if you are the leader of an agile team, how do you delegate your authority or a portion thereof to the team?

The author discusses seven levels of authority. In his words, these are:

• Level 1: Tell: You make decisions and announce them to your people. (This is actually not empowerment at all.)
• Level 2: Sell: You make decisions, but you attempt to gain commitment from workers by "selling" your idea to them.
• Level 3: Consult: You invite and weigh input from workers before coming to a decision. But you make it clear that it's you who is making the decisions.
• Level 4: Agree: You invite workers to join in a discussion and to reach consensus as a group. Your voice is equal to the others.
• Level 5: Advise: You attempt to influence workers by telling them what your opinion is, but ultimately you leave it up to them to decide.
• Level 6: Inquire: You let the team decide first, with the suggestion that it would be nice, though not strictly necessary, if they can convince you afterward.
• Level 7: Delegate: You leave it entirely up to the team to deal with the matter while you go out and have a good time (or use that time to manage the system).

So I decided to perform an experiment. Rather than trying to sort out the question of team self-organization with a top-down approach (which sound ridiculous even as I type it), I thought I would follow the structure above, delegating authority to the team in specific areas and then letting them decide on how to organize within that delegated authority.

I started by defining the things that are important to me as the product manager (shown below) . Any decisions the team made within their delegated authority would have to support or at least not detract from these.

Product Manager's Primary Responsibilities and Goals:

Vision: To have a highly configurable, extensible, sustainable product backed by a quality centric organization that is highly responsive to the needs of our users.

Mission: To build the product by creating a team of highly capable individuals with the right mix of skill sets who work together through agile processes to create a high quality product and excellent customer experience.

Product

• Create and maintain the vision for the product
• Create a sustainable product
• Create features that provide value to our users
• Create an extensible, flexible architecture

Process

• Follow agile best practices
• Innovate on agile best practices
• Create processes that are self-sustaining and don't depend on specific individuals or heroes
• Create processes to sustain multiple product teams working in parallel

Team

• Create a sustainable team
• Encourage personal growth

From here, I created three tables of delegated authority, one each for Technical, Product Definition and Process. Under each, I put the areas where I was delegating authority to the team and at what level. For example, some table entries are:

This was where my true trust in the team would be measured. If I delegated each area at a level of Consult or above, it would mean that I didn't trust the team to make decisions.

So I took a deep breath and started to delegate. I tried to remember my own behavior in meetings. When did I say things like, "I'm not telling you the answer. This is just my opinion." Or, "For this discussion, I'm just another developer." Or, "You guys decide. I don't care." I tried to use these to frame my true interest in how much I controlled the form of the solution. There were some very specific areas where I did maintain strict control because of my involvement in activities for the project outside of the development effort, thus giving me special knowledge and perspective.

You can see the full results at the end of this column.

Once I did my part, it was time for the team to do their part. While I had done the hard job of figuring out the areas where I would delegate authority and at what level, they had the even harder task of figuring out how to organize within that delegated authority.

And this was perhaps the scariest part of the experiment for me because I didn't know what the team would do. They could choose to appoint a single leader who would make all decisions for them. They could choose to have a pure democracy where all voices are equal regardless of experience. They could choose to put rigid rules in place that would limit their options when applied to real situations. And I knew that there were individuals on the team that would advocate for each of these options.

So we met for a marathon two-hour meeting to walk through the document, what we now call the Team Contract. How did the team do? You can see for yourself in those charts.

Personally, I am very happy with the result. For the most part, the members chose a dynamic agile approach that allowed the team to make decisions in the moment using the best information and team members available.

But there was still one important issue to discuss: Conflict Resolution. We decided this could happen in multiple ways:

Conflict: The team cannot come to consensus on a decision.
Resolution: We defined an escalation process that ultimately brings the decision back to me, with further escalation if I am unavailable.

Conflict: The team solution does not meet my listed goals.
Resolution: I can reject their solution if the team cannot show how it meets these goals.

Conflict: The team is exceeding its delegated authority.
Resolution: Discuss immediately or in the team retrospective without fear of retribution. Revisit authority levels.

Conflict: I violate the authority I delegated to the team.
Resolution: Discuss immediately or in the team retrospective without fear of retribution. Revisit authority levels.

Final Thoughts...
I had originally thought to title this article "An Agile Experiment in Terror." It took a lot of trust on my part to follow through with this experiment, but it was well worth it.

For my part, just the act of thinking about what is important to me allows me to let go of some areas of responsibility that I might otherwise have gripped tightly. As issues come up, I am constantly thinking about this contract and my role in the decision-making process.

For the team, they recognized that this is a living document. They're already thinking about ways to improve or change it. Before this experiment, we had individuals named as technical leads for our different technologies. Since technical leads were not addressed in this document, this was lost. Now the team is considering naming individuals as technical leads again.

The real test of this experiment will be whether we are still referring to this contract a year from now, or if like so many team charters, it simply gathers dust in the depths of our wiki.

And finally, here are the three tables in full:

Table 1. Technical

Table 2. Product Definition

Table 3. Process