2.7 KiB
+++ title = "Agile vs Culture: The Story of Outliners" date = 2015-12-18
[taxonomies] tags = ["agile", "book", "empowerment", "disenfranchise"] +++
When the culture goes against agile.
In some recent agile conferences I went this year, I've been recalling and telling one story from Outliners (which I wrongly assumed it was part of 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. ;)