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
Contrary to popular opinion, these two approaches are not
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.
How much process is enough, and how much is too much? That question has been the subject of
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).
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
[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.)
Use Case Driven Object Modeling with UML : A Practical Approach (Addison-Wesley Object Technology Series)
User Stories Applied: For Agile Software Development
ICONIX Process Roadmaps: Step-by-step Guidance for SOA, Embedded, and Algorithm-intensive Systems
Design Driven Testing: Test Smarter, Not Harder