Scrum shouldn’t just be for developers

Let’s improve all ways of working

Recently, I received a battlefield promotion to Product Manager on my tech team. I’ve had more exposure to how things work outside of my scrum team, and have collected thoughts about how things ought to work.

Most people I speak to are bewildered by the operation of a scrum team. “So, who manages you?” or “can I have an ETA on this?” are questions that don’t really have a good answer in the context of our, specific, way of working (your mileage may vary).

I contemplate this confusion against a conversation I keep having with a close friend; she works for a well known pollster and consultancy. The following is a heavily abridged summary.

F: “I’m always overworked”

KC: “Why?”

F: “This project was meant to take 40 hours, but there’s no way it could take 40 hours.”

KC: “Who decided that the project would take 40 hours?”

F: “The senior consultant”

KC: “Do they work on any projects similar to this?”

F: “No”

KC: “Why are they providing an estimate for the client”

F: “That’s just how it works”

KC: “Would it be fair to say they’re inclined to underestimate, to appease the client, in order to reduce costs, increase profits and keep senior leadership happy?”

F: “Yes!!!!”

The dysfunction here is one of the same dysfunctions we try to eliminate in a scrum team - the person estimating work is not the same person as the one actually doing the work, and often has perverse incentives leading them to underestimate work.

Another common complaint from my friend is that of scope creep, the client will chuck out most of the requirements at the last minute and ask for something completely different! Usually because they have their own perverse incentives that mean they don’t actually care about the progress of the project - as long as they can shift accountability to the ‘external consultant’ who presumably got it all wrong.

What’s the point of this anecdote? My friend is suffering from all of the same problems agile ways of working are designed to solve. In this case she is doing client research, but effectively there is no difference here between a software project and a research project for a client. The management problems are the same.

So, why have agile ways of working taken over the software world, but not other parts of our working culture? My guess would be something to do with accountability.

In a software project, or indeed an infrastructure project there is a defined output - the product. The product lives and breathes, it exists and is used by lots of people. When the product isn’t up to scratch people start asking very difficult questions. Usually, key to this is one very simple fact - the product is almost always the one thing in the business that critically important to its success. Whoever controls the product, ultimately, is one of the most important people or groups in a technology business, for they have the leverage to be able to deliver profit.

In a consultancy, no one really cares about output - a bolt assertion, I know. The client is almost certainly some large organization accountable only to its shareholders. The person the consultancy is dealing with is presumably some mid-level manager who has only meager interest in moving whatever project they’re handling forward, they’re usually accountable to a line manager, who will accept ‘the consultants are slow’ as a reasonable excuse. When I say output here, I mean valuable output. People certainly care about output - but usually they only care that work has been done to their exact specification not whether it is any good.

This problem I am describing is the same problem that meant the entirety of Whitehall was unable to come up with a meaningful way to deliver a COVID-19 vaccine into British peoples arms, but a few people in a room with complete accountability and capability could. As soon as there is a boundary of responsibility and capability efficiency reduces 10x.

So then, a lack of clear accountability and oversight ensures nothing ever changes.

My argument in its simplest terms, is that there is no reason why the efficiency gains introduced by empowered agile working in a software project cannot be applied to any kind of delivery project.

In a future post I will write about how ways of working can change to be more efficient in practice, but for now I’d like you to think about parts of your organization stymied by cross team boundaries, and if there is any way those boundaries can be eliminated.