Petition the King

When you’re in a group that serves many customers, your backlog list tends to become infinitely long. You’re not sure whether to report on things that aren’t being done, or to pretend they are being done, or what. Don’t keep a backlog list at all. The result could be greater clarity for your customers, and far less hassle for you.

Contents:

The Metaphor

Imagine some kingdom somewhere, with a benevolent king (you), who has finite resources that he wants to use to help the people. There are many things the king (you) might do, but only so much time and money. What does the king do?

Every month (or every two weeks, for an Extreme King), the villagers are invited to come Petition the King to have their requests granted. Each villager may plead his case, and the king makes his best judgment as to which requests are best to fulfill. The wise king considers the importance of the request, the importance of the petitioner to the kingdom, the taxes paid by the petitioner, the length of time since the last petition granted to this petitioner, and so on.

Based on his best judgment, estimates of the cost of granting each petition, and on the resources available, the king chooses which petitions to grant. All the villagers are told which requests will be granted, and why. The chosen petitioners are invited to come to subsequent audiences to discuss the details.

All the other petitioners are told that their petition was not accepted this time, and that they are welcome to come back to any subsequent Petition the King meeting.

At this point, some villagers will ask whether the king would please just remember their request, and grant it at some later date. The king replies that he would like to do that, but the volume of requests is too high to do that, and that when next he considers the request, he will need to be sure that the petitioner still wants it. So it’s best to come back to a subsequent meeting.

Other villagers will ask whether the king could just work on their petition “a little bit”. The king replies that that would just make the things chosen take longer, and would waste the kingdom’s resources in the short and long term. So it’s best to come back to a subsequent meeting.

There is a bit of grumbling at first, but soon the villagers realize that the system works well: the most valuable petitions are granted, and everyone is treated equally, fairly, and publicly.

The Metaphor Illuminated

The Kingdom
I envision the situation of a development team who takes input from a large number of customers. Perhaps an internal analysis group or a group doing modifications to a wide range of existing applications.
The Villagers
The villagers are the customers, the people who want features put into the software. Invariably there are many more of these than we can help in any given period.
The King
The king is almost certainly not the development group, at least in the XP context. In XP, business decisions are not made by development. So from an XP viewpoint, the king is some kind of Big Customer. Kevin Lawrence suggests that the king is the Customer Who Speaks With One Voice. Brad Appleton mentions the idea of a Customer Advisory Board, and suggests that the XP equivalent might be “One Customer Team”. In a product company, the role of king might be taken by a product marketing committee, or the head of product marketing. In any case, it’s best if the king is a business-oriented decision maker.
The Petitions
These are requests for applications, product features, whatever the developers develop.
Resolution of the Petitions
The essence of the idea is that petitions are either granted or refused. The king doesn’t maintain a list of things that might be done at some future time: it is the responsibility of the petitioner to come back to a future meeting and support his request again.

The Metaphor in Practice

What would happen if a team with many customers followed this kind of procedure? Clearly there would be some benefits:

  • Everyone would know exactly what is being worked on, and what is not;
  • Reporting from the development department could be simple, clear, and complete;
  • Project- and task-switching overhead would be reduced;
  • Projects would receive enough attention to make good progress;
  • The things worked on would always be things that someone really wanted, at least enough to argue for it.

Of course there would be drawbacks:

  • Some people think it is your job to keep track of their priorities;
  • It might be a bit more difficult to see the size of the full backlog of requests.

And perhaps there are other drawbacks that I haven’t thought of. If so, I trust that someone will bring them to my attention.

It’s just a wild idea, but it seems to me that it could really improve the effectiveness of communication, and the effectiveness of planning and execution, in a group that serves many masters. I think that if I ran such a group, I might try it, and see how it had to be modified to make it work. My key objective would be to have the organization on the hook only for things actually being worked on. Let’s talk about some issues.

Issues and Modifications

As with any other XP idea, the point is to get us near enough to a good way of working to enable us to see it and adjust it from there. In talking with people about the metaphor, they came up with issues and questions:

Back Door

Some villagers will know someone in the court, or someone else highly placed. They may prevail on them to plead the case, and they are likely to do so outside the designated time and place. The king must remain aware that he needs to keep these constituents satisfied. If sometimes he needs to add in some work this way, he allows for it in the amount of resource he schedules during the petition meeting. Then he just schedules the work, and reports it in his status report at the end of the period.

Demigods and Gods

Sometimes gods and demigods meet with the king privately and command him to change his priorities. Ultimately he must accede to their demands, but by behaving reasonably he can still come out in good shape. First, he might hold back some resources for these events as well. Second, since he knows what resources are scheduled, he can ask the gods to help him decide what /not/ to do, and he can ask them to help him explain to the displaced petitioners what has happened to them. Sometimes this will even stop the change from happening.

Most important, though, if the petition meeting is held on a regular basis, people will show up at the duly appointed time with their ducks in a row. Lots of interruptions in mid-period suggest that the period is too long.

Changing Priorities

I’ll address this separately, I think, in a subsequent article. The quick answer, however, is shorter delivery cycles. If the king’s projects are small enough, a change in priority means that a new project won’t ever be asked for, not that an existing project languishes half done.

Long Projects

Projects longer than the planning cycle would have to be addressed. And the planning cycle needs to be scaled near the median or short end of the project length scale. What should be done about long projects?

Here again, this will be addressed in the subsequent article I mentioned, and here again, the quick answer is not to do long projects. Break the long projects down into shorter projects that deliver value, in standard XP style. This might be sufficient.

Keeping the Backlog

In a sense, the essence of this idea is that the king does not keep the backlog: the person with the priority is responsible for knowing what he wants and arguing for it. So in the case of the Customer Advisory Board or head of product marketing, it would be the individual requestors who would have this responsibility. If these are the heads of departments in the company, or people in charge of the various products, this is their job anyway. In a company where the customers are outside, there almost certainly does need to be a backlog list kept by the board, to use in deciding what to do next.

In either case, what’s important is this: no one can be misled to believe that something is being worked on when it is not, because only what is really committed to being worked on is reported on by development. The backlog, if we report it at all, is what Dale Emery calls a “NO” list.

Who’s the King?

It’s important to be clear that development isn’t “king”. To a development group, their current customer is king. So the metaphor is intended to give us ideas, but perhaps not to be told to people who may be confused by its terminology. If you know an equally vivid picture as that of the people petitioning their king, use it. And pass it on to the rest of us.

Is This Madness?

I’m not sure it is. I’ve worked in this kind of organization for many years, and have tried many ways of managing the request flow and the information flow. I have never tried anything quite like this, however. Still, nothing that I have tried has worked well enough to satisfy me, so I think I’d try this and see what happened. If you get to try it before I do, please pass on your experiences. I’ll be glad to talk with you via email while it’s going on, if a little coaching or chat would help.

Posted on:

Written by: Ron Jeffries

Categorization: Articles, Classics

Recent Articles

Emergent Design

Martin Alaimo asked about the Manifesto Principle "The best architectures, requirements, and designs emerge from self-organizing teams."

Codea Calculator II

Ignatz and Jmv38 on the Codea forums commented on the previous article. I had hoped to do more anyway so here's the next one.