The Three Roles of Scrum

The Scrum framework suggests to distribute the responsibility of a project amongst three different roles: Product Owner (PO), Scrum Master (SM) and Team Member (TM).

Now, let me be pedantic here and stress a little bit on the definition above.

I've talked about distribution of responsibility; I haven't defined any chain of command nor suggested any hierarchical structure.
I know it may sound pretty much the same, but the difference is huge.

Here are three slides I've used in a presentation a while ago.

PO

TM

SM

Question for you then: who's the boss amongst these three? :-)

If you've read my previous post, you know that the question itself is badly formulated.

A more interesting question I was actually asked during a presentation is: 'Who takes the decisions?'

We all know it's considered impolite to answer a question with another question, but allow me an exception here: 'Which decisions?'

In my opinion this is a key concept, in its way revolutionary, in Agile: the decision making process doesn't follow the traditional pyramidal structure, where people in the upper positions takes all the decisions or can override the ones taken in the lower positions.

Don't get me wrong: that is a model that can work in some contexts.
For example in those fields where the knowledge necessary for a job remains pretty much constant in time, at least in a lifetime.

I can't think of a modern example at work (*), but let's say you were an ancient Roman soldier. Once you learn how to march and kill people with your dagger, then it becomes a matter of refining those techniques and keep going killing and surviving to climb the military pyramid.
No doubts on the fact that an ancient Roman commander would have been able, at any age, to show a freshman the best angle to pierce a dagger in a human body.

I know, it's a squeamish example and I'm hugely simplifying here. Nonetheless you get the idea, don't you?

In contrast, let's pick up a modern knowledge field, like IT for example.
Let's say you're a successful fifty-year old technical manager: are you definitely sure you are more competent than your twenty-five-year-old techy software developer, when it comes to chose the last fancy web framework? It might be the case, but let's be earnest here: it's highly unlikely.

What is suggested by modern methodologies is to 'move' the decision close to the best decision makers, according to the area of competence requested.
The analogy may sound strange, but it's similar to a consolidate practice in Big Data (jeez...I said the buzzword): moving the computation close to the data.
Well, here the idea is pretty much the same: distribute the decision making responsibility in order to move the decisions close to the competence.

This way, instead of having a single point of failure, The Boss, who has the final say on everything, everyone will have their voice depending on their area of expertise. Simple common sense, innit?

For example, the developer, being the one writing the code, is usually in the best position to say how difficult is to implement a new feature. Whilst the Product Owner, having more frequent contacts and discussions with the clients, is usually in the best position to define priorities or evaluating on the economical repercussion of taking specific actions.

What does that mean? Simply that, for example, if the Product Owner wants to have a plan for the deployment of a new feature, the dev Team are the guys to consult. They have the competence, the experience and the feeling to make those estimations.
On the other hand, if the Team wants to have more details on a feature or on what prioritise in order to maximise the return on investment, the Product Owner is the decision maker for that.

Again, I'm hugely simplifying here.
In my defence I'd like to highlight the fact that unravelling the complexity of the interactions within a team in a single post it's definitely not an easy task.

Long story short, the answer to the question "Who takes the decisions?" is: it depends on the decision and the area of responsibility it falls in.
The responsibility is distributed, the decision making process is brought as close as possible to the people who have the best competences.

For the other question: "Who is the boss?"...well, I'm afraid we have strong impedance here. A mismatch between two likely incompatible models: Agile and Management.

Curiously enough, while I was writing this post, I accidentally bumped into this old, but always valid, article of Steve Denning : Why Do Managers Hate Agile?

What do we do with managers in Agile then?

It wouldn't be me if I didn't end a post without an open question...and a film suggestion: The Boss of It All.

(*) I don't want to be dragged into the diatribe of smuggy smug doctors vs nurses, but still this's a good case to spot out the confusion between the establishment of a hierarchy vs a simple separation of concerns. During the review of this post my clever, and currently very pregnant wife, came up with a perfect example: the medical system. A friend of hers, when she was pregnant as well, had a visit with a GP doctor who was completely incapable to get the baby's heartbeat. At the point that he started mumbling savantly about 'intra-uterine fetal death'. Luckily an 'uneducated'-midwife's simple check saved the day and we had chance to meet a beautiful lively baby-girl a few months later.