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.

Comments

Sounds good, go do it.

[iluvcapra]

I'm really more of an idea rat.

Buzz words...

[Frosty Piss]

I'll bet this book talks a lot about "The Cloud"...

Re:Buzz words...

[Warlord88]

You mean "Agile Development" in "The Cloud". Sounds badass. Off I go to buy the book!

Re:Buzz words...

[blair1q]

Agile Android Development-Framework Development in the Cloud

I'm so sick of the word "Agile"

[fortapocalypse]

Just write code that works, damnit.

Re:I'm so sick of the word "Agile"

[PmanAce]

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.

Re:I'm so sick of the word "Agile"

[Anonymous Coward]

Agile is not about writing code. Writing code is the easy part. The hard part is communication--achieving a meeting of the minds between the specifier, the implementor, and the acceptor. That's the problem that agile is trying to solve. Any idiot can write code that "works"; the hard part is writing code that advances your business interests efficiently and effectively both in the short and longer term.

Re:I'm so sick of the word "Agile"

[blair1q]

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:I'm so sick of the word "Agile"

[plover]

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:I'm so sick of the word "Agile"

[Desler]

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:I'm so sick of the word "Agile"

[blair1q]

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:I'm so sick of the word "Agile"

[blair1q]

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:I'm so sick of the word "Agile"

[DiegoBravo]

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:I'm so sick of the word "Agile"

[Desler]

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:I'm so sick of the word "Agile"

[blair1q]

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:I'm so sick of the word "Agile"

[Anonymous Coward]

Actually, it's pretty trivial to get it just about right first time. Things go wrong when specs are changed mid-project, and for the last 20 years that has been the normal thing, the expected thing, and the killer thing. You want code that works, thrash out the spec, hand it over to developers and leave them to it. You want a mess, move the target.

Re:I'm so sick of the word "Agile"

[jdgeorge]

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:I'm so sick of the word "Agile"

[SchloggieP]

Code is a commodity.

Re:I'm so sick of the word "Agile"

[Darinbob]

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:I'm so sick of the word "Agile"

[Anonymous Coward]

Wow, so disagree with you on that.

I've worked at several companies delivering enterprise software with minimal UI elements, that have used agile methodology for development. Our teams were held accountable for deliverables to external customers. We had what effectively worked out to be 4 week deliverable cycles (2 week dev, 2 weeks testing & fixes) for most features, though some could take multiple sprints to be completed (multiple stories combined to comprise a single, complete feature).

As the head of product management, tracking progress, communicating with customers, reviewing deliverables, creating stories, etc. was critical but I was responsible for prioritizing and aligning customer requirements with over-arching company strategy and goals.

Customers were often initially wary but soon grew to like the predictability offered by the set schedule. Though not always ideal for them, they also understood that a quality product was the result of realistic dates set by the team (with me constantly questioning and pressuring for more).

Honestly, I think agile processes that put too much weight on delivering business value and driving revenue can lose site of core infrastructure change requirements. That was one thing we struggled with consistently but had a rule of thumb to allocate some % of each sprint to those tasks like that or things like refactoring major systemic functions to anticipated expansion.

But to reiterate my point, our external customers were invariably fine with the cyclical process once they saw the benefits and timely deliveries.

Re-inventing

[sycodon]

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

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

So sick of the word Agile

[Anonymous Coward]

I think "Agile" a lot like religion. Using it requires a lot of faith and blind trust.

It's hard to argue against a methodology that is named "Agile" since it would be the equivalent of branding yourself an "Un-Agile" individual.

Re:So sick of the word Agile

[iluvcapra]

Read slashdot sometime s/Open/Agile

Just more process

[desertfool]

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:Just more process

[guruevi]

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 meetings and conversations along the work table - if somebody doesn't pull their weight (lots of interrupting others, requesting unnecessary meetings, slow delivery) just cut them.

Re:Just more process

[Darinbob]

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?

[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 of the time all they have is a vague set of wishes from prospective customers. The so-called product managers try hard, but typically they don't have the technical depth to produce a workable requirements document. The fact that development was using agile methods in all these cases mattered little.

Re:Business Core?

[hoppo]

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:Business Core?

[xelah]

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 marketing ceasing to be coherent). Adopting and presenting one conceptual structure to your users and then later trying to add now-demanded features which don't fit properly makes your product difficult to understand, both for your customers and developers.

In short, good product managers need to understand the overall technical effects of their decisions because it's going to affect the future options for their product. Is it possible to do that without a conceptual-level understanding of the technology?

how does dev know if they are aligned with biz?

[Anonymous Coward]

here are some questions to ask VP and Architects

how do you know if development is aligned with the business team and what indicators do you use?

how do you achieve organizational speed? what characteristics do you look for to achieve speed?

what is the capacity of your current life cycle model and how would you scale it to double revenue in the next 12 months?

what percentage of tools has your team written to identify and resolve symptoms?

how many root cause problems were solved in the past 12 months, and what tools have been written to support root cause problem solving?

if those questions cannot be answered, who cares what the model is

Punished by rewards

[Anonymous Coward]

So, basically, this process rewards developers who sit around and milk the system by cashing in on bonuses at the cost of long-time maintainability, until the point where the software becomes too hard to maintain, whereupon they jump ship.

I have cleaned up after a few of these brain farts. It is never fun.

Re:Punished by rewards

[hoppo]

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 more than a bunch of short-term waterfalls." That is a perfect mindset to get to the end which you describe. There is a great benefit to seeing tangible results in short iterations -- it allows for rapid priority shifts in a business, and mitigates the obsolescence of particular business requirements. Plus, it is always time better spent to solve today's problems today, and defer tomorrow's problems. However, you cannot reap those benefits in a sustainable manner without a paying certain costs. Namely:

1. Diligent tests in code, and good continuous integration are an absolute must. What allows you to defer problems that are not important right now to the future is having a reliable method ensuring that you unearth issues as soon as they arise by building frequently and having a full suite of tests that can reliably tell you when a bug has been introduced. This provides the entire organization the confidence that significant architectural changes can be done in a short cycle. It also provides for better design up front -- being able to effectively test a module of code in isolation dampens the ability of that module to introduce breaking changes in other parts of the system.
2. Someone from the business with a real stake in the work product absolutely has to be involved in the process. Without an interested stakeholder, an Agile project will fail brilliantly. This person must make him- or herself available to the team throughout the project, to provide feedback, answer questions, etc. Being able to give feedback and have it actually integrated is one of the primary benefits to the business, so if a stakeholder can't be bothered to be available, the project is a worthless venture.
3. The team must be motivated to produce high quantities of high quality work. True Agile teams break down hierarchy. There should be no perceptible "reward/punishment" system. If you do not have a team whom you cannot trust without the threat of being fired, your project will fail.

Nothing is a magic pill. I've comfortably worked in both Waterfall and Agile environments. But all things being equal, I've come to prefer the latter. It just feels like a more natural way to work, and honestly any workarounds we've come up with in the past to evade the tax of heavy process have greatly resembled Agile development.

Re:Punished by rewards

[Anonymous Coward]

I agree with most of that, but the main problem is doing the above actually takes twice as long as the "hack and slash" approach, by that I mean writing proper tests. Not just tests to satisfy code coverage metrics (which I see a lot of).

Writing good code takes time, writing a 10 line function and all it's tests can take best part of an hour, nailing down all the edge cases and out of scope usages - this to me is high quality and "bug free" code actually means. - most unit/integration tests don;' really do this because of time and cost implications; initial costs and maintenance costs.

However most clients don't want software that can run in a nuclear plant or fly a plane, they want something that just works and quickly. Software houses that ship slightly more buggy code because they skipped some/all of the unit tests can win out because they charge half as much and get it out the door quicker. Of course if they don't do informal testing of actually using the software, then they are up shit creak. But most developers I know actually use the software as a user to check it works, not the "it compiles ship it" types! :). Actually *using* the software can highlight many more issues than thousands of unit tests could ever do in my experience. YMMV.

To me agile is just keeping people in the loop, customers and developers and constantly making small adjustments as you go along. The general lack of spec documents and detail design can help that process move faster and can feel good, but it also can bite you in the arse as there is no scope limit and customers can just keep making changes; which precludes a fixed cost project unless you over quote by a lot. They can also say but I want it green and you shouldn't charge me, you know this is not what they originally asked for, but there is no signed of spec/UI document so what you going to do? People can be reasonable, but when money is involved, all bets are off!

It also means new developers on the project have very little to refer to besides the code and the tests, which document what is going on (although personally I think unit tests I've seen don't make it that much clearer), but not why it is going on. The product owner should know, but things in peoples heads tend to drift and become patchy. BDD is supposed to make things better, and it looks like it could; but it's just a spec and design document by another name.

My mantra is know pretty well what it is you are trying to build and the path you are going to take building it; that way if there is a change from the customer you actually see it and understand how it affects your original understanding.

Somewhere, over the rainbow...

[mcmonkey]

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:Somewhere, over the rainbow...

[Anonymous Coward]

What the hell is this? A god-damn book? Are you STONED?

Re:Somewhere, over the rainbow...

[mcmonkey]

Just high on life :)

Re:Somewhere, over the rainbow...

[PmanAce]

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 them in their environment after every story is implemented and QA approved (once a day at least). Continuous integration and proper work methodologies are your friend.

Re:Somewhere, over the rainbow...

[Anonymous Coward]

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.

Wrong attitude.

Agile isn't something that solves any of your issues. Agile is something that gives you a structure that may enable you to find issues earlier. If you are not willing to sort through the issues, agile won't help.

The daily standup we have is less than 15 minutes for a team of five developers. The only thing we do if go through what we did, what we are going to do today, and if something has appeared that makes us need help either from each other or from a stakeholder.

Our world can get quite colorful at times, but we are always finding new issues, causing the sepia tones you are complaining about. We are actively seeking them out, though, not trying to manage them to death.

It sounds like your meetings are for the benefit of the project manager, not for you. If he really needs that amount of control over you guys, you are incompetent. If he doesn't need that kind of control over you, he is incompetent because he is wrecking your productivity because of his insecurity. I am guessing the answer is a bit of both - it usually is.

Either case, you need to quit or speak up. Agile isn't a replacement for communication. Posting about it on Slashdot is probably the most ineffective thing you can do.

Re:Somewhere, over the rainbow...

[Anonymous Coward]

pigs n chickens yo... i work for a major airline, and we pretty much suck at software development. however, even with an ancient mainframe with an equally ancient team of developers, we've done pretty well in staying on budget and schedule with 4 week iterations and some fairly strict adherence to the philosophy for the "scrums". We reduced the scrums to 3x per week, and I will say that the holiday season really jacked with our iteration duration and deliverables. All told, we're doing really well. I like my old fly-by-the-seat-of-my-pants mixture of agile and waterfall, but I tend to think pretty highly of myself and don't think that's viable for most folks so I'm willingly giving myself over to the methodology nuts for the good of my company. I think it'll work well once everyone gets used to it...depending on the type of development.

Re:Somewhere, over the rainbow...

[Anonymous Coward]

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 been dying for decades?

b b but Agile can fix anything!

Methodology du jour. Post again when you can remember the names of the last 3 or 4 in vogue that made the same promise.

Some things can't be fixed in a business viable way unless you take action early on, and then there are several methodologies that work.

---

Then there is "forced buy in". You are told that the goals can be met if you just believe in them. You just have to believe. Thank you I will find a job where religion is not forced upon me.

Re:Somewhere, over the rainbow...

[Darinbob]

Ugh, daily 9am meetings... Isn't there a Geneva convention against that?

Re:Somewhere, over the rainbow...

[Anonymous Coward]

But I'm guessing you do have a GDD (game design document) and a TDD (technical design document), which help you roadmap what you are going to build?

Kinda like a requirements and design document, but not down to the last nut and bolt, but enough to know you are building a car and not an aeroplane?

A lot of agile people I've worked with scream and shout you shouldn't have such documents because they will never be right; sure, but because they are not 100% right does not make them 100% wrong. Hell a document 80% wrong is better than knowing nothing. right?

PS: used to work in a major game studio too doing agile. In fact games companies have been doing informal agile for years. Daily/weekly meetings with customer, getting feedback as soon as a problem occurs etc.

What ?

[eulernet]

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.

Warning!

[Anonymous Coward]

If you read this book or any books of this kind, then you will never accomplish anything worth accomplishing. You will forever become lost in the dust of code donkeys and watch other's from-the-gut & dirty software shoot to the stars. It's first to market that matters, not doing it properly. Believe!

until someone comes out with

[Anonymous Coward]

...5 week Agile. Wait! you can;t possibly get a good solution in 5 weeks! That crazy talk!

Re:until someone comes out with

[Anonymous Coward]

But you can get a solid ab workout in 7 minutes!

Extreme Programming Refactored

[Anonymous Coward]

If you want to understand why this (and all) Agile methodologies are epic fail: Extreme Programming Refactored

I especially liked the part:

Q. How can you know that you don't like agile if you've never tried it?

A. Because I have cognitive dissonance.
I've never tried agile, and I've never stuck my head in a big bucket of shit.
Having seriously considered all the ramifications of doing both,
I am quite certain that I would enjoy neither agile, nor sticking my head in a big bucket of shit.

Hey, lets incentivize the devs to game the system.

[mjhiggins]

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 Spolsky on his blog. http://www.joelonsoftware.com/articles/fog0000000070.html http://www.joelonsoftware.com/items/2006/08/09.html

Not a Great Review

[dcollins]

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 to plan their own cycles accordingly." I'm pretty sure that 8/year = 2/quarter. Etc.

Re:Not a Great Review

[Anonymous Coward]

So, in their defence, they probably mean that release spans two cycles, one for beta one for release? I dunno. What I do know is that you can have all the demo's you want, the software's not done until it's done.

Agile is only for production, not R&D

[140Mandak262Jamuna]

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 involves specialists, when specialists are short in supply, the backlog is going to build on one or two team members. And the others won't be able to plunge in to give a hand even if they are not loaded. You can deploy the silver card all you want, and draw every resource from the entire company. But if the crisis is a class 3 error reported by a nuclear power plant in one of the simulations used to design the peak load on a hydraulic pump, and only two guys in the whole company have the PhD in CFD to understand the k-epsilon turbulence modeling code written ages ago.... It is not going to help. Even in the most highly venerated Toyota, uses Agile only for production tooling, not for their R&D divisions.

The only good thing I like about Agile, is that it forces the managers to actually look at the amount of resources that are available. Done correctly, it can help avoid feature creep, and reduce the amount of vaporware promised by the sales department to close the deals.

Re:Agile is only for production, not R&D

[bomb_number_20]

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 in things than I hear people talk about. Trying to find a balance between inexperienced and experienced developers is difficult, and we've pretty much always come up on the wrong side of it. One of the other fundamental imbalances I've seen (at least in our organisation) is that, within the context of a sprint, the developers are usually capable of doing everyone else's job- but the reverse is not true. I've seen this turn into situations where developers end up doing BA work, QA work and supporting production issues while trying to keep up with the development tasks that are on the board. Meanwhile, everyone else is just sort of sitting around, trying to look busy. In my opinion. this is a management failing more than anything, but it is still an imbalance.

This could just be how we apply (or misapply) things, but what I really wrestle with is the idea that ultimate accountability seems to rest with the developers, but others don't seem to be held to the same standard. Agile (I can only speak to scrum) seems to provide a framework that offers to give developers more power in exchange for more accountability- but none of the processes that give the developers what they really need to deliver on what is required seem to fall under that same framework. Scrum seems to declare things like figuring out specific requirements for what you're trying to develop outside it's scope. This means that when other areas of the business don't do what they are supposed to, the developers end up having to deal with it in some capacity. Since they are the ones on the hook, that usually means doing someone else's job. Developers are motivated by the sheer number of eyes focused on them, but where is the motivation for everyone else involved in the process? Even this book review seems to only talk about rewarding (or not) developers. There isn't mention of the other groups that feed the process.

I'd also go waaaay out on a limb and argue that misapplied agile seems to have the potential to kill vision within a company. By forcing people to spend the majority of their time thinking only about what they can deal with in terms of this (or the next) sprint, it seems long-term vision with respect to a product has the potential to get lost. In other words, if there isn't a cohesive vision of what you're trying to produce, you could be reduced to a team of developers who only have the ability to react to situations and stare at the technical debt you've accumulated by switching directions so many times. That's probably a bit melodramatic- maybe that potential exists regardless, but scrum makes it easy to see how that could happen.

Ok, enough ranting.

You want efficiency?

[BurfCurse]

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.

Re:You want efficiency?

[lennier1]

THIS!!!

Been there, done that, don't give a fuck about the t-shirt.

Not a substitute

[Anonymous Coward]

After working for 3 solid years on Agile including coaching by well known Agile snake-oil errr coaches, its clear to me that Agile is mostly hype. Nobody seems to like detailed planning and requirements anymore ever since Agile came along. So, we just continue to miss requirements and take bad design paths. That allows us to write the code once and then rewrite 5 more times after that. There is never enough time to do it right but always enough time to do it over. I never experienced 10% of the problems I now have with Agile when I was living in a waterfall world. I sure like the job security though. Plenty of code to rewrite.

Re:Not a substitute

[Anonymous Coward]

That's because agile doesn't say you don't do any detailed planning or even gather requirements. Sounds like you and the people you work with are morons for thinking so.

one insight that hit me

[Anonymous Coward]

To be honest, a lot of what I read here regarding agile looks to me that people just do *something*, label it agile - and then if things fail, attribute it to agile. I for once do SCRUM for a year now, and we are much more organized & productive today than we used to.

But that's not what I want to get at. What strikes me as odd with the proposed process is the monetary awards, and the fix release cycles. The latter is against every agile method I know, because it's waterfall all over again. Make a plan, and release on time. You can *aim* for six weeks, but making that a rule? No.

Yet much more important is that monetary awards are *not* a way to motivate people of the likes of programmers:

    http://www.youtube.com/watch?v=u6XAPnuFjJc

And thus, I'd say it's bound to fail.

www.agentstaobao.com

[Anonymous Coward]

ÐÐобÐоÐÐÐнÑоÐ