Agile Development with ICONIX Process: People, Process, and Pragmatism - page 16

Summary

Taking an agile approach to your project does not have to mean abandoning up-front requirements gathering or up-front architecture and design. Often, spending the time to get the design right, based on what the customer really wants, can actually increase a project’s agility.

We aren’t suggesting that, taking this approach, requirements won’t change later on: they will. However, the level of “requirements churn” should be much lower, and what changes there are will have a lower probability of forcing a big, costly, high-risk change to the architecture.

The most visible (and probably the most often cited) reason for project failure is lack of effective user involvement, which often results in unstable requirements. One approach to fix this problem is to make the project as malleable (or agile) to the forces of change as possible. Another approach is to improve the requirements elicitation process (in other words, talk to the customer; find out what the customer really needs; use effective requirements elicitation techniques [as we describe in this book]; ask the customer hard, detailed questions; and hit the brakes if the customer doesn’t have the answers) and to model these requirements in the form of use cases.

Contrary to popular opinion, these two approaches are not mutually exclusive. In fact, combining the two approaches (traditionally seen as diametrically opposite —agile versus nonagile) should drastically reduce the risk that requirements churn places on your project.

Top 10 Practices and Values That Make a Project Agile

Here are the top 10 practices and values:

10. Tune the process as you go along.
9. Make the process low ceremony (i.e., produce just enough documentation to proceed).
8. Enhance agility through good design (with tried and trusted techniques).
7. Improve teamwork and communication.
6. Reduce exposure to the forces of change (e.g., by getting from use cases to code in the shortest time possible, and by short iterations).
5. Measure progress with working software.
4. Implement agile project management (identifying and delivering customer value).
3. Implement agile planning (use short iterations and review the plan regularly).
2. Manage change (a more controlled form of adapting to change, which is an important agile principle).
1. Aim to deliver the system that the customer wants at the end of the project, not what he thought he wanted at the start.

Chapter 2: Characteristics of a Good Software Process

Overview

How much process is enough, and how much is too much? That question has been the subject of intense debate for several years now, and the debate has been carried out most vociferously by the agile community— especially by the extreme elements within that community.

Barry Boehm described the problem graphically in his 2002 article titled “Get Ready for Agile Methods, with Care.” ^[1.] In that article, he shows the increasing costs due to both excessive planning and inadequate planning on either side of the “sweet spot” (see Figure 2-1).

image from book
Figure 2-1: Searching for the sweet spot between agility and discipline

In a more lighthearted vein, two of the authors (Doug and Mark) were thinking about this problem a couple of years prior to the publication of Boehm’s article when Mark published Doug’s “Goldilocks and the Three Software Processes” ^[2.] article in Ratio Group’s ObjectiveView magazine back in 2000. Specifically referring to RUP, XP, and ICONIX Process, “Goldilocks” makes the case that “one’s too big, the other’s too small, and the third one is just right.” We’ll let you guess for yourself which process was which (or you can download the article).

The authors of this book believe that the Agile ICONIX approach is certainly in the near vicinity of the sweet spot between plan-driven and feedback-driven processes, if not dead-center in the bull’s-eye. In the remaining chapters of this book, we describe that sweet spot both in theory and in practice (by example), although the exact sweet spot will vary among organizations and projects. But as a basis for that discussion, we’d like to first examine exactly what the components of a software process are, and then we’ll discuss trade-offs that can be made within each of these process components to help you find the appropriate level of process for your project.

^[1.] Barry Boehm, “Get Ready for Agile Methods, with Care,” IEEE Computer , January 2002, pp. 64–69.

^[2.] Doug Rosenberg and Kendall Scott, “Goldilocks and the Three Software Processes,” ObjectiveView , Issue 5, p. 35. (This article is available for download from www.iconixsw.com/Articles/Articles.html and also from www.ratio.co.uk/objectiveview.html.)