Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

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.
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.


This discussion has been archived. No new comments can be posted.

Book Review: Agile Development & Business Goals

Comments Filter:
  • I'm really more of an idea rat [dilbert.com].

  • by Frosty Piss ( 770223 ) * on Friday April 22, 2011 @02:14PM (#35908468)
    I'll bet this book talks a lot about "The Cloud"...
  • by fortapocalypse ( 1231686 ) on Friday April 22, 2011 @02:19PM (#35908514)
    Just write code that works, damnit.
    • And how many times have you acheived this on the first try in complexe projects without going over budget? The fact that where I work (in the top 5 game studio in the world) we use agile and it works, says a lot towards the agile methodology. But I will agree that to make it work you need a team that understands it and actually does it. If the team acheives this, then it really is beneficial.
      • I think Agile is useful for shops that develop new software with internal requirements (dictated by their own internal marketing, the artists or even the programmers) and when the objective is the software experience per se... but (in general terms) is inconvenient for standard business software where you must satisfy (or comply) external/client's business, political and contractual requirements, and where the software exists basically to help/control some other core operation...

    • Code is a commodity.
    • I noticed one of the questions above:
            3) Lend itself to a description so simple that everyone in the company can understand it?
      I don't even understand what "Align software development with business needs" means in the first question. One big problem with Agile to me is that it's so chock full of either business jargon or Agile jargon that no one outside of the cult can understand it. Why can't people talk normally in business anymore, with proper English syntax?

  • I think this wheel has been done over and over again. Pretty much just rearranging the bureaucracy around the process.

  • by Anonymous Coward

    And Math is the loser.
    I've always suspected that there was something about Agile that didn't add up. It's the numbers. Releasing 3 times per quarter on a 6 week cycle???

    "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."

  • Which, where I work, everyone just goes around anyway. I've been working on a project for three weeks, and we are almost done. It got approved yesterday.

    • by guruevi ( 827432 )

      I have the same feeling about the agile (or any other scrum-based process). It's great for large teams where there are lots of code monkeys that haven't learned to write proper code yet (such as most video games and large software suites these days) but for smaller teams that actually need to deliver a fully working product (in contrast to the company needing to deliver a fully working product) it's much better to cut the overhead and boring meetings, compensate them properly and just rely on the impromptu

      • My two week projects take two months, and my two month projects take two weeks, and the two year projects are on track. Sorry, widgets in the field are catching fire and the FDA/SEC/ATF are investigating so I haven't had time to update your docs yet.

  • by Anonymous Coward

    The book's approach is flawed in one of its fundamental premises: that the Business side of the enterprise really knows what product it wants developed, with the right set of features specified clearly enough that a development team can have a chance of providing a (series of) solution(s). In almost 25 years of doing software, in a half dozen different business arenas (HCI, transportation logistics, telecom apps, internet security appliances, etc.), I have never seen a business team that could do that; most

    • by hoppo ( 254995 )

      The only technical knowledge a product manager should need is in that of the problem domain of the product. The question is simple... "what do you want this to do, and what is the business value of it?"

      If the business cannot accurately portray the answer to that question, and/or the team cannot or will not understand the message it is getting from the business, then a problem has been uncovered. It should be solved (and it can be), not wallpapered over.

      • by xelah ( 176252 )
        Can it ever be so simple? Obviously the product manager has to know the cost of adding things to his product, but software (and presumably almost anything else) is more complicated than 'the cost of x is y'. Different functionality is interdependent. Adopting one architecture may make some things easier and rule out others. Taking the product in one direction may inhibit it from doing things in another area, either at a technical level or a product level (everything from UIs containing too much to the marke
  • by mcmonkey ( 96054 ) on Friday April 22, 2011 @03:12PM (#35908950) Homepage

    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?"

    • We do (major game studio). Daily meetings should never take more than 15-20 minutes, even if the stakeholders are present and these dailies are only once a day. Our iterations vary, between 1, 2 or 3 weeks, depending on the projects and team members available. Iteration velocities, task estimations, anything agile related (retro meetings at the end of iterations, scrum, plannings, etc) is done and everything works great. We deliver more items for the stakeholders (and 95% on time), so they can play with the
    • Ugh, daily 9am meetings... Isn't there a Geneva convention against that?

  • Thirty-five years after Brooks, we still don't have the answer.

    No, we have an answer : there is no answer !!!

    For a small percent of teams, waterfall works. And for the remaining teams, agile could work.
    In all cases, you need that people believe in the way they work. If they have doubts, the project will fail.

    People who think that Agile is a method are wrong.
    Agile is just a way to help the teams find the way they can work the most efficiently.

  • I believe the subject of incentives in software development have been proved to be harmful for a development team for a long time. By introducing an incentive pay scheme where a team can get more money based on performance will have disastrous effect on team morale and cause wedges between team members. Not only that but you're now encouraging the dev team members to fudge the system so they can receive extra pay and avoid looking bad. Both of these topics have been covered pretty thoroughly by Joel Spols
  • This is a cruddy review, and I suspect that the book is cruddy, as well. (1) A review posted anonymously smells bad. How can we be sure this is not the author/publisher? Etc. (2) Usually taking any discipline and hammering into being more "aligned with business" wrecks it. (3) Math doesn't add up. "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 t

  • All these Agile techniques are fundamentally based on the assumption the work can be broken down into smaller and smaller units, and these small work units can be completed by any available resource. When this assumption is valid, Agile can work. Some simple web projects, data base projects and GUI projects come to my mind. Agile has proven to be enormously successful in production tooling and manufacturing. (Not the IT of manufacturing, the actual nuts and bolts assembly of cars etc).

    But when the work i

    • I agree with your sentiment.

      I'll veer off into the woods a bit. At my company, we recently switched to scrum and it gives clear visibility into who is adding all the extra, unnecessary work and scope creep that comes with people not quite doing what they are supposed to be doing. What I really like is that it also gives developers a tool to push back with when they are asked to switch contexts, re-prioritize what they are doing or take on new work via scope creep.

      Team structure seems to play a larger part

  • Tell me what to do and I'll do it. Don't scope out 2 weeks worth of work for each member of the team, knowing that since all tasks take longer than expected, each member either has to work 50 to 60 hours a week, or come up with an excuse why the work didn't get done. No change to existing code is trivial. There are always surprises. You end up with 10 people in every meeting justifying why their work took longer than expected. That's causes stress and lowers morale.

The wages of sin are high but you get your money's worth.