Book Review: Agile Development & Business Goals

An anonymous reader writes "Agile Development & Business Goals: The Six Week Solution has scrum-like elements, fairly rapid iterations, automated testing, and some other things that you have come to rely on to make your Agile methodology work. But the Six Week Solution agile process has some other things, too, that make it a very interesting take on the classic Agile approach." Read below for the rest of the AC's review.

Agile Development & Business Goals: The Six Week Solution
author	Bill Holtsnider, Tom Wheeler, George Stragand, Joseph Gee
pages	256
publisher	Morgan Kaufmann
rating	8/10
reviewer	anonymous
ISBN	978-0-12-381520-0
summary	This book serves as a distilled learning guide for managing technical resources in a manner that directly boosts your bottom line.

For a company considering going Agile, this book might be a good place to start.The book talks in detail about topics such as Test Driven Development, build server software and SAAS. It also discusses specific release schedule planning to meet sales goals, revenue formulas and cost of change graphs. In other words, both technical topics are covered in depth and detailed business topics are covered in depth. The two worlds are integrated throughout the book (and the process).The basic premise is that software should be "released" on a targeted six-week schedule. There are eight six-week cycles in a calendar year, and releasing your software three times a quarter allows the Business to plan their own cycles accordingly. And the Business does not get software with random features someone thought should be added; they get targeted software built to their specifications.

Of the many features discussed in the book, two set this process apart: You should directly align your software development with the needs of the Business. You should compensate your development team based on delivering on their commitments. (If they deliver, they get rewarded; if they don't deliver, there are consequences.) Combined with the rigors of an automated testing program the authors demand and you have a distinct approach to an old problem: "How can I build the exact software I need as quickly and efficiently as possible?"

Among other audiences, this book is perfect for management types who might not be able to spell "Agile". They don't want the details, they want their software development teams to be held accountable and produce useful results. In the intro the authors ask 10 questions: Does your software development process:

1. Align software development with business needs?
2. Compensate your development team based on delivering on their commitments?
3. Lend itself to a description so simple that everyone in the company can understand it?
4. Have both core Business and core Technical components?
5. Produce revenue-generating results that address real-world needs?
6. Tie your investment in your software development to the delivery of the software you need?
7. Account directly for Quality?
8. Hit your short term goals while -
9. Addressing your long-term goals at the same time?
10. Reward success and make tangible the effects of failure?

Some of the points are standard Agile fare with small or insignificant twists. (How many times have you read: "A successful software project needs to build the right software, build the software right."?) And there are other places where the "Please Rename My Old Waterfall SDLC to Agile" button has been pressed.

But then there are the variances. The authors are pretty consistent throughout the book of detailing the similarities and differences between their approach and other Agile approaches. In a summary paragraph (again in the intro), they write: Compensation Piece: Performance is rewarded and, on the flip side, failure is penalized. Bonuses are paid (or not) every six weeks, not in some vague future annual date. No Reward for Success: Other processes do not reward success. Given that, what is the difference in classic development for the next sprint if everything was or was not delivered? No Risk in Failure: Other processes do not have to share the business' cost with the team when it fails; they just do another sprint and hope for the best again. If Cycle Fails Developers, Lose Money: Developers have a vested interest in delivering, not some vague promise of some future payoff. Other Agile Processes Iterate a Lot but Let the Boxes Fall Where They May: If a sprint fails to meet the objective, what happens? A boss stomps and shouts, everybody feels bad, and then they do the same thing all again. Other Agile Processes Do Not Align with Business: Sure there may be an on-site customer, but there is nothing to enforce exposure of what is being developed outside of the development group. With the Six Week Solution, the work done is what you really need done.

Some form of Agile software development may become (if it has not already) the standard method of software development in the future. But there is little question that the aggressive merging of the goals of the company and goals of the software teams has to happen. Too often software divisions do their own thing, pursuing targets that meet their requirements but are not aligned with those of the company as a whole.

This book details one method of bringing the aims of the Business and software development together. It is a different approach to Agile: disciplined release schedules, fully integrated automatic testing processes, specific monetary incentives, particular physical layouts. Many of these ideas are interesting to read about. And the authors have clearly lived these ideas.

This book is not for everyone – Agile purists will hate it, IMHO – but the audience for this book is people (tech and non-tech) who think about and explore the various ways to get software written. Thirty-five years after Brooks, we still don't have the answer. This book is a different take on the problem. But the rigor, unique approaches, detailed implementation techniques, practical (not theoretical) suggestions, real-world stories from the front lines of software development and internal cohesiveness – all of these suggest that the Six Week Solution book deserves a look for any organization considering implementing agile practices.

You can purchase Agile Development & Business Goals: The Six Week Solution from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.