|
|
|
|
|
+++
|
|
|
|
|
|
title = "Agile vs Culture: The Story of Outliners"
|
|
|
|
|
|
date = 2015-12-18
|
|
|
|
|
|
|
|
|
|
|
|
[taxonomies]
|
|
|
|
|
|
tags = ["agile", "book", "empowerment", "disenfranchise"]
|
|
|
|
|
|
+++
|
|
|
|
|
|
|
|
|
|
|
|
When the culture goes against agile.
|
|
|
|
|
|
|
|
|
|
|
|
<!-- more -->
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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. ;)
|
