+++
title = "Agile vs Culture: The Story of Outliners"
date = 2015-12-18
category = "thoughts"

[taxonomies]
tags = ["agile", "book", "empowerment", "disenfranchise", "en-au"]
+++

When the culture goes againt agile.

<!-- more -->

![The Agile cycle](/images/agile.jpg)

In some recent agile conferences I went this year, I've been recalling and
telling one story from 
[Outliners](https://www.goodreads.com/book/show/3228917-outliers) 
(which I wrongly assumed it was part of
[Freakonomics](https://www.goodreads.com/book/show/1202.Freakonomics) 
about the number of accidents in Asian and South American
airlines. The book points that there is a cultural difference between those
two and American people, in which the former see a larger distance between
them and their superiores than the later.

Why I keep recalling this? Because in agile teams, there is no hierarchy: the
PO is as important as the junior developer; the tester has the same input
value as the senior developer. This means that the team doesn't need to wait
for someone higher in the chain to make a decision: the team is free to make
their own decisions on how to better reach the value requested by the PO.

In all events I went, there is a constant problem on "how do I make my team
see the value in Agile" and "why Agile doesn't work". Again, it seems that
Agile goes straight against the cultural reference South Americans  -- in this
case, me and my colleagues  --  because we are cultural trained about that guy
who is in a higher place in the chain and, thus, I depend on him on the
important questions (for whatever value of "important" I believe a solution
is). 

In the end, it's not as much as changing a company development model and
explaining to managers and directors on how the software  --  and its value
 --  will be delivered, but fighting against the cultural norm of having
someone in a very high place that can make decisions while people think they
are very low in the chain to make a decision. Not counting the constant fear
of being wrong (which is actually good in agile).

The problem revolves not only on this point, but also in the assumed position
based on role name. Someone will assume that because their position is
"developer", it means that they are below  --  and receive orders from  -- 
the PO; someone will assume that because someone's else role is tester and
their are designed as developer, they are up in hierarchy and, thus, can order
the tester to do whatever they think it must be done.

Here we have a second problem: we need to detect and empower those who think
they are below in the chain and "disenfranchise" those who think they are
above everyone else due the role name.

My plan for 2016 is to read some books about those topics and bring this
dicussion to future events. Which me luck. ;)
