Agile Line Management

This is going to be another opinionated piece on the ideal line management reporting structure for an Agile team. I’m not going to get into organisational hierarchy or connections between teams, instead just focusing on the Agile team itself. This does, however, relate to the concept of dependencies.

Groundwork

First I’m going to establish some foundations.

The team is made up of:

1. 1 x customer proxy
2. 1 x process coach
3. 3 x engineers
4. 1 x QA engineer
5. 1 x ops engineer

Now some terminology:

So in a group, we can have one person who is accountable and many people who are responsible. In pretty much any Agile framework or way of thinking, there is some kind of customer proxy, often called the Product Owner, whose job is to maximise customer value. This person is held to be accountable. So far, so standard. From now on I’m going to call the customer proxy the Product Owner and the process coach a Scrum Master. Personally I don’t really care what titles are used and this makes it clearer what I’m talking about.

The Task

IT is complex, so let’s simplify the requirement. I’m going to ask the team to collectively build a Lego set. The PO will choose the set that our customer will most enjoy, the SM will help the team be the best the can be, and the engineers will build and send it to the customer.

To be accountable for something you need to have everything you require to do that job. If I ask you to accept accountability for ensuring my fence gets painted, but then give control of the paint and brushes to different people, you can’t actually be accountable. Technically the only person who can be accountable is the nearest common reporting node for all 3 individuals. Bear this in mind.

Agile Line Management Options

Scrum Master

I’ve seen this done many times. I’ve actually been in this position before. It’s not a terrible choice but it doesn’t really align correctly. The team’s mission is to deliver maximum customer value, the SM is there to help the team do that. But the SM isn’t accountable for the work that the team does. The team are accountable for their own work and the PO is accountable for the outcome of the work. So we’ve got a conflict of interest between process excellence and customer value.

By having the Product Owner reporting into the Scrum Master, we’re saying that the primary alignment for our team is process, not customer value.

Lego will be delivered, probably on time too as everyone needed is available and linked together with a common node within the team.

Not terrible, but presents problems: 5/10

Engineer

Engineers are accountable for building and delivering high-quality software to customers. There is a link here but the engineer is now conflicted between technical excellence and customer value. The healthy tension exists solely within an individual.

Aligning this way proclaims that alignment to technical excellence is more important than customer value.

We’ll no doubt get some Lego, but it’s going to be the best damn Lego set you ever saw and it’ll take 1 year to deliver.

Worse than Scrum Master as it presents a greater conflict of interest: 4/10

Team Leader / Manager

The problem here is that we’re manufacturing a role due to the lack of trust and autonomy we have in our teams and then try to make that person accountable for the team’s outcome of delivering customer value? Not only that, but we’ve introduced an additional connecting node that will likely disconnect the team from the rest of the organisation. Agile should be as flat possible to improve adaptability. This harms that.

As this role is also primarily there to ‘control’ the team and their work, it’s unlikely that they’ll be able to build significant domain experience and may find themselves in constant painful conflict with the PO. I also have no idea what the primary alignment is saying in this instance.

Adding another person to help our experts ‘coordinate’ the Lego doesn’t feel like the right call here.

Save your money: 3/10

Functional Lead

At least with a team leader, we had everyone reporting into someone common and local. When we push line management to diverse and external sources we end up making it pretty much impossible for a true team to form. As everyone reports into different lines, usually with engineering and scrum master going into some head of something, and product into a shadowy figure called ‘THE BUSINESS’, we have no common leadership thread to help establish a culture.

This also aligns to technology or function, which intrinsically builds silos and introduces dependencies. We broadcast that we care more about technical excellence and domains than customer value.

I’ve actually simplified this as it’s quite likely that each type of engineer will have a different reporting chain. This means that our unfortunate PO needs support from at least 3 different reporting structures to build the Lego set.

I know I said I wouldn’t, but I will talk very briefly about what happens outside the team here. If we had a common node within the team, then any tension could be resolved internally. Scrum Master and engineer disagree and can’t reconcile, they go to the TM and they sort it out. Job done. When this focus is outside the team, it’s usually WAY outside the team. THE BUSINESS and engineering usually have completely different reporting structures, often ending in the C-Suite. Can you imagine having to escalate to the COO because of a tension between a developer and SM? You wouldn’t bother, so it wouldn’t get sorted.

This system makes it very difficult for a team to form, introduces information dependencies, and aligns us to technology instead of customer value. We now have at least two cultures trying to collaborate, neither of which is primarily aligned to the customer. Decisions on our Lego might take a while.

Worst so far: 2/10

Product Owner

It feels wrong, but hear me out.

1. The Product Owner is the only one accountable for customer value so it makes sense for them to be able to make personnel decisions in order to make that happen
2. It clearly broadcasts that we’re in the value business
3. Healthy tension is provided by the engineers advocating for technological excellence and the SM advocating for process excellence
4. The team is there to deliver customer value, and the PO is best placed to provide guidance to the team as to how they can do that better
5. Tensions can be resolved immediately within the team
6. Scales gloriously without the need for function or technology to play any part in the reporting chain for the entire organisation

The downside here is a pretty significant conflict of interest between value creation and pastoral care. It’s worth noting that we had these conflicts with every other role, but at least this one is weighing up the two most important aspects.

Despite a slightly uncomfortable feeling, this simply makes sense. Like peanut butter and jam. 8/10