We interrupt this regularly scheduled newsletter to bring you breaking news from the agile front—Addison-Wesley's recent release of three new agile tomes: Barry Boehm and Richard Turner's Balancing Agility and Discipline, Mary and Tom Poppendieck's Lean Software Developmentand Robert Martin's UML for Java Programmers.

May 06, 2004
URL:http://www.drdobbs.com/leading-edge-agile-books/184415817

In This Issue:
-- Leading-Edge Agile Books
-- News and Views from the AM Mailing List
-- Hot Links

We interrupt this regularly scheduled newsletter to bring you breaking news from the agile front -- Addison-Wesley's recent release of three new agile tomes: Barry Boehm and Richard Turner's Balancing Agility and Discipline, Mary and Tom Poppendieck's Lean Software Developmentand Robert Martin's UML for Java Programmers.

--Balancing Agility and Discipline
All methodologies aren't appropriate for all projects, and Barry Boehm and Richard Turner's book takes a good look at when you should choose an agile approach, and when you shouldn't. While Boehm and Turner provide a good comparison of agile and traditional approaches -- which they refer to as "plan-driven" -- one of the book's most important lessons comes from two case studies in Chapter 4. Here, the authors examine both an agile project that used traditional approaches to scale the methodology and a traditional project that employed agile approaches to streamline the effort, demonstrating that agile and traditional approaches are not mutually exclusive. They can, in fact, be combined and tailored to meet your exact situation. But Chapter 5 is worth the cost of the book alone. Boehm and Turner present a risk-based methodology selection process that lets you evaluate your project's risk profile and tailor your approach based on various factors -- such as the certainty of your requirements and the complexity of your environment.

Finally, the book ends with six important conclusions:

1. There is no agile or plan-driven silver bullet.
2. Agile and plan-driven methods each have their own home grounds.
3. Future projects will need both agility and discipline.
4. Balanced agility-discipline methods are emerging.
5. Build your method up; don't tailor it down.
6. Focus less on methods and more on people, values, communication
and expectations management.

--Lean Software Development
Mary and Tom Poppendieck's Lean Software Development describes seven fundamental principles adapted from lean manufacturing for effective software development. According to the Poppendiecks, you should first seek to "eliminate waste": Anything that does not add value for the customer.

Second, "amplify learning." In software development, quality should be based on perceived integrity; the system should continue to solve the problem in an effective manner, even in the face of changing needs or a changing environment. Therefore, you must learn what those needs are and fulfill them effectively. Seeking feedback and taking an incremental approach are useful techniques, as is employing a set-based approach that explores several alternative solutions, merging the best possible features from each for a final solution.

Third, "decide as late as possible." According to Lean Software Development, the most costly mistakes are made when an important issue has been forgotten or ignored in the early days of a project, and the easiest way to make that mistake is to drill down into detail too soon. Instead, it's best to survey the landscape and delay detailed decisions as long as possible.

Their fourth principle is to "deliver as fast as possible." Showing your customers interim, working deliverables is desirable because they can see what they're getting and provide you with essential feedback that will steer you to success. At times, this principle may conflict with the third one, and that's okay -- you need to find the appropriate balance for each individual situation.

Fifth, you should "empower the team," so that it is accountable for its success.

The sixth principle instructs you to "build in integrity." The Poppendiecks discuss two forms of this vital quality: Perceived integrity means that the product's totality achieves a balance of function, usability, reliability and economy that delights customers; conceptual integrity means that the system's central concepts work together as a smooth, cohesive whole. Without such integrity, you may be able to deliver your system on time and on budget, but you'll fail because it will be rejected by its user base.

Finally, the Poppendiecks believe you should "see the whole." A system is not just the sum of its parts; it is the product of their interactions.

I really enjoyed this well-written book; its solid, real-world advice makes it a must-read for anyone interested in agile software development.

--UML for Java Programmers
In UML for Java Programmers, Bob Martin lays out the fundamentals of the Unified Modeling Language (UML) in terms that Java developers can understand. Martin focuses on UML class diagrams, sequence diagrams and use cases; although he also touches on other artifacts such as collaboration diagrams (now called communication diagrams in UML 2) and state diagrams (now called state-machine diagrams). UML for Java Programmers also contains an overview of several design principles, including the open-closed principle and the interface- segregation principle (familiar ground for anyone who's perused the author's other books). In many ways, the book's modeling portions represent the level of maturity that we should see (but rarely do) in other Java programming books. It's refreshing to see a book that connects modeling and coding together as well as this one does.

One of the book's most useful segments, Chapter 7, explores dX, a collection of practices for effective development, including pair programming, working in iterations, developing spike solutions to explore technologies, unit testing, refactoring, estimating and tracking your team's velocity. A meld of Extreme Programming (XP) and the Rational Unified Process (RUP), dX may be a viable option for teams that seek more structure than XP provides, but don't want the overhead typically found in many RUP instantiations.

The book's two case studies are a welcome bonus: Both the coffee maker and the remote service wrapping Martin's SMC compiler (download it at http://www.objectmentor.com) show models and code, valuable resources from which all developers can learn.

Read, Read, Read
I can't say this enough -- successful software professionals read. A lot.

>>News and Views from the AM Mailing List

Hacking and Refactoring
Eric Raymond, best known for his writings about open source, recently posted some thoughts about agile software development techniques in an essay entitled "Hacking and Refactoring." Members on this list discussed Raymond's thought-provoking essay, generally agreeing with his views.

UML Certification Program
In mid-August, the OMG released a beta version of a new UML certification program, in order to run a group of people through the test before it's finalized later this autumn. Thoughts regarding UML certification were mixed on the mailing list, ranging from "it isn't going to prove anything" to "it's about time we started certifying people." A couple of people who took the test reported that most of the questions focused on the differences between UML 1.4 and 2.0.

Planning Agile Projects
A new poster was struggling with following an agile development approach in an organization that required a start-to-finish project plan. List members advised him to follow Extreme Programming (XP)'s planning game, or something similar, and to first write "fuzzy requirements" that focus on system capabilities instead of exact features to allow for changing requirements. An example of a fuzzy requirement is "support wild-card search of customers" versus the defined requirement of "search for customers based on first name, last name, telephone number and address."

>>Hot Links

The Agile Alliance home page is the best starting point for anyone interested in learning more about agile software development.
http://www.agilealliance.org

Find the Agile Modeling Mailing List at
http://www.agilemodeling.com/feedback.htm

Agile Modeling training resources are overviewed at
http://www.agilemodeling.com/training.htm

The Agile Models Distilled page leads to summary pages describing a wide range of model types, including all 13 of the UML artifacts.
http://www.agilemodeling.com/artifacts/index.htm

Find Craig Larman's Agile & Iterative Development: A Manager's Guide (Addison-Wesley 2003) at
http://www.amazon.com/exec/obidos/ASIN/0131111558/ambysoftinc

Check out Barry Boehm and Richard Turner's Balancing Agility and Discipline: A Guide for the Perplexed (Addison-Wesley, 2003) at
http://www.amazon.com/exec/obidos/ASIN/0321186125/ambysoftinc

Check out Eric Raymond's Hacking and Refactoring blog entry at
http://www.artima.com/weblogs/viewpost.jsp?thread=5342

Find Mary and Tom Poppendieck's Lean Software Development: An Agile Toolkit (Addison-Wesley, 2003) at
http://www.amazon.com/exec/obidos/ASIN/0321150783/ambysoftinc

The Object Management Group's UML Certification Beta Test can be found at
http://www.omg.org/uml-certification/beta-test.htm

Check out Robert Martin's UML for Java Programmers (Addison-Wesley, 2003) at
http://www.amazon.com/exec/obidos/ASIN/0131428489/ambysoftinc

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.