Many of us have have heard about CMM for Software (now replced by CMMi), but few of us know much about TSP or its cousin PSP. I came across PSP and TSP when reading "Balancing Agility and Discipline; A guide for the perplexed" by Richard Turner and Barry Boehm, investigating the differerces in approach of Agile/XP and SEI approaches to project managament.
TSP (as I understand it) is a project model where the planning is separated into layers; with the top layers being the domain of management (e.g. what capabilities are deliverred in which order) and the doing work of the developer (and similar level) team is by the people who do the work.
Maybe it's the crossroads of the engineering and craft models of software development. More on TSP later. Right now I want to refer you to the article by Mr Humphreys.
Back in 2005, in Crosstalk, (thanks Glen) Watts Humphries addressed twelve questions around why large software projects fail and what needs to be done about it. The article is a lead in to TSP as a solution to the challenges of large projects, and software projects in particular. Go read the article and you'll recognise the themes.
- Are All Large Software Projects Unmanageable?
- Why Are Large Software Projects Hard to Manage?
- Why Is Autocratic Management Ineffective for Software?
- Why Is Management Visibility a Problem for Software?
- Why Can't Managers Just Ask the Developers?
- Why Do Planned Projects Fail?
- Why Not Just Insist on Detailed Plans?
- Why Not Tell the Developers to Plan Their Work?
- How Can We Get Developers to Make Good Plans?
- How Can Management Trust Developers to Make Plans?
- What Are the Risks of Changing?
- What Has Been the Experience So Far?