Aug 282011
 

A few days ago Derek Huether started a discussion on his Criticalpath blog about “Theory X vs. Theory Y” and asked for feedback who believes in what: Do you prefer command-and-control or do you believe in team empowerment?
It’s an interesting topic, as the question touches the fundamental disagreement in today’s management approaches. I recommend to have a quick look at the article and the comments below it.

So what’s the answer?
When confronted with two such polarizing choices (which both seem justifiable), a typical reaction is something like “yeah, well, it depends, somehow a combination of both, maybe”.
Well, probably correct. But unfortunately that doesn’t really help. Derek also highlighted the issue by asking what people “believe” in. Can that really be a matter of belief? Shouldn’t we have an understanding about management which is substantiated in a way that we know what and why we’re doing?

The most important thing to know about methods is why they worked for somebody else. So let’s look at the backgrounds of X and Y.

X vs. Y

Theory X resembles a lot of the ideas that served Frederick Winslow Taylor as a basis for his approach of Scientific Management, published in 1911 and first used by Ford’s Model T production.
Basically it expresses a fundamental mistrust in people doing work as employees. The assumption: What they produce is not theirs, so they’re only interested in the money they receive and they will try to get away with as little dedication to the job as possible.
For management to stay in control this must result in a strict command-and-control approach: Tell people exactly what and how they should do it, and verify compliance with the given orders.

In contrast, Theory Y reminds more of the idea of man that the agile approaches follow. People and teams  act responsibly towards an agreed goal, and they are able and willing to organize themselves. Empowering the team is considered more productive for problem solving and creativity than command-and-control.

When does X work?

As said above, the philosophy of Theory X dates back a hundred years and aimed at industrial manufacturing. What are the characteristics of that?

  • There is exact knowledge upfront about what has to happen. E.g. the process for assembling a car is precisely known in advance.
  • The human beings in that process fulfil a function – the function stays the same even if people are replaced.

This kind of work – i.e. routine with only few (if any) unknowns – can in principle be executed with command-and-control.

Having said that, I have my doubts that even in these environments a pure command-and-control approach is the most productive choice. While it is necessary to some extend, e.g. Toyota already years ago allowed their workers to stop the production line if they find a problem with the car they currently assemble – the management counts on people’s responsibility and dedication to a quality product.

When does it have to be Theory Y?

Is Theory X and pure command-and-control transferable to the world of projects and software development? Not really  – for three reasons:

1. Software development is about solving problems, which is unlike routine work. The “one best way” how to solve a problem can’t be defined and commanded upfront – the knowledge is simply not there (if one knew everything, it wouldn’t be a problem).

2. In contrast to Theory X, the vast majority of people in the project business definitely have a broader motivation. They do not only work for money, they like the intellectual challenge, being creative and they care a lot about the outcome they produce.

3. A team solving a problem is a dynamic system, and an individual’s contribution is beyond a mere function. A person in a team influences both the way how people work together as well as how the solution is found. If you replace a person, the team will afterwards be a different one.

These aspects are dynamic and can hardly be controlled from outside the team. This is why problem solving teams in fact work like a feedback control system: Given the right feedback, teams can and will do a lot of the adjustments that otherwise a commander would need to order – but here teams do it better, because they know and feel more than any commander outside the team ever could.

But…

So does that mean that you can or should abandon teams to their fate and just wait until they come back with their result? No, probably not. Here’s why:

Theory Y is – as the name says – a theory, which means it assumes ideal circumstances. However, the world out there is not perfect, and neither are teams. Things that may not fall into place by themselves are e.g.

  • priorities (e.g. time-to-market is key for client, but team considers a refactoring more important)
  • team doesn’t make progress as problem is too difficult (for this team or in general)
  • team doesn’t arrive at productive team processes (e.g. requirements definition)
  • hidden agendas (e.g. trying out a new exciting technology)
  • solutions more complex than necessary
  • … and more

This is why leadership is important. Leadership needs to help ironing out any inefficiencies a team may run into (both team internal and considering the project context). It doesn’t necessarily need to come from one person in charge of management – depending on the team there may be different people ensuring leadership in their respective areas.

In any case, this kind of management is basically another source of feedback for the team. It differs from command-and-control in the way that it doesn’t dictate internals to the team. A problem solving team needs to grow and stay intact in order to be productive.

Aug 072011
 

One of the agile methods’ claim is to overcome the tayloristic approach seen in the attempts to “industrialize” software development. For example, they don’t separate roles within the team, and they develop the product stepwise and evolutionary instead of defining it upfront. So is tayloristic thinking now history? It is worth taking a closer look.

A bit of history
Frederick Winslow Taylor published his thoughts in 1911 in a paper called “Scientific Management”. As widely known, his ideas were first implemented by Ford in the production of the famous Model T car (“You can have any color you want, provided it’s black!”). Soon after, the method revolutionized all of the manufacturing industries.

The basis for Taylor’s approach is the following thinking:
There are two groups of people – scientifically educated managers and uneducated workers. While the managers strive for excellence and higher goals, the workers’ only incentive is the money they receive.
Of course this view was criticized later, but it was just the way of thinking in the early 20th century.
Based on this, “Scientific Management” suggests the following:

  1. Strictly separate management and workers
  2. Management shall define “one best way” how work is to be done, and check for compliance
  3. A high degree of division of labor has to be achieved, as only with very small manufacturing steps it is possible to implement the second principle (defining and controlling “one best way”)

So this is it – published 100 years ago, and made for the manufacturing industry. But could it be that there is still an influence on how we think and act in today’s knowledge work? Let’s check.

1. The importance of methods
Did you ever notice the headlines in professional discussion groups on Linkedin and similar networks? Here are some recent examples:
Does anybody have a WBS for setting up a datacenter? Does Kanban have a product owner? Get the PMP certification now! Is it possible to combine Scrum and Waterfall?

What is interesting: The Agile Manifesto implicitly tells us that methods that work for someone do not necessarily work for someone else. It depends on problem, team and context (Andy Hunt just published a good article about this).
But this insight does not yet seem to be part of our thinking. Instead people and organizations are looking for the “one best way” how to solve their problem. As one can see from the questions, understanding an approach as such (and reflecting on its applicability) is sometimes not even tried. The belief in standards is so strong that way more attention is paid to the methods rather than to the problem itself.

Interestingly, as one of the agile methods even Scrum seems to be marketed and discussed in exactly that way – Scrum is the “one best way”, and you can even get certified for it. Discussions often go around how to interpret something, rather than how to adapt it to a specific situation.

Methods are an important market with demand and supply. But in the end this comes from a tayloristic thinking. Not that methods are useless, but applied to unique projects and situations they need to be looked at with reason and understood as guidance. Progress will be made once people start asking “This is the problem I have – how do I best tackle it?”

2. Staffing
Did you ever think about the human resource management seen in companies today? On the one hand the importance of teams is emphasized, but on the other hand HR is very much focussed on individuals, roles and functional skills.
We want teams to perform and deliver projects, but while e.g. successful sport teams spend a lot of time training together we

  • hire individuals
  • put them in pool organizations and “job families” to develop them within a predefined role
  • and we measure individual goals and achievements

This is a modernized taylorism. A step forward would be to value and develop teams as a whole, and spend more attention to improving their productivity.

3. Monitoring and Control
We still have the separation of management and workers suggested by Taylor (even though the workers are extremely well educated as well today). But that is not the point.
Management of course needs to know what’s going in the company and ensure things are on a good way. But how do they usually do this? They define and monitor procedures: Standardized processes, mandatory tools, review boards checking projects for compliance.

Focussing control on how the work is done again is tayloristic thinking (and again is not overly effective when applied to knowledge work). A new (and powerful) way of monitoring and control would instead be to focus on the outcomes. In order to still have regular checkpoints this would lead to smaller projects with more frequent deliverables. In fact it is about applying the philosophy of agile and lean to an entire organization.

We’re clearly not there yet. There is a hidden Taylor in us and our thinking, and in the way we run projects and organizations. And it is still hindering us from further increasing productivity of software projects and knowledge work.

Changing a mindset requires more than just changing methods.