Agile Zone is brought to you in partnership with:

Allan Kelly has held just about every job in the software world, from sys admin to development manager. Today he provides training and coaching to teams in the use of Agile and Lean techniques. He is the author of "Changing Software Development: Learning to become Agile" (2008) and "Business Patterns for Software Developers" (2012) and a frequent conference speaker. Allan is a DZone MVB and is not an employee of DZone and has posted 78 posts at DZone. You can read more from them at their website. View Full User Profile

Blaming the People or the System?

03.26.2013
| 3339 views |
  • submit to reddit
“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?”

George Orwell, “Charles Dickens” essay in Shooting and Elephant and Other Essays, Penguin Books

I am sure I am not alone in exhibiting another of Orwellian trait: Double think.

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

It wasn’t until John Harvey tweeted about the latter recently that I realized In was double thinking, my positions were not compatible with one another.

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 epitomize 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 privitization, 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 seen different things happen within the same organization, even within what the company regarded as “one team.” I saw Reuters destroy its own processes in an effort to impose a CMMI level 2 (going to 3) process. (Managers were a bit like the American General in Vietnam who supposedly said “we have to destroy this village to save it”. Like the American’s Reuters ultimately lost.)

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 recognize as a form of Agile but ultimately the company, the system, killed the success. Partly by hiring bad people, partly by not recognizing 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 effects 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.

Published at DZone with permission of Allan Kelly, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: