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.
Sounds good, go do it. (Score:2)
I'm really more of an idea rat [dilbert.com].
Buzz words... (Score:3, Funny)
Re: (Score:1)
Re: (Score:3)
Agile Android Development-Framework Development in the Cloud
I'm so sick of the word "Agile" (Score:3, Informative)
Re: (Score:1)
Re: (Score:2)
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...
Re: (Score:3)
In the real world, we call that a "Requirements Document". It's handy to have, just in case you can't finish and someone else has to.
Re: (Score:2)
In the real world, we call that a "Requirements Document". It's handy to have, just in case you can't finish and someone else has to.
As a software engineer, we call that a "list of half-baked ideas, ill-conceived notions, and incorrect assumptions that neglect serious side effects and consequences of the decisions it represents." Instead of "trying to make the document better", Agile recognizes that the document will never be perfect. Agile instead says "hey, you, Business Stakeholder, come sit with us so that when we run into one of these poorly-thought-out notions we can ask you what you really meant for us to do."
Re: (Score:2)
In the real world, the Requirements Document is what you point to when the consultant hired by the business stakeholder to do that contradicts what the Requirements Document says about the 9/10ths of the project you've already finished.
Yes, I get the concept of working without a net. But when business gets involved, there is always the nonzero probability that that lawyers and liability suits come out. Lack of documentation is how you lose those cases.
Re: (Score:2)
What you point out is that not everything works the same in every environment. Not everything falls into a neat Agile model, though some projects do. Your mileage is very likely to vary with Agile, but there's something of value it it for almost everyone.
Re: (Score:1)
They WOULD be handy to have if most requirements documents weren't garbage and near useless. This is assuming that your customer even knows what they want and can give clear requirements.
Re: (Score:2)
it usually helps not to let the customer write the requirements. that's why you interview the customer to define use cases, and then let him review and approve the requirements you develop from those.
Re: (Score:1)
I never said you let the customer write the requirements.
that's why you interview the customer to define use cases, and then let him review and approve the requirements you develop from those.
As I said, most customers don't even know what they want to be able to define clear use cases.
Re: (Score:2)
If that is the case, then you have no worries, because you're developing for a hypothetical market beyond the person ordering the product from you.
And you need to make sure they understand that, so they will pay you and not complain when the thing you develop doesn't please them, and so they are cognizant that they don't own it.
Re: (Score:1)
Re: (Score:2)
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?
Re-inventing (Score:1)
I think this wheel has been done over and over again. Pretty much just rearranging the bureaucracy around the process.
Agile and Reality meet in a fearsome clash (Score:1)
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."
Re: (Score:2)
Read slashdot sometime s/Open/Agile
Just more process (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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.
Business Core? (Score:1)
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
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
In a word... no.
Releasing code in short cycles is not a license to produce trash. An effective Agile team needs to be committed to the ideal of shipping bug-free software, and also provide itself the means to achieve that ideal. Is everything going to be perfect, at any point in time? No. But that does not mean we should not strive for it.
Agile often gets a bad rap because there are so many teams that practice Agile-in-name-only. At a firm where I once worked, I had a CIO claim that Agile was "nothing mor
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?"
Re: (Score:2)
Just high on life :)
Re: (Score:1)
Apparently you haven't been there. Yet. A project that agile can't fix. Some projects or even finely detailed requirements are so set in concrete and time that the only realistically viable business plan is to milk it until dead. No methodology will fix it in an economically viable way.
Don't get me wrong. It can be fixed, but it will cost and the business will not pay for more than patching and shipping. A hundred man years of code and careful tweaks. How to save a huge 500 year old tree that has bee
Re: (Score:1)
Re: (Score:2)
Ugh, daily 9am meetings... Isn't there a Geneva convention against that?
What ? (Score:2)
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.
Hey, lets incentivize the devs to game the system. (Score:1)
Not a Great Review (Score:2)
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
Agile is only for production, not R&D (Score:2)
But when the work i
Re: (Score:2)
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
You want efficiency? (Score:1)
Re: (Score:2)
THIS!!!
Been there, done that, don't give a fuck about the t-shirt.