Test-Driven Management

How does a Project Community learn whether its project work is successful? The same way programmers learn whether their code works: tests.

1 million song downloads = $1 million for Apple. After 1 week in production, the new service passed Apple's management test. Project green bar!

Test-driven management directs the specification of management tests. A management test is a statement that indicates a measurable, time-limited goal, framed in a binary manner: We either achieve the management test or we fail. Good management tests are SMART: Specific, Measurable, Achievable, Relevant and Time-Based.

Management tests are statements about the world external to the project, treating the project as a boundary of responsibility and authority. They avoid specifying ways in which external effects (that is, things that occur outside the boundary of the project and the software) should be achieved. In other words, good management tests set a destination, but don’t specify how to get there.

Management tests are specified using spoken language, not software, and must be measurable and undebatable. The measure can be a hard number (50 organizations will have signed up to use our software by December 31st) or a perception number (by project end, survey of customers’ happiness shows a 20 percent increase on a scale of 1 to 10).

Management tests provide an excellent way for a Project Community to understand what unites them. This echoes Tom DeMarco and Timothy Lister’s observation that “The purpose of a team is not goal attainment, but goal alignment.” (Peopleware, Dorset House, 1999, second ed.). Management tests create goal alignment by delineating how and when success will be measured, enabling individuals to understand the effects of their own actions.

Management tests complement an XP project’s unit tests and storytests by adding a test layer around the project itself. While unit tests assert that small units of code meet programmer expectations, and storytests assert that system features meet customer expectations, management tests assert that organizational returns on investment meet management expectations.

Management tests should never state what system features must be completed by a given date, for that’s the job of Release Planning. The tests should also not create an environment in which people live in fear of their tests. Management tests are meant to form connective tissue within a Project Community, which implies that people must be comfortable in their willingness to commit to the achievement of the tests. It’s therefore best for a Project Community to formalize management tests with business managers prior to embarking upon Release Planning.

Management tests are part of a Project Charter. The tests are assessed at regular intervals, such as the end of each iteration. Tests may be updated or deleted as a Project Community learns whether its tests are helping drive it towards important organizational objectives. Management tests come in two flavors: external and internal.

External management tests are focused on the success of the host organization, measurable outside the project and software boundary, and critical to the organization’s Gold Owners.

Internal management tests are focused on the success of the development organization, measured at or within the project boundary, and critical only to development managers.

Further Reading