Book Review: Agile Development & Business Goals 60
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.
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.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. |
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.
Somewhere, over the rainbow... (Score:5, Insightful)
Theoretically, Agile sounds nice enough. And I don't know if it's a sign that after years of getting by on good looks I'm starting to understand software development, or that my mind has turned into mush, that when I hear or read about Agile, I think I can actually identify applicable concepts as opposed to it being a clump of jargon.
That being said, is anyone living actually living and working in this colorful Agile world? Cause from where I sit, it's all sepia tones.
My first exposure to (what turned out to be) Agile was on a project scheduled for about 9 months that was stretching out to 18. Not the worst boondoggle in history. A new manager was brought in and immediately instituted a daily 9 AM meeting. I know now this is a "daily scrum." I also now know a "daily scrum" should be 15 minutes of updates, not 2 hours of back-and-forth done without the stakeholders who hold the missing piece information and the authority to make decisions.
That first meeting of the day was followed by meetings with smaller groups discussing the issues raised during the previous meeting. Then we'd break for lunch.
After lunch, I'd have a meeting or two, with perhaps 30 to 60 minutes of 'free time' to do actual work. At the time I was an 'internal consultant'--an employee working for another group on loan for this project, so I still had some responsibilities to my home group.
Then we'd end the day with a quick meeting of what was done today and what's the target for tomorrow. Well, what was done today is I attended a series of meetings. What's on the agenda for tomorrow is more of the same. (And by quick meeting, I mean about an hour before folks started making excuses to leave.)
I understand the idea behind having many short meetings throughout the development process. I just finished managing a 3-day project for a configured OTS application. We received a patch from the vendor on Tuesday, ran through the cycle of documentation and testing, and deployed to prod Thursday night. During that sprint I was meeting every few hours.
But that's a project that lived its life in one week. For a project even as short as 6-weeks, daily meetings are too much. It's baby-sitting. If your developers can't make it through one day (or aren't trusted to make it through one day) without meeting, something is seriously wrong.
And that 6 week cycle, how can development be responsive to business at that pace? My business can't pick its nose in 6 weeks. If I had a report with all the data field requirements locked down, my business couldn't decide on the report layout in 6 weeks. (I have, and they couldn't.)
And they want everything at the same time. My customers would love new features rolling out every 6 weeks. But they'd want EVERY new feature in 6 weeks. Wait 12 weeks for a change? But that's forever! My team has managed to get on a generally regular schedule of releases every 3 to 4 months, but that includes about 6 weeks of taking the business's 3 years worth of requests and paring it down to 3 months of work.
For that age old questions, "How can I build the exact software I need as quickly and efficiently as possible," is that really the question we fight with every day? How many developers are really working on that cutting edge, attempting to solve complex problems with precise solutions?
Any how many developers are reimplementing the wheel and just trying to get the business customer to decide what color it should be? I can build the software. The question I need answered is, "What is the exact software I (or my customers) need?"