Recently, I have witnessed a disturbing trend.
I’ve witnessed some companies who are trying to transform themselves into ”agile” organizations without ever referring to the original philosophical underpinnings of the Agile Manifesto and its principles. And in some cases, I have heard of companies or divisions within a company rewriting the entire Agile Manifesto, sometimes removing verbiage that would either challenge the existing company culture or would be too difficult to realize in their current environment. I have also worked for or know of consulting companies wanting to make money by creating their own principles and methodologies.
As I said before, I find this troubling.
Hollow ceremonies are ways to “do” agile, but in order to achieve true agility we must be Agile.
In an effort to emphasize the values and principles of the Agile Manifesto, I have decided to create a series of blogs with my thoughts on each value and principle.
With Agile we are now uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value certain things, one of which is:
Individuals and interactions over processes and tools
That is, while there is value in the items on the right, we value the items on the left more.
The Agile Manifesto is best seen as a reaction to the environment at the time. Many authors are saying that software development values have gotten out of whack because the majority of companies now value processes and tools more than individuals and interactions. Obviously in order to create better software this needs to be corrected!
Those of us challenged with transforming organizations to Agile see the attractiveness of putting processes and tools over individuals and interactions. There are a great number of individuals in positions of power (and influence) who believe that only if they can find the right processes and get people to slavishly follow then we can deliver. In this mindset, people are “resources”; chess pieces to be moved around. The chance to be master of the universe is intoxicating and plays well into our mistaken notion that we can be in control. However, let me be clear that it is a fool’s errand because it doesn’t work well in the real world and doesn’t work well with software development.
In some respects it reminds me of socialism in that if we only move the right levers and offer the right incentives, we can get complex social constructs to behave in predefined ways. And the ideas around process management can be traced back to the theory of a mechanistic world that can be known and tamed. We would be better to look at theories of complex systems for inspiration.
Some things look great on paper (the Dallas Cowboys would always win if they didn’t actually have to take the field), but what looks good in theory doesn’t always work well in practice. The Soviet Union fell because grand theories and plans do not always work well with real human beings because humans are not cogs or machines and will not behave predictably. For instance, real humans do not like being managed (especially micro-managed!) and workers are motivated more by intrinsic factors than extrinsic rewards.
Humans are messy. They are individuals. They work well with some people and not well with others. They cannot be treated as if they are all the same. I have three children of different ages, therefore I treat the seven year-old much differently than the twenty-one year-old. And though they share genetics and a similar environment (parents, socio—economic, etc) they each have their own personality and how we interact and react to each other is vastly different. There is not one playbook that will necessarily work with each child so why would we expect it to work with every individual at work? Of course, we all strive for fairness and there are certain ways we should all be treated (this is where HR comes in), but one process fits all? I think not.
Because teams are made up of individuals, every team has its own individual personality. Even if I found a process that works well with one team, it might not work with another. That is not to say that there isn’t universal processes that will work with almost every team, but the more prescriptive and detailed the less likely it is that it will work with everyone (think waterfall). This is why agile methodologies, like scrum, rely on fewer controls. The philosophy of Agile should be shared by all teams, but even the basic methodology (scrum vs kanban, etc) need not be shared by all teams because the needs of the teams and the individuals comprising the teams is not shared.
Just as one process will not work with all individuals or teams, one tool (or set of tools) cannot work for all teams. The manifesto does not say that tools are not important, but their use should be subservient to the individuals doing work and should not interfere with the interactions among individuals.
Software development is communication and creativity
It only works when people are treated like individuals so their inherent creativity can be evidenced. Furthermore, individuals on a team must constantly interact but processes and tools are often in the way of this collaboration. The writers of the manifesto knew that processes and tools were necessary to software development, but our very human need to have an illusion of control can lead us to value processes and tools over individuals and interactions.