“Its always a people problem.” Gerry Weinberg, The Secrets of Consulting, 1985
The great, unspoken, divide in agile is between those who believe the individual is all powerful and the centre of everything, and those who believe the individual is the product of the system.
Weinberg’s “law” is taken as unquestionable truth by most people in the agile community. Whatever the conversation, whatever the problem a wise old-sage will stand back and say “It’s always a people problem.” And in a way they are right.
People made the modern society and economy. People work in organisations, people make the rules, people enforce the rules, and ultimately someone in that organization made it the way it is. If only those people would act differently, make different rules, if only those people had greater foresight.
The problem is, once people have put all the pieces together the result is a system, not necessarily a technology system but a system of rules, norms, standards, accepted practices and “the way things work around here.” Which puts me in mind of Winston Churchill:
“We shape our buildings, and afterwards our buildings shape us.” Churchill, October 1943.
Yes, people shape our organisations, our processes and our culture, so it is always a people problem. But people are as much prisoner to those decisions as they are controllers of those decisions. Changing those things means changing the system, while that change needs to be made by people – and therefore is a people problem – the power to change that is distributed.
For example, Donald Trump has tried to change the US system in so many ways during the last four years. Often he has been frustrated by the rules of the system. He’s made some changes, and some of his actions will create changes in future. Some of us are glad the system constrained him, others are unhappy. Despite being the most powerful man in the world Trump was constrained.
So while it is “always a people problem” in that people created the system and operate the system doing something about isn’t just a case of asking the system operators to do things differently.
This is the great agile divide.
There are many, perhaps most, in the agile community who believe that every change, every improvement, is rooted in people. People are the centre of agile and all energies should be directed to help them do great work and create a system they can work within.
Then there are others who believe that it is the system which needs to be centre stage: because people work within a system.
Watch Stockless production and ask yourself: in the first simulation, when the waste is piling up, is there anything the men on the production line can do to improve it? I don’t think so because they are inside the system and the system is controlled by others.
I see the great divide again and again in the “agile” advice given out. The community doesn’t recognise the divide but every speaker, writer, consultant and coach is biased one way or another. Actually, “coaches” tend to put people first while “consultants” work with the system. Regurgitating “its a people problem” hides the divide.
Generally I align myself with the second group – its one of the reasons I associate with the Kanban community. But the process group has a problem.
In the days before agile there was a widespread belief that one could define the process, turn the handle and everything would be alright. That logic led to much of what fell under ISO-9000, TickIT, CMM(I) and other “process improvement initiatives.” I suffered under some of those regimes and I see the scars on others.
The problem was that this thinking lead to process experts who decided the process for others to follow, and process police who enforced it. So again, it is a “people problem”. But those process people are as much prisoners to the process as prison guards are. (I don’t want to be one of those people but I probably look like one of them on occasions.)
So, where does that leave us?
I no longer agree with Jerry Weinberg: people may create the problem, people may be key to fixing the problem but fixing a system is more than people.
I see my role, as an Agile Guide, as creating systems people can thrive in, where are not just cogs in a process, places where people can do their best work, where people problems can be seen and addressed. The system needs changing to respect the people, equally, those people deserve respected and involvement while changing the system.
Published on Java Code Geeks with permission by Allan Kelly, partner at our JCG program. See the original article here: The “people problem” problem and the great agile divide Opinions expressed by Java Code Geeks contributors are their own. |
