AppTrends

Sign up for our newsletter.

I agree to this site's Privacy Policy.

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?

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:

What Delegated Authority
Architecture Agree
Software Design Advise
Test Driven Development Advise

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

What Delegated Authority Team Decision on How It Works
Architecture Agree A subteam of those interested in the decision would either reach consensus or decide how to make the decision.
Software Design Advise Try to decide within the pair.  If needed, others will be pulled in.  Any pair feeling a rewrite is necessary should first have a team turn around.
Test Driven Development Advise All code should be test driven, all exceptions should be agreed upon by consensus.  Always test code before committing. 
Pairing Rules Inquire A subteam of those interested in the decision would either reach consensus or decide how to make the decision.
Conflict resolution Consult Escalation goes from the team up to PM or DPM. If neither are available to make the decision by the last responsible moment, then the team escalates to the Executive Sponsor
Configuration Management Inquire A subteam of those interested in the decision would either reach consensus or decide how to make the decision.
War room physical configuration Inquire A subteam of those interested in the decision would either reach consensus or decide how to make the decision.
Technical Documentation (internal to team) Delegate A subteam of those interested in the decision would either reach consensus or decide how to make the decision.
User Acceptance Testing Advise A subteam of those interested in the decision would either reach consensus or decide how to make the decision.
Release Testing Advise A subteam of those interested in the decision would either reach consensus or decide how to make the decision.

Table 2. Product Definition

What Delegated Authority Team Decision on How It Works
MMF Definition (not process but actual decisions on content of an MMF) Consult The responsible group of QA, designer, and product management. Others will be pulled in when necessary.
Story Definition (not process but actual decisions on content of a story) Agree The responsible group of QA, designer, and product management. Others will be pulled in when necessary.  At least 1 developer will be involved.
Release Definition (not process but actual decisions on content of a release) Consult The responsible group of QA, designer, and product management. Others will be pulled in when necessary.
Branding  Sell Branding decisions come from outside the team. PM and other interested team members work with the Executive Sponsor, UX, sales teams and Legal to determine branding.
Product Documentation (any docs a user will see including API docs, installation, help) Consult PM will assemble advisory team to make the decision.

Table 3. Process

What Delegated Authority Team Decision on How It Works
Development Process (e.g. Kanban queues) Agree A subteam of those interested in the decision would either reach consensus or decide how to make the decision.
Decision Escalation/Conflict Resolution Agree A subteam of those interested in the decision would either reach consensus or decide how to make the decision.
Customer Engagement Sell Customer engagement is owned by the PM. He may delegate to individuals. This is to keep a single POC for the customer.
Demo Execution Agree A subteam of those interested in the decision would either reach consensus or decide how to make the decision.
Retrospectives (when/who/content) Agree A subteam of those interested in the decision would either reach consensus or decide how to make the decision.
Stand Ups Agree A subteam of those interested in the decision would either reach consensus or decide how to make the decision.
Process Tools Agree A subteam of those interested in the decision would either reach consensus or decide how to make the decision.
Team composition Sell PM works with Executive Sponsor to determine staffing profile. Team makes recommendations, identifies gaps.
Product Definition Process Agree A subteam of those interested in the decision would either reach consensus or decide how to make the decision.
Metrics Tell on required.
Inquire on others.
A subteam of those interested in the decision would either reach consensus or decide how to make the decision.
Process Documentation Advise A subteam of those interested in the decision would either reach consensus or decide how to make the decision.
Customer Support Consult A subteam of those interested in the decision would either reach consensus or decide how to make the decision.
Multi-Team Collaboration Consult A subteam of those interested in the decision would either reach consensus or decide how to make the decision.
On boarding  Agree A subteam of those interested in the decision would either reach consensus or decide how to make the decision.

About the Author

Dr. Mark Balbes serves as Vice President, Architecture at Asynchrony Solutions, and leads multiple Agile projects for Government and Fortune 500 companies. He received his Ph.D. in Nuclear Physics from Duke University in 1992, then continued his research in nuclear astrophysics at Ohio State University. Dr. Balbes has worked in the industrial sector since 1995 applying his scientific expertise to the disciplines of software development. He has led teams as small as a few software developers to as large as a multi-national Engineering department with development centers in the U.S., Canada, and India. Whether serving as product manager, chief scientist, or chief architect, he provides both technical and thought leadership around Agile development, Agile architecture, and Agile project management principles.

comments powered by Disqus