Fresh New Eyes

I haven't written for a while now. It has been a pretty hectic period.

On top of that my beautiful daughter, Sophia, has come into my life.

I know, No Excuses, but, no matter how well you think you're organised, sleep deprivation and all new concerns can disrupt a little bit your routine.

My daughter birth has been an incredibly formative learning experience. There are a lot of aspects of it I could talk about for hours, picking up on metaphors about iterative and adaptive processes.

However there is one, little aspect, in particular, I would like to highlight in this post.

My wife's labour has been longer and more troubled than expected. Everything went very well at the end, but during the process I've been all the time very attentive with all the things that were going around. What struck me the most was the fact that the midwife in charge any few hours shouted: "fresh eyes!".

That was the signal that anyone who hadn't dealt with the patient yet, had to review the log and the action taken by that time and validate the next step.

A simple acknowledgement that we're not perfect. We can make mistakes. But we can reduce errors relying on collective intelligence.

As software developers we must be aware of our limits as well.
When I can't do pair programming (not a very popular practice nowadays) I usually call very often for code reviews or a second opinion. It happened to me to send a code review request on a semi-finished features, just because I wanted to validate my choices. This practice has been seen, from time to time, as a sign of weakness: it doesn't comply with the manly idea of the omniscient, infallible, lone developer.

This way, I tend to release bug-less, reviewed, well-known and well-structured code. Hence, I think I'll keep going my way, sharing and taking the opportunity to look at my work, whenever I feel like, with fresh new eyes.

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.

The Product Owner, The Scrum Master, His Manager & Her Boss

There is a pattern I think is very common in organisations that are transitioning to Agile: the sense of losing hierarchical references.
Modern organisations are strongly permeated with hierarchy. And not only organisations, individuals as well.
It seems to be a common thinking that it is natural, in life as well, not only at work, to have a boss, as an obvious, inexorable fact.
As if there were an intrinsic universal law saying that something is do-able only if a boss has told us to do it. To the extent to assign to supreme and divine entities hierarchical relations, to preserve the consistency of this model.
I'm not going to dwell in anthropological justification, but I think that the structure of modern companies probably comes from the beginnings of industrialisation era, strongly influenced by military hierarchies.
Now, I've already digressed a lot on this concept, and it's the case I leave to the anthropologists the burden to explain why hierarchical structure is so ingrained in our culture, minds and communities.
The point is, when a company decides to take the leap of faith for an agile framework, most of the times it happens to be Scrum. No matter how well the framework is implemented, how good the Scrum Master is and how the teams keep up, there is a problem that usually emerges (at least according to my experience): the fight for power.
Things start changing when you adopt the new framework. So, who is the boss now? Who takes the decisions?
I've been asked in many occasions to give a presentation about Scrum and Agile methodologies in general, especially by companies who have been implementing agile for a while and would like to have a fresh view.
During my presentations I like to involve the audience asking some questions.
Most of the times I improvise the questions on the spur of the moment, depending on the vibes I get. Sometimes, apparently harmless questions can reveal a lot.
For example, when I present the typical three roles of Scrum: Team Member, Scrum Master and Product Owner, I then ask: "Who is the boss amongst these three?"
According to the mental model of the audience, the answer is usually either the PO or the SM. Rarely, only when the audience's formed prevalently of developers or there's someone trying to play smart, the answer is the TM.
No matter how clever you think you are, at the end of the day your mental bias will trick you.
And, yes, here we are, eventually at the core of the question: Scrum doesn't define a chain of command neither a hierarchical structure.
The three roles - well the people impersonating them - should deliberately cooperate.
In no Schwaber's or Beck's book, I've come across with any hierarchical definition among the Three Roles of Scrum.
Yeah, it looks like they tricked us.
They left us alone, playing our daily, absurd plot of lovers and haters, bosses and traitors, commanders and executors, conquerors and defeated, climbers and besieged.
Mostly as the characters of one of my favourite films: The Cook, the Thief, His Wife & Her Lover
If you've followed me so far you're probably thinking: so what? What do we do then?
I'll answer that in the next post.
Stay tuned!

Introduction

Hi, I'm a veteran software developer, with many years of experience practicing, and occasionally coaching, agile (XP, Scrum, Kanban, Lean),  even though my main and favourite professional activity remains coding.

Some years ago I moved to UK and, in this blog, I'd like to tell you about my adventures, learnings and thoughts since I joined this exotic tribe in the middle of the Thames Valley: The British.

DISCLAIMER 1:
I may use a humorous or irreverent tone every now and then, just because I like to put things in a playful and funny way: no offense intended.

DISCLAIMER 2:
All characters appearing in this blog are fictitious. Any resemblance to real persons, living or dead, is purely coincidental.

DISCLAIMER 3:
English is not my first language and, truth be told, not even the second, if I look back to the last ten years. Hence I apologise in advance for my poor writing. This blog is also an opportunity for me to improve my communication skills.

Feel free to comment and to correct.