Mark A. Hart
Mark A. Hart, NPDP, Visions Launch Editor, Founder of OpLaunch ( mark_hart@oplaunch.com)
What do you do when your launch date is approaching and there are unexpected obstacles? What if you have options to enlist more resources? This article explores the implications of adding resources and minimizing risks.
Alistair Cockburn states, “Software development is a series
of goal-directed, resource-limited, cooperative games of
invention and communication. The primary goal of each
game is the production and deployment of a software system;
the residue of the game is a
set of markers to assist the
players of the next game.”1
Cockburn (pronounced
Coburn) describes himself
as “project witchdoctor
and IT strategist.” He is
also a coauthor of the Agile
Development Manifesto.2
Cockburn’s insight ap-
plies to new product devel-
opment (NPD). It provides
an approach to develop products that are validated by abundant sales at launch. It provides guidance on how to select the appropriate development resources. It embraces NPD concepts such as Product Lifecycle Management and system-level training to improve contributors’ skills for the next NPD effort. Brooks’ Law provides another important insight.
“According to...Abdel-Hamid and Madnick... the later in the project that the additional resources are added, the higher the potential for problems.”
Summary of Brooks’ Law
Frederick P. Brooks, Jr. is a software engineer, computer scientist, and the author of the highly influential book, The Mythical Man-Month, which was first published in 1975.3 An oversimplified explanation of Brooks’ Law is “adding manpower to a late software project makes it later.” Brooks’ Law provides an appropriate warning for managers of software projects that are behind schedule.
Brooks cites learning curve factors and communication factors as the primary reasons for the additional strain on software projects that are likely to cause them to fall further behind schedule. For example, training engineers new to the project diverts resources and diminishes the productivity of the established staff. Code produced by engineers new to the project is more likely to require rework because these engineers make errors consistent with their neophyte status. Communication overhead increases as more contributors are added to the project. According to the model developed by Abdel-Hamid and Madnick in the 1991 book Software Project Dynamics: An Integrated Approach that is described by Brooks, the later in the project that the additional resources are added, the higher the potential for problems. 4
Sometimes, Brooks’ Law is cited inappropriately as an argument for not adding resources to an understaffed project. In addition, Brooks’ Law does not apply directly to contributors that perform tasks that can be easily partitioned and isolated—those tasks that do not have a significant learning curve and require minimal communication.
Brooks’ Law and new product development
In NPD, an intrinsic aspect of preparing for product launch is that resources are added late in development. Therefore, the impact of Brooks’ Law may be amplified while preparing for launch. Problems that can occur due to the late addition of resources or limited communication include the following examples:
• Because of terminology differences, communication between disparate disciplines (such as engineering and public relations) can be difficult.
• Because contributors are likely to be geographically dispersed, there will be multiple channels of communication.
• Since team members do often not have the same managers, there are additional learning curve and communication factors.
• Since the preparation for a successful new product launch requires contributions from many disciplines, there are additional learning curve factors—outside of traditional production—required to harmonize launch goals. Common conflicts include the sales organization requesting additional product features while engineering considers eliminating planned features in order to meet the launch deadlines.
Brooks’ Law impacts launch strategy decisions. For a given obstacle, should resources be added? Or should the team make other adjustments to overcome the problem? Using a concept from martial arts can be helpful as a launch strategy is developed.
Shu, Ha, and Ri levels of mastery
Shuhari is a martial arts concept that Cockburn and others have popularized to provide software development insights. When differences in the level of mastery among team members are considered, misunderstandings are minimized. Shuhari concepts can be used in NPD to reveal insights about learning curves and to facilitate communication. This applies to intradisciplinary and interdisciplinary situations. It applies to both individual contributors and their managers, as seen in Exhibit 1.
From a discipline specific perspective, a Shu-level contributor should be encouraged to follow templates and adopt a predefined
References:
Archives