Review: Peopleware, Productive Projects and Teams
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 othersOn 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
Teams and motivationsSo 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.
Considering 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 managementNow 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.