The “people problem” problem and the great agile divide

AllanAdmin from Allan Kelly Associates

“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.


Subscribe to my blog newsletter and download Project Myopia for Free

The post The “people problem” problem and the great agile divide appeared first on Allan Kelly Associates.

Historians of computing

Derek Jones from The Shape of Code

Who are the historians of the computing? The requirement I used for deciding who qualifies (for this post), is that the person has written multiple papers on the subject over a period that is much longer than their PhD thesis (several people have written history of some aspect of computing PhDs and then gone on to research other areas).

Maarten Bullynck. An academic who is a historian of mathematics and has become interested in software; use HAL to find his papers, e.g., What is an Operating System? A historical investigation (1954–1964).

Martin Campbell-Kelly. An academic who has spent his research career investigating computing history, primarily with a software orientation. Has written extensively on a wide variety of software topics. His book “From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry” is still on my pile of books waiting to be read (but other historian cite it extensively). His thesis: “Foundations of computer programming in Britain, 1945-55″, can be freely downloadable from the British Library; registration required.

James W. Cortada. Ex-IBM (1974-2012) and now working at the Charles Babbage Institute. Written extensively on the history of computing. More of a hardware than software orientation. Written lots of detail oriented books and must have pole position for most extensive collection of material to cite (his end notes are very extensive). His “Buy The Digital Flood: The Diffusion of Information Technology Across the U.S., Europe, and Asia” is likely to be the definitive work on the subject for some time to come. For me this book is spoiled by the author towing the company line in his analysis of the IBM antitrust trial; my analysis of the work Cortada cites reaches the opposite conclusion.

Nathan Ensmenger. An academic; more of a people person than hardware/software. His paper Letting the Computer Boys Take Over contains many interesting insights. His book The Computer Boys Take Over Computers, Programmers, and the Politics of Technical Expertise is a combination of topics that have been figured and back with references and topics still being figured out (I wish he would not cite Datamation, a trade mag back in the day, so often).

Michael S. Mahoney. An academic who is sadly no longer with us. A historian of mathematics before becoming involved with primarily software.

Jeffrey R. Yost. An academic. I have only read his book “Making IT Work: A history of the computer services industry”, which was really a collection of vignettes about people, companies and events; needs some analysis. Must try to track down some of his papers (which are not available via his web page :-(.

Who have I missed? This list is derived from papers/books I have encountered while working on a book, not an active search for historians. Suggestions welcome.