Principles Part 2 - Content Authority
Last post we looked at the first three of my agile principles -
They are built around small, self-organising teams
The team has a clear vision of what they are doing and where they fit into the bigger picture
The team delivers a regular flow of value via a well-defined backlog of work
This gives us an effective delivery engine (the team) with a clear destination in mind (the vision) and a clear route to get there (the backlog). All good? Not quite. If nothing was ever going to change, this would be all we need, but we know this isn't the case. When doing development work, and no matter what it is we are developing, we generally aren't travelling on well marked highways. Most development is, at best, navigating though a confusing maze of back streets and at worst, blazing our own trail through virgin country of varying degrees of ruggedness.
In any sort of development work, change is inevitable and we need to equip our team to deal with it. That's where the next principle comes in -
There is a content authority responsible for making sure decisions are made quickly
When change occurs, the team will sometimes need guidance on which new direction to take. Sometimes they can make the decision themselves, but often they are so bogged down in detail that they need someone with an eye on the bigger picture to advise them. That is the job of the content authority.
You can think of the content authority as the team's navigator. Because they aren't involved in actually driving the car, they can focus on the map, the terrain ahead and any changes in conditions, to adjust the route and make sure that the team gets to its destination. They can ring ahead and arrange for obstacles to be cleared from the team's path. They can make the decision to change destinations if a new, better destination become apparent. They can also make the call to stop the car and abort the trip, if the trip is going to take too long and the destination turns out not to be worth it.
If this sounds to you a lot like a product owner in Scrum or XP then you are absolutely right. Scrum and XP (and others) implement the content authority through a person called the product owner. So why not call it the product owner? Because the product owner is, by definition, a singe person. While this is ideal, when we start to scale things up beyond single teams, a single product owner becomes impractical. No one person can possibly be the single product owner in a large, complex system. There are too many people wanting their time and there is just too much information to fit into one head.
So in a small system, you may have your content authority embodied as a single person - a product owner - but in larger systems you may have your content authority embodied as a team of product owners, each with responsibility for a part of the system. The content authority could be a committee, it could be a panel of end users, it could be just about anything. What matters is that they speak with one voice. No matter what the internal structure of the content authority, and what internal divisions they may have, when they speak to the team, they all give the same message.
The content authority can be made up of multiple people, or even multiple teams of people, but there is only one authority. There needs to be very clear and well-defined areas of responsibility or other frameworks put in place to ensure that the content authority can do its job and not start giving mixed messages.
Care also needs to be taken when dealing with complex content authority structures to make sure that decisions are made quickly. There is no point giving a team directions after it has passed the intersection. A steering committee that meets monthly is not doing the job of a content authority. The decision making structures you have in your organisation now are probably not functioning as content authorities.
A content authority needs to be constructed to be as simple as possible. Use the minimum number of people needed to get the job done in the simplest possible structure that allows them to interact with each other in a well-defined way at the fastest possible cadence.
Let me reiterate - the mishmash of technical design councils, architecture committees and steering groups that you probably have now is not the same as a content authority.
So. Where are we now? We have a delivery engine, a destination, a route and a navigator. What else do we need? We have a lot of people in our car now. What we need to keep things running smoothly is clear agreement on who does what. We need a service agreement, and we will look at that next time.