- 1.1 Software Crisis
- 1.2 People Impact on Productivity
- 1.3 Agile Contributions to Development Productivity
- 1.4 Magic Bullets
- 1.5 Development Constraints
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.3 Agile Contributions to Development Productivity
In 1975 a two-person programming team experiment applied the triad software development model to the implementation of a real-time software system executive. The process followed was a modified waterfall approach replacing the traditional programmer with a two-person team using a single workstation; one programmer “driving” and the second programmer “observing, reviewing, or navigating.” The navigator is not an idle participant. In a military sense, the navigator reviews the implementation in real time and focuses on the “strategic” direction of the work by recommending ideas for improvements and pointing out potential problems to address for the future. The driver focuses on the “tactical” aspects of completing the current task, using the navigator as a safety net and guide. (The details of the experiment are described in Chapter 5.)
This team approach became known as pair programming several years later. The focus of the experiment was the impact of tight communications and modern management techniques (not processes) on software development productivity. The very positive results of the experiment led to the Software Effectiveness Formula discussed in Chapter 2, and it led to the definition of the development organization capability model (Chapter 6) used in software effort and schedule estimation tools today.
Pair programming is considered to be an Agile software development technique even though this technique is often used in a traditional waterfall development approach. The productivity gains from pair programming are very beneficial in either approach.
Agile software development in general includes a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.
Incremental software development has existed throughout the history of software. It existed before the introduction of any formal development approaches. I have heard some old-timers refer to it as “programming when it was real programming.” Agile software development methods evolved in the mid-1990s as a clear alternative to the formal waterfall development approaches of the 1970s.
Agile development promotes adaptive planning, evolutionary development, and delivery, and it encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen tight interactions throughout the development cycle.
I am not going to take sides in the continuing debate about the merits of either the formal waterfall approaches (including evolutionary spiral development), or the iterative Agile approaches to development and delivery, or put myself somewhere in between. In terms of improving software development productivity the Agile development methods offer two clear benefits up front:
- The use of software development teams, and
- The effective use of communications.
Both of these benefits are congruent with the attributes of the Effectiveness Formula mentioned earlier. Chapter 2 will be devoted to the implications of this formula.
It is appropriate here to consider the impact of the two benefits. Alistair Cockburn28 uses a term called virtual teams in his book discussing Agile software development. His definition of virtual does not include sitting together. In the traditional process world, all teams are virtual; that is, there is no requirement for co-located teams or communications. Of course virtual team members do not have to sit together, so we can ignore the fact that most team members are isolated in individual boxes. Boxes are communications barriers. Productivity is related to the speed of development, or as Cockburn puts it, the speed of development is directly related to the time and energy cost per idea transfer. As the distance between the team members increases, so does the cost per transfer.
Extending the cost-per-idea transfer idea to development decisions, the time and energy cost per decision also affects the productivity of the project. The separation between the manager and the source (the discoverer of the problem) directly impacts the project. The time and cost to adjust the project to the decision is also important in productivity.