Review: Peopleware, Productive Projects and Teams

PeoplewareHere we go for a review of Peopleware: Productive Projects and Teams, 2013 (1st edition in 1987) by Tom DeMarco, Tim Lister. Another long overdue review since I read the book twice again since I first decided to write this review.

This is a book about teams of software developers, what makes them produce exceptional software and how (for the management) to avoid being in their way of such a noble aim. To me, this is also the logical sequel to the Mythical Man Month (reviewed here a few years ago).

The core idea is that developing a software product is an intellectual work (of communication and reflection) in an environment (market and technology) that is changing fast.

I would group the other main ideas in the following categories:

  • software projects are unlike traditional ones
  • teams and motivations
  • creativity and change management

Software projects are unlike others

On the nature of the work, Peopleware: Productive Projects and Teams is not saying anything different from The Mythical Man Month by Fed. P. Brooks. However it draws the more radical conclusion that most of what people do in traditional management is either meaningless or plain counter-productive.

Among the "mistakes" identified for the "traditional" management:

  • everything in "optimized for steady state"
  • experimentation and risk are discouraged or strictly constrained
  • the work is highly standardize with the aim to "squeeze out errors, slack and originality"
  • often accompanied in software development with the conviction that the developer's work can be automated
All this is clearly unwise in the field of software business where a risky project is just one that is not dead yet, and that even if robots learn how to code there will always be a need  for humans to analyze, negotiate and formalize customer needs.

Teams and motivations

So we need developers and arguably quite a few to work on complex projects. That's when you need to know how to grow teams.

A secret for team members to bond (or for the team to "jell" in the books' own term) is to make them share a common aim, which in a context (again) where everything is changing fast is difficult and forces us to look for an abstract aim.

black-24645_150Considering on the other hand that developers' life and software products are literally plagued by bugs, the best choice should interestingly be the same for all software projects: quality.

That said a few other elements are key to succeed:

  • trust developers with as much decision power as possible and make sure the managers are of the "open kimono manager" kind.
  • make sure the work place favors intellectual work (quite enough, livable)
  • recruit the right people: build and keep up a sense of eliteness but don't underestimate the value of soft skills (as opposed to the always needed technical skills) that may help the team to jell.

Creativity and change management

Holger DanskeNow that we've put the responsibility back in the hands of developers we can be sure that if a change is needed no time will be lost to implement it. But how could we make sure that the best change is done ?

Well there is presumably no way to be sure, but several ways to help:

  • let the team spend time thinking about their work.
  • make sure techlead and managers (if any) play as catalysts more than directors.
  • be defiant with methodologies that centralize thinking and take it from the developers
  • make sure it is clear for everyone that change has a chance of success if failure is accepted.
Last but not least for creativity (as a response to change) to flourish, "Peopleware" reminds us that a dose of rebellion and chaos is necessary.