“the two view-points are always tenable. The one, how can you improve human nature until you have changed the system? The other, what is the use of changing the system before you have improved human nature?”I am sure I am not alone in exhibiting another of Orwellian trait: Double think.George Orwell, “Charles Dickens” essay in Shooting and Elephant and Other Essays, Penguin Books
For several years I have been guilty of agreeing with two contradictory points of view:
- The Deming idea that the system governs how people will perform and act
- That no matter what system (e.g. Scrum, XP, Prince2, DSDM, etc.) you use to develop software the motivation and quality of the people is the overriding factor
I should have noticed the cognitive dissonance sooner. I’ve been known to say, and still believe: “The true test of any software development method (e.g. Kanban, Scrum, etc. etc.) is whether it can help mediocre people perform, i.e. deliver, be more productive”
In that one statement I epitomise the contradiction. I’m hoping that writing this blog will allow me to resolve this!
This isn’t an academic problem: depending on which side of the argument you come down on will determine how you go about improving things. It also explains why some people in the Agile moment emphasis: trust, communication and other inter-personal issues while others emphasis a method, technical practices, etc.
I’m thinking of my experiences:
- I have worked in environments where the system defeated the people: Railtrack privitisation, Sema had an ISO-9000 waterfall process and 120 people. Of course in 120 people some were good and some not so good.
- I have worked in places where (good) people have overcome the system: two years after leaving Railtrack I returned, a much smaller team were in maintenance mode. The same process was in place but we circumvented it, we faked the documentation and so on.
- And I have worked places where everyone was treading water and complying enough with the system
I have worked places were the concept of “system” would have been laughed it, things might be more accurately characterised as “Chaos.” But even in this chaos there was a system of sorts.
At Dodge Group it was hard to define any system or process, but there was somewhere a process. The company was trying to sell, sell, sell so they could IPO and the software team just had to keep up as best they could.
The good people at Dodge won out for a while. I instigated a simple process we could now recognise as a form of Agile but ultimately the company, the system, killed the success. Partly by hiring bad people, partly by not recognising the good people and partly by letting the system run its course.
In my “Agile will never work in investment banks” posting a while back I made a similar point: Good people in banks can install a good process which can deliver. But in time the bank - the systems, culture and contradictions - will kill the system and dispose of the good people.
Then there is the question of whether “good people” are themselves the result of the system. Can you pick up a “good person” from company A, put them into company B and let them do their good stuff?
An article in the MIT Sloan Management Review a few years back suggested that when “star players” move to a new team they don’t necessarily, or even normally, keep their “star player” performance. (When ‘Stars’ Migrate, Do They Still Perform Like Stars?, Fall 2008 issue.)
So where does all this lead us?
I think there is truth in both the System-first and People-first point of views. Things are not so black-and-white. Sometimes the System-first view is right and sometimes the People-first is right. There are forces at work in different contexts.
Some of these forces are:
1) The strength of the system: the stronger the system the more likely it is to win out.
The strength of the system derives form multiple sources including: the effectiveness of the system, the degree to which it is enforced and the degree to which people see their interests being served by the system.
Reuters CMMI initiative also put a lot of effort into policing. At Dodge the system was weak day-to-day, developers got on with it and they made good stuff.
At Sema Railtrack (first time) a lot of effort was put into policing the system, the system delivered ISO-9000 which helped the company win contracts. As a programmer woking in the system it didn’t seem particularly effective but I guess it was effective at generating money.
2) The System affects the Good People
At Reuters the system encouraged people to leave, I was one. At Dodge the system eventually recruited the wrong people, forced others out and wore down the good people who submitted.
3) Good people can make an poor system work
Primarily through ignoring it, compensating or changing it. Which leads to…
4) Good people can change the system
I’ve seen it happen. In fact you need at least one good person to cause they system to change or it will not.
Again a strong system is harder to change.
5) How “good” are the people?
Yes “good people” can do things change thing but how “good” do you need to be? Is it real a question of having super-stars? Most people aren’t super-stars. Surely we should be more concerned with the mediocre.
And before anyone rushes to say “Good developers are 10 times (or 28 times) better than average” please read Laurent Bossavit book “Leprechauns of Software Development” where he shows the evidence for this claim doesn’t hold up.
I guess these conclusions are going in the Deming direction.
Yet good people can make a bad system work; but if they do not succeed in actually changing the system it will eventually impose itself.
Can I suggest it comes down to a question of time scales: In the short-run good people can overcome a poor system, but in the long-run, unless they change the system for something better the system will overwhelm them.
And the mediocre people? - How about we say this:
Over the short-run, the better your people are the more likely they will overcome a poorer system, but in the long-run the hard it will be for people to sustain the effort if they do not change the system.
A good system will help everyone work the best. It will allow star-performers to shine and mediocre people to contribute and feel good, I’d even like to think a good system will improve the mediocre people.
I'm not convinced that the two are contradictory. The system governs how people will perform and act, but not necessarily in the intended ways - especially if the design of the system fails to understand enough about the people who will be implementing it and the situation they are in. Good people will subvert a badly-designed system in order to still make things work somehow. Perhaps the Deming principle re. right to pride of workmanship is also relevant here.
ReplyDeleteok lets first pretend the PEOPLE were good and the SYSTEM bad. Once those good people try to change the system, the system will eliminate them by advancements and cost cuts.
ReplyDeleteif we pretend SYSTEM was good and the PEOPLE bad. Once the good system forces the ppl to behave, the ppl will workaround the issues and ignore the rules
Hi Allan, thanks for the post. I've been wrestling with the people & system contradiction too - I wrote about it too: "It's the system, not (and?) the people." http://winnipegagilist.blogspot.ca/2013/03/its-system-not-and-people.html
ReplyDeleteNice article, I like thinking about these issues a lot. Two complementary articles I've read square pretty well with your thoughts. The first is from Alistair Cockburn
ReplyDeletehttp://alistair.cockburn.us/Characterizing+people+as+non-linear,+first-order+components+in+software+development
The other is about the 10x programmers. I also enjoyed Leprechauns of Software Development, and I see that the lack of evidence will not stop this meme from replicating. HOwever, there is another truth that I think we've all seen - the 1/10th programmer:
http://www.techfounder.net/2013/04/04/there-are-no-x10-developers-but-there-are-certainly-110-ones/
I need to track down the references, but at least two of the speakers at Lean Agile Scotland said that there's some newer research that shows the "alpha" coders are the ones who don't just start hacking but spend time chasing down the requirements before they even start. In environments where the communications are good the differences become very small, perhaps nonexistent. Like I said, this may be a leprechaun, but it does make sense.
ReplyDeleteAnd, (no sh1t Sherlock ;)) the people who are experienced are the ones who have probably learned this lesson already.
I have experienced this anecdotally, where I pushed for the recruitment of someone who wasn't technically the best but had a really good rapport with people. She turned out to be an absolute star, building relationships across to the business and testers, and making very few mistakes.