Hold on to your agile hat! Or rather not?

5 min readNov 18, 2022

Is a strict role segregation beneficial when implementing agile frameworks or not? What role does leadership play in scaling agile?

Roles in Agile

Agile methodologies, such as SCRUM, use well defined roles, such as product owner or scrum master, to describe a group of related responsibilities which need to be performed by a member of a functioning agile team. Most larger organizations would layer more traditional structures on top of agile methodology to accommodate managerial and technical career paths so common in software development companies.

Scrum (software development) — Wikipedia — en.wikipedia.org

Scrum is a framework for project management with an initial emphasis on software development.

So, in many cases, you could easily end-up with four or more distinct leader roles per team: (1) product owner representing the product/feature dimension, (2) scrum master facilitating the day-to-day team organization, (3) technical leader (architect) representing the technical perspective, and (4) team leader (manager) responsible for people and talent development. On top of the above you might have other specialized roles, such as UX designers, program/project managers and others, required either due to the special skillset or due to the need to coordinate activities across many teams.

Who is responsible? And for what?

At that point, you might start asking: Who is eventually responsible for the overall outcome? And that’s a good question. Not only are there many distinct roles, but also there often is a desire to clearly define responsibilities so that those responsibilities do not overlap between distinct roles.

It looks good on paper: you don’t want people to step on each other’s toes, at the same time you do not want to leave any blind spots, any responsibilities which would lack ownership.

There is even sometimes an aim to create some hypothetical balance of power between different perspectives to balance out product requirements, technical requirements, managerial objectives, and team member objectives by making sure the powers of individual leaders are limited in some ways.

The reality is much more complex though. With four or more leadership roles the decision making becomes slow, difficult, and overall responsibility nonexistent:

On one hand, you could get complaints from developers about poor managerial decisions, from technical leaders about unnecessary shortcuts and technical debt, and from product owners about lack of feature velocity. This is the example of “stepping on each other’s toes” issue.

On the other hand, you might get chronic indecisiveness, when for each, no matter how trivial, decision you need to gather four or five people in the room, because no one is willing to decide on her own. It is a clear symptom of lack of ownership.

There are always gaps where weeds can grow.

My takeaways

Given the problem statement above, let’s see what I have found working throughout my practice.

Multiple hats

First, let’s not be dogmatic about each person playing only one role. I find it not only acceptable, but desirable, to have people wearing multiple hats. This limits the number of people you need in a room to be able to reach a consensus or to decide in a non-destructive way.

I am not arguing for one person to take on all responsibilities and of course, people are different, with different skills and preferences. But you can have a technical manager pairing with hands-on product owner / scum master. Or you can have a team lead facilitating the process as a scrum master and partnering with a product owner and an architect on what and how.

What’s important is to be aware of the roles you need to fill and make sure on every team those roles are assigned and well played, yet each team can have a slightly different setup, based on unique team member profiles.

It’s all about leadership

And this one is simple: there can be only one person responsible. The ultimate decision maker, who steps in when consensus can’t be reached or when the train goes off track.

I have experienced two models in my career: either product-led or engineering-led organizations. Success is always about a healthy partnership between the product management and product development leads, just sometimes it is the product manager and sometimes the head of engineering or CTO, who is the more senior partner.

And what about the balance of power? There is none. You either pick your leaders wisely and it works because they can balance the different perspectives and constraints themselves, or you don’t, and it all falls apart eventually. There is no magic framework preventing stupid people from doing stupid things, but there are so many frameworks slowing down smart people in doing what they are best at.

Past Articles

Consider checking out past articles from my series on software development:

Software Industry’s Alphabet Stew: CRM, XDR, …

Technology Thoughts 2.0 — Why software vendors manage to discredit any new product category before its maturity, leading to a never-ending cycle of inventing new buzzwords.