New Analyst Report Calls Agile a Scam, Says It's An Easy Out For Lazy Devs

msmoriarty writes "We recently got a copy of a new Voke analyst report on Agile, and the firm basically blasts the movement from top to bottom. Some highlights: 'The Agile movement is designed to sell services. ... Out of over 200 survey participants, we received only four detailed comments describing success with Agile.' 'Survey participants report that developers use the guise of Agile to avoid planning and to avoid creating documentation required for future maintenance. ... Be aware that the Agile movement might very well just be either a developer rebellion against unwanted tasks and schedules or just an opportunity to sell Agile services including certification and training.' So did the analysts just talk to the wrong 200 people?"

Comments

You get what you pay/wait for

[elrous0]

Beware of hucksters selling a system that will give you everything you dream of, and fast and cheap to boot.

And be even more wary of those who promise a way to outsource everything on the cheap without taking any hit on quality.

There is no secret formula. It takes hard work, time, and skill to produce quality work. That's the only trick.

Re:You get what you pay/wait for

[NReitzel]

Yep. Fast. Cheap. Good.

Pick two.

Re:You get what you pay/wait for

[Anonymous Coward]

Not to mention the fact that the provider wants you to subscribe to their services at $999 per year, and even if you opt for the 3 month (free) trial, you don't get access to the report unless you purchase a "bundle" for $199... These are troll! and the fact that Slashdot has referenced them in such a provocative article is unconscionable!

Re:You get what you pay/wait for

[multi io]

Yep. Fast. Cheap. Good.

Pick two.

I think it would be hard to be slow and cheap.

Re:You get what you pay/wait for

[Gaygirlie]

Oh, I could point you to PLENTY of examples.

Re:You get what you pay/wait for

[PPH]

Beware of hucksters selling a system that will give you everything you dream of, and fast and cheap to boot.

Already this thread has gone off topic into politics.

Re:You get what you pay/wait for

[dkleinsc]

The one thing where I think agile might help is in reducing the impact of this scenario (which I watched really happen):
1. Marketing team presents a design of a web page to the development team, saying "This is exactly what we want".
2. Development team works night and day to make that web page completely functional, conforming perfectly to marketing team's every whim (burning out developers in the process).
3. Development team presents the design to marketing team, on time. Marketing team promptly announces that they hate it, ignoring all protests involving a side-by-side comparison between what the page does and what they asked for.

With more frequent iterations, there's a chance that the difference between what the marketing team asked for and what they actually wanted will be evident sooner.

For the most part, though, the basic deal with software developers is: 1. Hire competent developers. 2. Give them clear instructions about what you need. 3. Trust that they will do their best to get what you need done as quickly as they reasonably can.

Re:You get what you pay/wait for

[jythie]

True, but this is what splits 'iterative' or 'spiral' development from 'agile'. Actually, this kinda gets into the murky waters of 'what does person X actually mean when they say 'agile'?'......

I think the real problems come from pure forms of agile, or the agile services sector. Like any technique it tends to work well when hybridized with others in order to best suit the situation, and sucks in its pure inflexible form.

Re:You get what you pay/wait for

[Ryanrule]

In software development, pick one.

Re:You get what you pay/wait for

[Jeremiah Cornelius]

What? Like rail transport? Container ships? :-)
I am the SCRUM MASTER! Don't make me PROVE it!

Re:You get what you pay/wait for

[DCheesi]

The iterative development model is really the best thing to come out of Agile, IMHO. Multiple sprint cycles allow Marketing to shift their priorities without it turning into feature creep, since they're forced to decide what to cut from each cycle. And as in your example, it allows for change feedback once they've actually used the feature. All the rest of Agile can be tossed aside, but this orderly iteration is by far the best method I've seen for dealing with Marketing requirements issues.

...So of course it's the one thing that's expressly forbidden in the new formal development process imposed by upper management :-/

Re:You get what you pay/wait for

[Briareos]

I'll take "Yep" and "Good".

What do I win?

np: School Of Seven Bells - Scavenger (Ghostory)

Re:You get what you pay/wait for

[petes_PoV]

"This is exactly what we want".

The example cited is just a textbook failure to consult properly. Every client *knows* exactly what they want - until you ask them "what about ...." in which case they'll think again, or challenge their conflicting desires: "you can't have it easy to use AND infinitely flexible". Repeat that loop until the end of time and you STILL won't get a hard set of requirements - let alone a sensible or possible set.

Every experienced designer knows that the customer always lies. They might not know they're lying (or they may well do) but they will NOT tell you the truth, simply because they don't know it yet. The job of a designer is not to write down all the wishes, hopes and dreams that exit the mouth of the client, it's to present them with a list of what's possible, what's necessary and what can be done within the constraints (time, money, skills) that exist.

In the end it doesn't matter what methodologies you use. Good, talented, motivated developers will get the job done no matter what processes or obstacles you put in their way. Lazy, stupid, demotivated or confused developers will never finish the work

Re:You get what you pay/wait for

[Anonymous Coward]

Like any technique it tends to work well when hybridized with others in order to best suit the situation, and sucks in its pure inflexible form.

I thought it was funny how well this statement applies to political and economic systems, as well.

Re:You get what you pay/wait for

[dmomo]

By planning, writing specs, and creating documentation, you are not necessarily throwing away the ability to develop in iterations.

The onus here is on Project management to translate Marketing's designs into wire frames and requirements so a prototype can be created. If Marketing cannot see through the fast version that has yet to get any bells and whistles, the issue is with Marketing or perhaps the Project Managers.

Re:You get what you pay/wait for

[MacDork]

Yes. This. The problem is marketing has no business designing software in the first place. They don't know their asses from a hole in the ground. They request UI designs that we as developers KNOW are slow, confusing, and/or doomed to fail. We tell them so, and they persist in their "vision."

Oh hai Marketings, you want a image gallery? I see your mockup. You didn't include pagination. What should that look like? Oh, Marketing doesn't *want* pagination. FAIL.

We don't let the passengers design the flight control panel. Why do we let marketing design web applications?

Re:You get what you pay/wait for

[JWSmythe]

    Well sir, I have a nice Pentium 100 to sell you. And I have a team of developers ready to do your work. For only $20, they'll do any project. Don't ask how long it will take, I'm sure we* can have something** to show you by FY2015***.

    * "we" only indicates anyone who the work may or may not have been farmed out to.
    ** "something" may only be a photocopy of the printout of your original request.
    *** FY2015 is not a promised date, it simply indicates an arbitrary date in the future.

Re:You get what you pay/wait for

[Anonymous Coward]

IT resourcing is the scam :) IT projects can be summed up in one line: If the project goes live, the vendor needs another job.

Re:You get what you pay/wait for

[dfetter]

Yep. Fast. Cheap. Good.

Pick two.

That's actually the optimistic perspective. Given skill, experience and good will, you could pick up to two. Frequently, the most you could have is one, or in sadly common cases, zero.

Re:You get what you pay/wait for

[JWSmythe]

    You outlined exactly why I won't touch development again. It doesn't matter what system you use to establish the flow. Development can make exactly what was requested, and regardless, they will want something different. The more people that are involved, the more changes will be requested, frequently in direct conflict with each other.

    At some point, someone has to give in, and as you noted in step 2, this burns out the developers. So devs quit, get fired, or gracefully move over to another project, and now there's a new team of devs to repeat the process with.

    I've gone through this with iterations of only a day or less. Programming all day and night to modify the previous weeks work to match the newly defined spec, and you still end up worse off than where you started.

Re:You get what you pay/wait for

[The Mister Purple]

I second that.

Re:You get what you pay/wait for

[biodata]

We were doing the iterative development model explicitly in the mid 90s. Do you think this model really came from something called 'Agile' or the other way round?

Re:You get what you pay/wait for

[mcmonkey]

Yep. Fast. Cheap. Good.

Pick two.

I've heard that many times before, and I have to disagree.

Where I work, we didn't pick two.

Our projects take twice as long as they should, cost three times as much as they should, and quality in the crapper.

Who says you can't have it all?

Re:You get what you pay/wait for

[macson_g]

Yep. Fast. Cheap. Good. Pick two.

My choice: Yep & Good

Re:You get what you pay/wait for

[turbidostato]

"There is no secret formula. It takes hard work, time, and skill to produce quality work. That's the only trick."

Exactly. But even then, there are ways and ways to reach to that.

"Agile" (in its various incarnations, but I'm specifically talking about Scrum) is not a project management methodology but a people expectations' management methodology. Most people have this wrong.

And it is a kind of people expectations' management methodology that leans *a lot* on giving power to the people that do the work -the pigs.

Just paying attention at the two observations above is the difference between a successful and a failed "agile" implantation:

1) "Chickens" that "forget" that agile is about empowering pigs: a lot of observations about that have already been cited here (i.e. "we do agile", which in fact means "we set your goals for each fortnight in stone and you'd better acomplish them by living in a permanent sprint or you are fired").

2) "Pigs" that are not up to the challenge: the Sturgeon's revelation works on every scenario but its results are even more wherever you depend on people more than in processes. With Scrum you are letting programers work like artisans or craftsmen (which, due our current state of the art is what they are no matter how much we'd want it to be consider an engineering); but once they are considered artisans, the difference between good and bad artisans is the more acute. And most (as in 90% of them per Sturgeon) are not up to the challenge. Here is where goes those "programmers want agile because it's the way they find to scape from whatever they don't like". It works the other way too: agile is most demanding for programmers but it increases demands for the business guys too: they forcibily need to understand what they are asking for and they won't be able to hide their responsibility pushing it towards the freakoids: *you* had the responsiblity to choose what was the best for the business and you failed; you can't hide the fact that it was *you* the one that wanted the "selling ice to the skimos" feature first.

3) And then, there are the "cargo cult guys". You find this kind very easy: they say "we are doing scrum" but then you learn that they interviewed the customer once on the kick-off meeting and they won't see him again till six months down the road (but, of course, they have their morning stand up meetings, their sprints, their cards, their pomodoros... even an internal manager -the one that sets the goals for next milestone in stone, acting as "internal customer" in lieu of the real one...).

So, just like always, you either take the work to stablish a high quality, commited, well imbricated team -and then methodologies doesn't mean so much, or you use the methodology in vogue to hide your lack of abilities and/or lack or commitment. And, just like always, it is the ones in command those that really have the greatest portion on the success of a project -and even a greater portion on its failure. But, hey, since they are in command they are in the best position too to make the successes to be theirs and the failures everybody else's.

Re:You get what you pay/wait for

[turbidostato]

"Every experienced designer knows [...] The job of a designer is not to write down all the wishes, hopes and dreams that exit the mouth of the client, it's to present them with a list of what's possible, what's necessary and what can be done within the constraints (time, money, skills) that exist."

Right.

"In the end it doesn't matter what methodologies you use."

Wrong. They may matter more or less, but they *do* matter. For instance, your approach to an "experienced designer" lacks a critical observation that the agile processes take into consideration even if the "experienced designer" forgets about it: the customer won't tell what they want because he doesn't know yet. Well, the designer won't get to what the customer really needs because he doesn't know it yet either: the iterative process with strong feedback between developers and customers with no people in the middle copes for the fact that neither the askers nor the doers know what's needed yet but by means of the strong feedback they maximize the chances to discover it on their way or, at least, to weight the highest responsibility to the ones that have the most chances and/or the most stakes to do it right (business to business and technology to techies) on a tighted loop.

So in the end: methodologies *do* matter. People *do* matter even more. Near, but not exactly the same thing you said.

Re:You get what you pay/wait for

[turbidostato]

"If Marketing cannot see through the fast version that has yet to get any bells and whistles, the issue is with Marketing or perhaps the Project Managers."

Which is a pretty good way to deflect blame but adds nothing to the odds of the project to succeed.

Any other valuable suggestion, Mr dmomo?

Re:You get what you pay/wait for

[GodfatherofSoul]

That's not what your mama said. Burn!

Re:You get what you pay/wait for

[greg1104]

Like most software methdology, iterative development dates back to the 50's. All of these "new" software approaches are just different mash-ups of existing development techniques; it's inappropriate to credit any of them with real innovation.

Re:You get what you pay/wait for

[murpup]

Your second example of "top tier talent and give them as much time as they want" is not illustrative of the rule. The rule says pick two. Your example only picks one - it picks good, but with expensive and slow. What your example should say is "if you want really kick-ass software, you need to hire top tier talent who are really expensive, and lots of them, because they are the only ones who can do it fast"

Re:You get what you pay/wait for

[Pieroxy]

You don't have it all, you have none !

Same at my place of work. I'm sharpening my resume as we speak.

Re:You get what you pay/wait for

[Guspaz]

If I want to print a large volume of material, it will take a certain amount of time. If I want to get it faster than that, I need to pay extra for rush service.

Re:You get what you pay/wait for

[Guspaz]

I have. It didn't save money, because of the enormous amount of rework involved. It was a huge disaster that thankfully put the senior management off outsourcing for good.

They didn't do it to save money anyhow, they did it because a big customer wanted a new product, and we didn't have the development resources to pull it off. They hired an Indian outsourcing firm get the extra development resources required. It was a nightmare, both for those of us on the local side of the dev team working directly with them, and for the management, whose decision came back to bite them. Even years later, we're still finding bits of facepalm sprinkled in the code of that project...

Re:You get what you pay/wait for

[Guspaz]

And if you throw enough money at the problem, you get bumped to the top of the queue, which gets you the "good and fast", but not cheap.

Re:You get what you pay/wait for

[jbolden]

He's saying $.12 / gb / mo. You are talking about one $.06 one time cost. Obviously if it were a one time fee no one would object.

Re:You get what you pay/wait for

[TheRealMindChild]

Not if you are good.

Re:You get what you pay/wait for

[AuMatar]

One good developer who already works for you doing this in his free time at work. Cheap (already paid for), slow (1 dev part time), probably high quality (good dev).

Re:You get what you pay/wait for

[KingMotley]

That depends. If he's a programmer, and his bosses are paying him well, don't expect much, and give him as much time to do it as he wants, then HE does have it all, so long as they can keep finding business.

Re:You get what you pay/wait for

[KingMotley]

As for as I'm concerned, Agile isn't a proven methodology. Not as far as being able to produce all the claims it makes for every project. In fact, I can say that it's proven to be false, time and time again.

That said, there are SOME projects that work well in an agile environment, and it works well in SOME environments using SOME teams. And on the other hand, there are SOME environments where it just doesn't fit at all, and SOME projects don't lend themselves very well to it, and SOME teams it's a hindrance.

I call that a huge success.

I call that one tool in a shed, not the golden swiss army/ginsu blade that does everything.

Companies would not use it if it did not provide benefit.

Companies use it MAINLY because they've hired program managers that are familiar with it, typically younger ones that want change. Change is good, as long as it provides a benefit. The company typically doesn't care so long as the work gets done in a reasonable amount of time.

Re:You get what you pay/wait for

[hawguy]

Agile is a proven methodology. In the old "waterfall" software industry, the famous "standard" was 7 lines of code per day per programmer.

Thanks largely to Agile methodologies, you can get up to as many as 1000 lines of code per day (though that's a bit on the high side), with even fewer bugs than the old 7-lines-per-day methods thanks in part to thorough, continuing testing being built-in to the process.

Using "waterfall" you could also get 1000 lines of code in a single day from a coder too - but whether the project is done using Agile or Waterfall, if you take the total project time (including requirements analysis, documentation, unit and system tests), the average LoC/day is much lower. And of course, LoC is completely meaningless - when using a modern library or framework a single line of code can replace what would have taken a thousand lines or code 5 or 10 years ago.

In my experience, Agile projects tend to run longer than they would have under waterfall, but the end product is usually closer to what the customer needs - few customers are willing to put in the time to spec out an entire project at the beginning (and are unwilling to freeze their business process during the project) and it takes too long to work changes through the waterfall process, but small changes can easily be rolled into the next iteration of an Agile process. (but some managers overestime the agility of Agile development and think that a major change that requires rearchitecting major pieces of the project can be incorporated into the next iteration)

Re:You get what you pay/wait for

[RealGene]

I prefer "Better, Faster, Cheaper - Pick two."

Re:You get what you pay/wait for

[KingMotley]

Probably one of the most insightful posts on the subject I've seen. Well done!

Re:You get what you pay/wait for

[next_ghost]

Development can make exactly what was requested, and regardless, they will want something different.

The main cause of this problem is that what the client wants and what he needs are two completely separate things. Pay no attention to what the client says he wants. Make him teach you the process as it is done at the moment without the software and then design the software around what you've learned. Chances are the process itself will need some serious rethinking.

Re:You get what you pay/wait for

[AVee]

Not to mention the fact that the provider wants you to subscribe to their services at $999 per year, and even if you opt for the 3 month (free) trial, you don't get access to the report unless you purchase a "bundle" for $199... These are troll! and the fact that Slashdot has referenced them in such a provocative article is unconscionable!

A report claiming Agile is just a scam to sell services will set you back $199,-. You just have to appreciate the irony there...

Re:You get what you pay/wait for

[next_ghost]

1: Upper management understand whose fault it is, and acts accordingly. In this case, consider staying with the company.

It's the management's fault because they didn't have a software analyst write the specification. Marketers are not qualified for this job.

Re:You get what you pay/wait for

[dkleinsc]

I actually wasn't on the team that had this happen to them, but it was the second situation, and I was part of an exodus that occurred over the year following that mess.

Re:You get what you pay/wait for

[Altrag]

Something slow and expensive, most likely.

Re:You get what you pay/wait for

[Anonymous Coward]

The iterative development model is really the best thing to come out of Agile, IMHO. Multiple sprint cycles allow Marketing to shift their priorities without it turning into feature creep,/

There's the problem with agile. It requires a lot of work from the stakeholders, in this case, Marketing. They don't want to be involved in each iteration. They want to give you a statement up front and get something two weeks later that looks like what they think they want. They don't want to be bothered with iterations or postmortems.

Too often agile is simply used as a way for the customer and BA to avoid their part in the development process. "We gave you a story, what else do you need?" One line describing an entire system is not a story, nor is it agile. It's lazy.

In my opinion, agile has become a way for everyone BUT the developer to be lazy. Despite which methodology you use, the developer still has to code it.

Re:You get what you pay/wait for

[Altrag]

Not really. A single programmer can usually do as good if not better a job than a team of programmers, for example. It just takes her a lot longer (the slow part.)

However, it generally won't take him as long as the multiplied rate of the team because she won't have nearly as much of the coordination overhead. So its still "cheap" (in comparison, which might not necessarily be cheap in absolute numbers.)

Plus, this quip also tends to apply to everything in life, not just software. You can find much more clear-cut examples in other areas where the time scale between "slow" and "fast" is more obvious.

Something like shipping for example. Basic mail is relatively cheap, but also relatively slow, but you can pay more to get faster service if you have more money than time. (In this case, the quality metric becomes hard to compare -- nobody wants to lose their mail regardless of how they send it.. but if you really want to play that metric as well, you can pay even more for shipping insurance and extra-detailed tracking and whatnot as well.)

Re:You get what you pay/wait for

[Jake Griffin]

The company I work for employs Agile and Scrum methodologies along with some Extreme Programming mixed in, and I would argue that we achieve all three. I am a part of a team of 6 developers and here is how I believe we achieve all three:

Fast - By only working on the highest priority items, we get the most value out as soon as possible, and are able to switch gears on a weekly basis if the company's direction changes. With a waterfall approach (the most common I think), if the plan changed halfway through, you'd have to scrap everything you've done so far and restart (or risk taking on some serious technical debt).

Cheap - Because we are only completing the highest priority items, we get the most value in the least amount of time. And less time spent means less cost. When we get down to the lower priority items, the product owner can decide on a whim that we don't really need to complete features XYZ, because what we have already completed gives us 90% of the business value for 50% of the cost.

Good - Because our development cycle is so short (1 week), we are always working on things that are fresh in our mind. Also, when we're only focused on one feature at a time, we can really make sure that feature is done right, instead of worrying about how 60 different features are going to fit together (which can lead to some serious over-development and result in more technical debt). Paired programming also helps here, because we have a sort of built in QA as we develop from the person sitting next to us.

The feedback we have received from the company is that we are a marvelous improvement over the previous team, and all six developers have been with the company for less than 2 years. The shared knowledge that is achieved through paired programming has really helped us to excel above the company's expectations. I have some references to some great Agile/Scrum coaches if anyone is interested. Hit me up at Jake{dot}Griffin{at}gmail{dot}com if you're interested.

Re:You get what you pay/wait for

[ghostdoc]

We don't let the passengers design the flight control panel. Why do we let marketing design web applications?

Partly because developers can be really bad at designing web applications too. We tend to think of how the site is constructed, not how it's used, and design nice, orderly, awkward, unfriendly interfaces.

Re:You get what you pay/wait for

[TheRealMindChild]

So, what am I supposed to do with these three wishes?

Re:You get what you pay/wait for

[Belial6]

It seems that if you opt for slow and expensive, you always end up with crap.

Re:You get what you pay/wait for

[frosty_tsm]

Yep. Fast. Cheap. Good.

Pick two.

That's actually the optimistic perspective. Given skill, experience and good will, you could pick up to two. Frequently, the most you could have is one, or in sadly common cases, zero.

I was going to say the same thing.

Re:You get what you pay/wait for

[Jane Q. Public]

"... and it works well in SOME environments using SOME teams..."

Well, of course. Did anybody here try to say that it works all the time, for everybody?

"I call that one tool in a shed, not the golden swiss army/ginsu blade that does everything."

Again, did I even imply that it did everything for everybody?

But a report like this, that appears to imply it does little for anybody, appears to be, just as I said, FUD.

"Companies use it MAINLY because they've hired program managers that are familiar with it, typically younger ones that want change. Change is good, as long as it provides a benefit. The company typically doesn't care so long as the work gets done in a reasonable amount of time."

Again: companies would not use it -- especially so often -- if it did not provide benefit. It has been around far too long to be a fad.

Re:You get what you pay/wait for

[MisterSquid]

The options you're probably thinking of are "slow", "long", and "hard".

Re:You get what you pay/wait for

[patchmaster]

Fast - If the plan changes halfway through Agile development, how does that NOT result in the same discarding of work and starting over? In my experience it's very uncommon for non-Agile projects to change so drastically halfway through that you have to scrap everything done so far. Has it happened? I'm sure it has. But I'm sure something similar has happened to Agile projects as well.

Cheap - Your conclusion is only valid if priority and value are directly related. Due to the various priorities of different departments, I've not found this to be at all the case. The marketing guys might think it's imperative and of the highest priority that the product use whatever the latest designer colors might be. Does this add value? Not in my book.

Good - I fail to see how short development time necessarily leads to "good". As far as I can see, all it does is lead to doing things in bite-sized pieces. I'm not saying that's a bad idea, but it's been my experience that on any project of real substance it can be very difficult to break everything up into chunks small enough to complete in a week (or even two). We've tried this several times at my company and have always failed. Even with a two-week cycle it was very difficult to break things up into sufficiently small pieces.

I would also suggest that non-Agile development in no way insists on you juggling 60 features at once and not submitting any of them until they're all complete.

You obviously like the Agile approach, and that's great, but some realism in the implied criticism of other approaches would also be a good thing. The non-Agile developers aren't all dunderheads who do everything in the dumbest of all possible ways.

Re:You get what you pay/wait for

[MacDork]

developers can be really bad at designing web applications

If that's the case, they aren't very good developers. I *know* 500 thumbs are going to be a ridiculous amount of bandwidth. Marketing doesn't.

We tend to think of how the site is constructed, not how it's used, and design nice, orderly, awkward, unfriendly interfaces.

That's user interface design. Which, BTW, marketing ALSO has no fscking clue about. Marketing should be doing *marketing* and that's it.

Re:You get what you pay/wait for

[dynamo]

1. Have a great idea. Let's say software, for example.
2. Working on it yourself in your off time for a year or two.
3. Really take your time to try to perfect it.
You'll understand all too well.

Re:You get what you pay/wait for

[JoeMerchant]

I don't know what the report is calling Agile, but the flavor of Agile I believe in mostly consists of development code that always works, it does not preclude documentation, planning, architecture, or rework. The only thing my brand of Agile lacks are multi-day periods where there is no new visible progress because "the code's all ripped up for rework and we won't be ready to test/demo for a few weeks." (Though, to be fair, architecture revisions can occasionally trigger one of these "no visible progress" periods.)

If you could actually get an outsource team to work in that fashion, and could get management's attention on a regular enough basis to give them feedback, it could work. In my experience, outsource teams are anything but agile, and management generally only pays attention at T-40 hours and counting for contract delivery.

Re:You get what you pay/wait for

[JoeMerchant]

Fast, Cheap and Good: you can always get one if you try for it, two takes skill, all three is a lottery win.

Re:You get what you pay/wait for

[crutchy]

I develop using the extreme methodology because it works.

The main and deciding reason why is because clients and end-users never know what they want at the beginning, which is the critical flaw in waterfall design. It's the critical flaw in waterfall design of anything (not just software), but agile couldn't really ever suit development of say a jet airliner (though companies do try). You can offer a client or end-user something that you and they think they want, but when they start using it they will ALWAYS find something wrong with it. If you can't fix what's wrong, you've already fucked up by not meeting the needs of your client, but how could you since their needs are continually evolving. The main problem with waterfall is the lack of flexibility.

You can buy some huge does-everything package (take SAP for common example) and then spend the next 10 years trying to change your company and procedures to suit how it works. On the other hand, extreme programming takes and existing system and improves it incrementally with lots of user input and allowance for changing priorities. It allows change to fit the company as opposed to forcing the company to fit it.

Those who argue the other way will always come up with seemingly good reasons for companies changing to suit packages like SAP, but at the end of the day, every company is different, and companies would only be in a position to purchase a package like SAP if they had done pretty well for themselves already and knew a thing or two about making money in their operating industries. Who is SAP to tell any successful company how to operate their business?

Agile and extreme are the future, not by design or choice, but by evolution and market force. Companies are getting sick of pigeon-holing software like SAP that doesn't work out of the box as they claim in their fancy sales presentations (amongst many and varied other false claims required to make the sale). Companies employ agile programmers to come in and fix problems created by these monstrosities (interfacing their previous working solutions into things like SAP). Waterfall programmers can whinge all they want, but they are a dying breed in their death throws and will of course say all sorts of predictable shit to get themselves out of the holes they've dug over the years. If you can't hack the agile world, go flip burgers or something.

Re:You get what you pay/wait for

[sycodon]

AT&T DSL service.

AT&T Data services (for phones).

Re:You get what you pay/wait for

[IICV]

... few customers are willing to put in the time to spec out an entire project at the beginning (and are unwilling to freeze their business process during the project) ...

Actually, even if they spec out exactly what they think they want and you implement it perfectly, on delivery you're still going to realize that 90% of the time what they said they wanted in the spec isn't what they needed.

Asking someone to spec out an application sight unseen is essentially asking them to commit the planning fallacy, except for feature estimation instead of time estimation. Humans seem to be largely incapable of making detailed plans more than a few "units" in advance, no matter whether or not those units are time, feature or cost based.

That's why Agile projects can "take longer" than equivalent Waterfall projects - if the client had somehow managed to spec out exactly what they really needed in the first place for the Waterfall project, I bet you it would have ended up taking about as long as the Agile version; the Waterfall project was only "completed" faster because nobody could foresee some of the features that would end up being required.

Further, there's a whole heck of a lot less risk with the Agile project; if some feature isn't quite what you wanted, you'll find out in a couple of weeks, not a several months.

Re:You get what you pay/wait for

[GrumpySteen]

Shipping options generally work that way. The slower the shipping method, the cheaper it is.

Re:You get what you pay/wait for

[JWSmythe]

      As I've observed from the mechanics themselves, pushing them to complete something in less time than they are comfortable with, can and will lead to errors. It could be something trivial, like forgetting to put your tire valve stem covers back on. It could also be something catastrophic, like not double checking the lug nuts were tightened down properly.

    Sure you'll get fast. You might get good, if they don't overlook something that they'd normally do because you were rushing them.

    I just fixed a friends car, who had a break fluid leak. It was discernible, he had to add brake fluid daily. The cursory check saw no problems at the wheels nor master cylinder, so they said there was nothing to worry about. They saw nothing wet, and no fluid on the ground.

    I took my time, and followed the whole system through. Half way down the frame rail, there was a pinhole leak, which only manifested when he pumped the brakes.

    Don't rush perfection, especially if your life depends on it. For a car, brakes are kind of important. For IT, it could mean that they missed a hole that could allow buffer overflows, SQL injection, or all kinds of dumb mistakes that simply shouldn't happen.

Re:You get what you pay/wait for

[hawguy]

"Using "waterfall" you could also get 1000 lines of code in a single day from a coder too..."

Repeat: the oft-quoted "average" in a large waterfall project has often been reported at 7 usable (i.e., non-comment) lines of code a day.

The average for Agile is commonly reported to be somewhere around 300 to 500 lines. That's a pretty significant difference.

I'm going to have to call bullshit on those numbers. Unless you're saying that an Agile project is bloated with unnecessary lines of code because a developer continuously rewrites code over and over. I'm sure you can find the stats to back up 7 LoC for a Waterfall project and several hundrend LoC/day for an Agile project, but I can't believe it's an apples-to-apples comparison for an equivalent project.

If those numbers were true a project that would have taken 60 months under the Waterfall methodology would take a month or two under Agile (assuming the same number of resources were assigned to the project). I haven't heard anyone claiming that a project could be completed 40 to 70 times faster under Agile.

"(but some managers overestime the agility of Agile development and think that a major change that requires rearchitecting major pieces of the project can be incorporated into the next iteration)"

I agree, but that's a problem with the manager, not with the process.

Well, sometimes the adaptability of Agile is oversold. It's not a weakness with the process, but it is sometimes presented as a magic bullet that will let a project adapt to changing requirements, and not everyone understands that a fundamental change in the requirements may require a major overhaul of the project. Whereas waterfall makes that assumption explicit - what you write down is what you're going to get.

Re:You get what you pay/wait for

[tiraid]

I think it would be hard to be slow and cheap.

I am the only software developer at the start-up I work at. Development is slow because it is only me; but it is also cheap, because it is only me. Hiring another 5 devs would increase velocity and cost.

Re:You get what you pay/wait for

[tiraid]

Yep. Fast. Cheap. Good.

Pick two.

I had a boss that just didn't get this, so I started saying it as: Slow. Expensive. Bad. Pick one.

Re:You get what you pay/wait for

[Nadaka]

In my experience, agile is great for developing internal tools. You get stuff you can use early, and it improves over time.

And much less great for developing client products. If the client is aware that the design is in flux, they will insist on changing the requirements at every possible opportunity.

Its big drain is in the amount of time required to track and manage the daily tasks and the pressure to increase the accuracy of estimates. Spending an hour a day reporting progress and estimating the time it will take to complete tomorrows tasks is an hour I can't be doing something productive.

Re:You get what you pay/wait for

[mpfife]

| In my experience, Agile projects tend to run longer than they would have under waterfall, but the end product is usually closer to what the customer needs

Great analysis - I would agree.

The other pitfall I've seen of people claiming to be 'agile' is that it's a keyword for "You're about to give your life and soul to this startup". I think a fair number of places claim to be running an Agile process, but in reality use it as a keyword for busting your hump as hard as they can. And run as fast as you can if you ever see an ad looking for someone that wants to hire you for "a fast-paced, dynamic, agile environment".

Re:You get what you pay/wait for

[patchmaster]

I don't really have a problem with Agile development techniques. I have a problem with people who preach about them with religious fervor, always trying to convince others that Agile is the one true development methodology and all others are pretenders.

It's my feeling that Agile techniques probably work well for certain situations and problems, but they don't always work in every situation. As you point out, Using Agile methodology when building a jet airplane is probably not the best way to go. Which is not to say some aspects of Agile couldn't be put to good use even with that scenario.

One thing has become clear to me from years of reading Slashdot -- there are many different development environments. Anyone who thinks the techniques used in their little corner of the development world will be universally applicable is sadly deluded. This was recently revisited in the article questioning why people are still using C. The answer is that for some problem sets C falls somewhere between adequate and best language for the job. For other problem sets C is far from the best choice.

The same applies with Agile. In some situations it works very well. In others, not so much.

Re:You get what you pay/wait for

[localman]

I'm all for rapid development, but any time you're measuring coding productivity in "lines of code" you've already lost.

Re:You get what you pay/wait for

[Assmasher]

Yes, the triangle I call it. I always find a way to bring this up once we start talking about 'possibilities.'

It's my mantra - "Fast, cheap, good - pick any two."

Cheers!

Re:You get what you pay/wait for

[Aighearach]

It's all just programming, mofo, do you speak it?

Re:You get what you pay/wait for

[turgid]

Why should the engineers take the blame for everything, even other peoples' failings?

It is everyone's responsibility to speak up when they see something that is wrong or needs fixing, but if stubborn, pig-headed PHBs and MBAs won't see the error of their ways, why should anyone else take the blame?

Everyone working on a project must take responsibility, especially those in positions of privilege and power.

Re:You get what you pay/wait for

[ghostdoc]

Depends on the skillset that you include in 'developer'. I know I suck at interface design, but I'm clearly a developer and I've been doing that successfully for 25+ years so I can't be that bad at it. I am colourblind which doesn't help things though ;)

There are people out there who specialise in interface design. In an ideal world we'd get them to design all our interfaces. Just like in an ideal world the customer would be able to describe their requirements accurately and completely, and not change them during the development project... ...sorry, had to take a breather there, nearly died laughing. Or crying, one of the two.

Re:You get what you pay/wait for

[KingMotley]

Really? Because I find that our internal tools would be a bad choice. First, for internal tools, we typically aren't trying to manage customer expectations, and we all know pretty well at the start what the tools objective is. Meeting about it daily is usually a waste of time. But then again, that's our place, yours may be different.

Re:You get what you pay/wait for

[ljw1001]

Agile is a proven methodology. In the old "waterfall" software industry, the famous "standard" was 7 lines of code per day per programmer. Thanks largely to Agile methodologies, you can get up to as many as 1000 lines of code per day (though that's a bit on the high side), with even fewer bugs than the old 7-lines-per-day methods thanks in part to thorough, continuing testing being built-in to the process. I call that a huge success.

I call that an unsubstantiated claim. Also, total nonsense.

Re:You get what you pay/wait for

[LongearedBat]

There's something I don't understand about this...

You'd think with all the talent and hard employee filtering processes, they would be pretty skilled and able developers.

So how come so many businesses have such extremely disappointing experiences with outsourcing to India?

Re:You get what you pay/wait for

[mcmonkey]

We've managed to hit the triumvirate of slow, expensive, and shoddy not through lax oversight of my work (though I am a programmer) but through out sourcing and off shoring.

Management decided to send almost all technical work outside which, even if the individual programmers make less, costs more overall due to the redundant layers of managements between us and the consulting company.

This also assures all projects run longer than needed because, while we use off the shelf software, we customize the heck of it and use it for off-label purposes so even with programers who are familiar with the software, project estimates are 3 to 4 times longer than similar projects done in house before they laid off most of our programmers.

The results are crap for many reasons. One is while we do have big names in software--Oracle, SAP, Microsoft--we also rely on many less known, niche products, and no one thought to take that in to account when selecting our off shore "partner." So instead of someone in house who knows the software and our configuration making changes, updates are done by someone half a world away who has never heard of the software and has no history with our system. Oh, and we're so far behind the niche vendor's upgrade cycle that there is no available training for the versions we run.

But the main reason we run slow, expensive, and shoddy is our IS projects are run by MBAs with no software or development experience. I survived the lay offs to be the technical expert to keep an eye on the consultants and contractors, but as I've tried to make clear, if they don't include me in requirements gathering with the users, and I'm not in on the design or construction, and they don't include me in the test cycle, then I don't know what it's supposed to do, how it's supposed to do it, or how well it performs, so I'm not much of an expert.

No, I am not paid well. Yes, my resume is in order and I am looking.

The bright side of lay-offs is, no matter what management thinks of me, everyone I've worked with as a peer or in my user community thinks I'm a superstar, and now I have this network of people who now work at all the major employers in the area, so there's no shortage of interest.

Re:You get what you pay/wait for

[Mycroft_514]

Here here. Agile is nothing more than a rehash of what we called prototyping back in the late 80s / early 90s. You didn't think there was anything new under the sun did you?

The big problerm with Agile, the way it is practiced, is that you push 3 times as much rework on your DBAs and other support personal. Tell me - who costs more - a DBA or a developer?

Agile proponenets never facter in the higher costs of the support staff, since they are "already there". But what does it cost to extend your support staff when they are overloaded? Where do you get those scarce people as well?

Re:You get what you pay/wait for

[Jake Griffin]

I didn't mean to come across as knocking other approaches. The core of my point was that in my situation, with my team, agile works well. And to address the questions you posed:

Fast - By change of direction, I meant for the REST of the project, not work that was already completed. You can change directions on a weekly basis with agile (if your situation supports it, as someone else suggested, this won't work for the design of an airplane for example).

Cheap - My team tends to use the words priority and value interchangably. The highest priority task is the one that brings the most value to the business as a whole (which can, admittedly, be difficult to judge the "highest" sometimes, but we do our best and people seem happy).

Good - Short development time means we don't have to go back to the research and designing we did 3 months ago to remind ourselves what we're doing. The research and design is done in very small chunks and is usually from the past week. Yeah, some things take more than our one week time to complete, but we have SOMETHING done each week that is measurable, predictable, and best of all, sustainable.

Re:You get what you pay/wait for

[Jake Griffin]

Oh, and also, I was basing my comments on previous experience. I have worked using a waterfall model in the past, and in my experience it wasn't usually executed well, or didn't work as well as the team I am a part of now. So no, I don't know the best way to do things, but I do know what has and has not worked for me.

Re:You get what you pay/wait for

[crutchy]

who costs more?

consultants performing pointless system investigations in ever ultimately futile attempts to pigeon hole a company's infomation system in such a way as to fit a commercially available system in an also futile attempt to remove programmers from the picture altogether.
also, dba's are generally cheaper than software engineers and programmers, so putting more workload on them is economically sensible if it improves development efficiency. having said that if you employ programmers with half a brain the db design would be no different regardless of which development methodology you use. anyone who needs to make a flowchart to normalise data isn't qualified to design a database in the first place.

if an organisation needs to extend support staff for agile projects, it is likely that they would also be required for waterfall. waterfall projects don't result in a simpler design, it just takes longer for waterfall to produce an outcome that most likely no longer meets all the needs of the organisation anyway.

the op is also right about agile not being new. i was programming that way long before i heard the term, but its a catchy name that can be used in marketing guff, and it also makes it easy to describe in conversation. agile is merely unplanned development by people that know what they are doing, which necessarily excludes CS graduates that cheated their way through exams and think that they know what they are doing just because their garbage compiles without errors. its also different from the philosophical types that have to analyze the organisation to the nth degree before they type a single line of code because they are so afraid of getting it wrong if they have nothing to back up every design choice. experienced agile programmers rarely need to document their decisions because reasons for them are usually obvious. agile programming also encompases the ability to recover from a fuck up without too much effort (it needn't even be a fuck up - it may just as well be a complete change of requirements by the client), so justification of an agile fuck up doesn't require the same amount of effort as trying to justify fucking up 6 months of fruitless planning and proposal preparation.

agile programming is also likely to face more stringent financial monitoring, because the bean counters can directly track tangible costs versus practical benefits. costs of agile development aren't represented by some abstract thumbsucked figures on a tender document that will no doubt be blown out anyway.

Re:You get what you pay/wait for

[Kergan]

If it can make you feel better, try hiring one directly... I tried that a few times, and found it was even worse than outsourcing a specific task to a pre-existing team.

The single worst I hired mentioned he had a few personal projects and he wanted to start his own business someday. I figured I'd encourage the guy by offering him, at his option, to work 4 days per week instead of 5. He picked the full time option, as the pay was slightly higher.

Having hired a few other Indians before him, I didn't worry too much about his pathetic productivity for the first couple of days. Until I saw him bidding on a job on E-lance.

When I confronted him with it, he revealed that he occupied a day job at the outsourcing branch of a major US company. Aka he had two full time jobs and occupied them both by completing tasks on his own account.

Re:You get what you pay/wait for

[Unipuma]

If you look into where Agile came from, you will see that it is a collection of best practices and insights gathered since the 60s. Agile is just a collection of common sense, nothing more, nothing less.

Everyone implementing it as a 'thou shallt...' way of working, does not understand agile.

Key focus is:
- release early and often, so you get good feedback
- TALK to your customer (and to your teammates), don't assume some email of document captures what they mean
- improve your process if you find somthing isn't working, don't just continue with rituals and procedures because someone said so.

Yes, this asks of a certain mindset from both team and customer. But if they didn't have that mindset to begin with, no matter what method you use, you will fail.

Re:You get what you pay/wait for

[Jane Q. Public]

"I'm going to have to call bullshit on those numbers."

As I said, they are commonly reported. I'm not vouching for their veracity... maybe the people reporting them are exaggerating. How should I know?

But the 7 LOC number (or some say 10) is a famous one and you can find many sources for it... it's hardly in dispute.

As for the other number, as I say maybe they are exaggerating, but I think there's good evidence for it. Sunday and Monday of last week I personally averaged more than 1000 lines per day. And that's not comments and whatnot either... that's actual lines of code.

Re:You get what you pay/wait for

[ultranova]

I *know* 500 thumbs are going to be a ridiculous amount of bandwidth.

You could simply do like this Greasemonkey script and attach new thumbnails at the bottom of the page when the user scrolls down.

That's user interface design. Which, BTW, marketing ALSO has no fscking clue about. Marketing should be doing *marketing* and that's it.

You mean like deciding what the marketing materials, such as company website and its photo gallery, should look and feel like?

Re:You get what you pay/wait for

[Thuktun]

If the client is aware that the design is in flux, they will insist on changing the requirements at every possible opportunity.

In my experience, clients do not need this excuse to constantly change requirements.

Re:You get what you pay/wait for

[kelfink]

I'll choose Pick Two. Then I can go back for the others.

Re:You get what you pay/wait for

[turbidostato]

"Why should the engineers take the blame for everything, even other peoples' failings?"

All I talked about was deflecting blame, as in "make sure it doesn't falls on me", not that it effectively will fall on me and even less if it would be a deserved on undeserved blame.

"It is everyone's responsibility to speak up"

Then it's everyone's responsibility to be sure they are doing all at their reach and proportion to maximize the project's odds to success, which brings the situation back to square one: saying "the issue is with Marketing or perhaps the Project Managers" is maybe a good way to deflect blame away but adds zilch to the project's success odds so, any other suggestion?

"if stubborn, pig-headed PHBs and MBAs won't see the error of their ways, why should anyone else take the blame?"

Because the world is a filthy unfair place and those on a position of power, specially if they are of the stubborn and pig-headed kind, will use their power to deflect away blame making the tryings of their minions not only not conducive to rise the odds for the project to success but moot at deflecting blame away from themselves because power is a much better weapon for this?

Re:You get what you pay/wait for

[turgid]

We engineers should refuse to put up with this. I know it's not always possible to find a new job, but we must vote with our feet wherever possible.

In my experience, businesses run by people like that are usually on their way down anyway.

Who are these people again?

[JDG1980]

I'd never heard of Voke before today. What is this company? What credentials do their analysts have, that we should care what they say? (I don't mean academic credentials, I mean proven real-world success.) What are they trying to sell?

There needs to be more skepticism about statements coming from random "consultants", think tanks, etc.

Re:Who are these people again?

[neiljt]

There needs to be skepticism. Doesn't really matter who suggests it.

Re:Who are these people again?

[ahem]

I took a look at their website. Seems like two ex-Gartners striking out on their own to build their own Gartner.

To that end, it certainly casts the alarmist report titles in the class of "generate buzz/subscriptions".

Both of the bios of the principals are fully buzzword compliant, not to mention cromulent.

Re:Who are these people again?

[dkleinsc]

What are they trying to sell?

Seems like the service they're intending to sell is a believable reason for manager A to blame the failure of a software project on manager B. In large companies, that's extremely valuable.

Re:Who are these people again?

[RabidReindeer]

I took a look at their website. Seems like two ex-Gartners striking out on their own to build their own Gartner.

Dogbert & Ratbert?

Re:Who are these people again?

[greg1104]

I don't know why this is modded Funny when it's the most Insightful description of the report yet.

Developer rebellion?

[Nursie]

It was forced on us by "hip and trendy" managers who saw it as a way to get more frequent status reports (i.e. pretty much daily) and try to get more work out of people (it's agile! Crunch time is every sprint!).

Not that I hate working that way, I like the morning meetings when they're conducted correctly, but it's not a panacea. Neither is it really anything new AFAICT, it's just waterfall with shorter iterations.

Re:Developer rebellion?

[Anonymous Coward]

That is so true that it's waterfall with shorter iterations. The process can still fail miserably if you don't have someone steering the process towards the deliverable goals. Also, just because you finished a piece of shitty code and decided to move on can still spell disaster for a project. One of the assumptions in Agile is that at almost any point you could go back and recode a significant amount of the work once you realize that you've been going down the wrong design path. Sounds nice on paper but in reality I doubt that ever happens. You rarely get a chance to redesign major code elements once they start getting leveraged and established throughout the codebase.

Re:Developer rebellion?

[Vanderhoth]

^ This is exactly what happened in my department. No training or understanding of the processes involved. We were told by our managers, who heard it used as some buzz word then read an article or something on it, we were going to use it.

After five years of practice and putting my own money up for training I finally have somewhat of a handle on it, and it works great in some situations. Specifically when a project is really short and only has maybe one or two cycles before it's complete.

The worst thing I find about Agile is scope creep. We were told we need to manage client expectations, which wouldn't be a problem except we're not allowed to say no, or that we can't do something, and we're not allowed to discuss cost. What I've ended up doing is putting all the request I get in a database then I let the client pick the most important features at the beginning of each cycle. After two or three cycles the clients usually forget about the, "oh, you know what would be really neat!!" features, or they confront me with, "Why hasn't such'n'such been done yet I asked for it two months ago", in which case I tell them it's in the queue. When projects go over budget we leave it to the managers to deal with. After all we're not allowed to discuss cost.

Re:Developer rebellion?

[modmans2ndcoming]

Waterfall is the basis of all engineering....the difference is you can not use it in its classic sense in a software engineering project. Iterative is the modification you are talking about and yes...it takes smaller chunks and applies the waterfall to each...what separates basic iterative from Agile is the methodologies used to decide what belongs in the iterations.

Re:Developer rebellion?

[modmans2ndcoming]

That is actually a really cool way to make the customer feel like they are in control... they can request many changes, and choose the priority for the next release....not bad.

Re:Developer rebellion?

[mwvdlee]

I've seen this in practice, it works really bad.
The problem is that "really cool new features" pretty much always win from all but the most annoying bugs.
If you rely on a feature that only a minority uses and that feature is bugridden, a customer-controller priority system will ensure that it'll never get fixed.
Unless they make an exception for bugs (bugs have priority over everything else), it won't work.

Re:Developer rebellion?

[cmat]

In fact, the customer really must always be in control... of the features. As developers, we are good at what, how, when and where. It is however, the "why" that will hang us ever time. And the "why" is driven by and only by the stakeholders of the software being developed (i.e. typically the "client" or "customer"). So they must (imho) ALWAYS have control over the features, and be given input as to how their choice of features impacts the other variables: cost and delivery time (which we are supposed to be the experts in providing them).

I don't think it makes any difference on the development methodology used, but this one golden rule will, must always be obeyed in successful projects: the clients choose the features, the developers provide the estimates and recommendations on implementation and delivery time. Then the client is free to make an informed decision based on what's the most important features for them at the time frame that developers feel is achievable.

Re:Developer rebellion?

[Anonymous Coward]

I once asked my boss to prioritize the requests I had for a project. He said all the requests were priority 1.

Re:Developer rebellion?

[donscarletti]

If I had asked people what they wanted, they would have said faster horses - Henry Ford

One can make an effort to understand the business practices and requirements of the client well enough to give them what they need, rather that what they ask for. It's a riskier proposition because you can't just throw it back saying "well, this is what you said", but if you really want to make a something more efficient, especially if it is internal and will impact you in the future, you've got to tackle the whys with the what, whens, wheres and hows and deliver the solution that is needed, rather than what someone with questionable understanding of the problem has asked for.

Re:Developer rebellion?

[Kjella]

The worst thing I find about Agile is scope creep. We were told we need to manage client expectations, which wouldn't be a problem except we're not allowed to say no, or that we can't do something, and we're not allowed to discuss cost. What I've ended up doing is putting all the request I get in a database then I let the client pick the most important features at the beginning of each cycle. After two or three cycles the clients usually forget about the, "oh, you know what would be really neat!!" features, or they confront me with, "Why hasn't such'n'such been done yet I asked for it two months ago", in which case I tell them it's in the queue. When projects go over budget we leave it to the managers to deal with. After all we're not allowed to discuss cost.

Well, part of agile is that managers have the permission to change priorities (but only between sprints, not during sprints), but they can't put infinite work into a sprint - if something gets prioritized up everything else is prioritized down. And strictly speaking you shouldn't speak costs but you should speak hours - estimated with planning poker or something like that. Here's roughly how I've understood it should happen:

1. The product backlog should contain all the tasks the project should do. Tasks that are far out are coarser and have less secure estimates, but that list is the best estimate on the total scope.
2. Any pet features the manager has wanted should go in the product backlog, that's the only place where he's allowed to add items.
3. Before each sprint, the team detail and estimate sprint tasks from the product backlog that might go into the next sprint, for a small feature this may be a 1:1 but for a large feature there's typically many sprint tasks to one product task.
4. The manager and the scrum master go over the product/sprint items and decide which should go into the next sprint, the sprint is timeboxed and the estimates are given so it's almost like ordering a la carte, you can only get X items from the menu.
5. You can at any time see the scope creep from hours spent + product backlog. Typically you create a burndown chart which shows how many sprints it would take to complete the project given the current backlog and the current velocity (hours delivered/sprint).

Re:Developer rebellion?

[Surt]

Shorter iterations is kind of the primary point. The idea being that project failure will become visible earlier, opening up more options in the response to the failure.

Re:Developer rebellion?

[Surt]

What you've ended up doing is exactly what agile recommends: all work is in a single priority queue, and the customer gets to determine the priority every sprint. Work comes out of the queue at the rate reality dictates, but the customer can always decide what is most important to them to get next.

Re:Developer rebellion?

[Surt]

Why is that the wrong outcome. From what you are saying, they are maximizing customer satisfaction overall. Yes, you, the minority customer, are dissatisfied. But someone has to be in this scenario. Why should they choose to make more customers dissatisfied?

Re:Developer rebellion?

[Surt]

Agile would say that someone with a theory of a better solution would propose it during the customer feedback cycle, and let the customer decide if that better solution is actually what they want.

Re:Developer rebellion?

[Surt]

You asked wrong. You don't ask for the priorities, you ask for the order he'd like them resolved in.

Re:Developer rebellion?

[foniksonik]

If you didnt get your stakeholders to practice agile (go to backlog meetings at least) then it won't work. They also have to participate. They should set business value (1-10 works) and provide clarity on what needs to be built. At the end of a sprint they see the work and add refinements to the backlog.

Re:Developer rebellion?

[dcollins]

Counterargument: Why bother taking that risk for a custom one-off project for a single client? If you've already got the development contract, then there seems to be little upside in doing something unexpectedly revolutionary (and as you say, "it's a riskier proposition").

Now, if you're making a product for mass-market consumers, who will make a purchase decision at a time much later than design/development -- like a Ford automobile, or Google or Facebook or entertainment media -- then that's a different story.

Re:Developer rebellion?

[mothlos]

This isn't a problem with Agile as much as it is a problem with organizational management. It seems that every new idea is simply a way to rebrand management's desires for more work and more control over the process. I can't tell you how many stories I have heard (omitting my personal experience) of shops which implemented structural paradigm 'X' (e.g. Agile, ITIL, Six Sigma) only to cherry-pick and misimplement and then later call the paradigm a failure when in reality the paradigm wasn't even attempted in anything like a reasonable way.

That said, Agile doesn't solve every problem and for many projects it isn't particularly appropriate. Agile works best when stakeholders are not dependable and you, developing something fairly straightforward, and your team has sufficient maturity and buy-in. That said, Agile does encourage practices which are applicable in almost every project, particularly writing smaller functions which work and saving optimization for later.

Re:Developer rebellion?

[Decameron81]

Agile works, as long as everyone involved has the balls to stand up for their own part of the process. If the client requests a feature that requires a big chunk of code to be rewritten / refactored, you just have to make sure you're upfront about it, and make it clear of how much effort and time will be required in the process.

The basic thing to keep in mind if that your boss, or the client don't trust your effort / time estimations, agile won't work.

And as a final note: the way to make sure you can trust someone is to hire the right people - have a good screening process when you hire.

Re:Developer rebellion?

[hey!]

Well, agile's been around for something like a decade, so it can hardly be seen as trendy any longer.

"Agile" is an umbrella term that covers many "best practices" that cover interlocking areas of concern. Unit testing is one example that actually involves more up-front work. The reason automated testing is "agile" is that it is a safety net that allows programmers (or pair programming teams) to work with greater autonomy from each other. It allows you to catch any unexpected results of aggressive changes. This doesn't mean much if you don't have source code control, and notice how it adds considerable value to automated source control over seat-of-the-pants "I'll just save this version with a different name" management of old code.

This is also an example of how trying to just be "a little agile" it doesn't work. If you don't add unit testing and source control together, you may add only half of the conceptual and labor burden, but you get a lot less than half the benefit. This is why so many people don't see the point of "agile". They did implemented individual, agile-ish practices, but they've never really grasped the point of agile, which is to gain those precious nuggets of time when you can concentrate on a specific, identifiable problem without having to worry about interruptions (the boss walking in mid-morning and reodering your day's schedule) or unintended consequences (will this break what everyone else is doing?).

Neither is it really anything new AFAICT, it's just waterfall with shorter iterations.

And you don't think that's something new? Were you expecting magic? You have to set goals, and unless your project is utterly trivial you have to adapt it to evolving needs.

Having managed developers before and after "agile", I think Scrum-style sprints are the greatest thing that ever happened to managing software development. It doesn't *prevent* you from having year-long or even multi-year plans, it just provides a formal framework in which you can balance the need to get something identifiable done with the need to respond to new knowledge. That knowledge is not always imposed upon you externally by management. Sometimes you discover a risk or problem that could invalidate a lot of future work if you don't address it right away.

try to get more work out of people (it's agile! Crunch time is every sprint!).

If it's crunch time every sprint, it's not necessarily the managers who are at fault. It might be you. Are you honest in the estimates of what you can do, or do you tell the manager what he wants to hear? If a quality job on a target can't be done in the time they ask you to do it, are you assertive about that? Do you manage your own time so you can go home on time at the end of the sprint? I don't currently manage a team, but when I did I was a stickler for that. In an unexpected emergency, or if the muse was on you, I'd let you stay late but I'd make take comp time immediately. Why? Because as a manager I prefer repeatable, predictable processes to heroic displays of individual dedication. Those are needed occasionally, but they represent a failure of planning, and I don't believe in developing habits that paper over failure.

Now if a manager tells you to do something quicker than you think can reasonably be done, that's just bad management. Management should be based on reality, not wishful thinking.

Re:Developer rebellion?

[Immerman]

I've come to the decision that good up-front design is important at an architectural level - get a good, well though out "skeleton" in place and you can flesh it out all higgledy-piggledy while being confident that any major rewrites will be of a limited scope. Overall code and data structure, APIs between large modules, that sort of thing. Time spent on quality large-scale design up front tends to pay for itself many times over in the long haul since you can make sweeping changes at low cost. On the other hand any halfway-decent programmer is also at least an adequate designer - when you start designing the details of every module or function up front you're probably just wasting a lot of time, and it sucks all the creative joy out of actually programming. What fun is writing code when the only room for creativity is minor implementation details? If your design is detailed enough to be read as extra-high-level pseudo-code all that's left is the tedium of actually writing the corresponding code, and you've demoted your programmers to the position of sentient pre-compiler.

Re:Developer rebellion?

[The Mister Purple]

call the paradigm a failure when in reality the paradigm wasn't even attempted in anything like a reasonable way.

While this is an accurate statement that I heartily agree with, I am amused by the resemblance to the defense of communism offered by more than a few of the trustafarian/hipster types I've had the "pleasure" of working with in the past.

Re:Developer rebellion?

[turbidostato]

"If you rely on a feature that only a minority uses and that feature is bugridden, a customer-controller priority system will ensure that it'll never get fixed."

And the problem is?

It's the customer's money, not yours, and it's the customer's customers, not yours. If your customer's POV is "fuck my customer base bugged by #876" why should you dare to tell or act otherwise? If you think you can lead your customer's business better than him you might try to start a business competing against him instead of one servicing him, don't you think so?

Re:Developer rebellion?

[turbidostato]

"If I had asked people what they wanted, they would have said faster horses - Henry Ford

One can make an effort to understand the business practices and requirements of the client well enough to give them what they need, rather that what they ask for. "

The Henry Ford anecdote might have a different reading that you might think. Henry Ford's on faster horses survived not because of what he said but because of what he didn't say: "...but still, by offering something my prospective customers didn't think they wanted or needed, I did a lot of money in the end".

*That* is the important part. Apply it to software development: you can offer your opinion to your customer about why he should prioritize A over B and you might the right or wrong and you might convince your customer or not. But good luck trying to make money in the software developing-for-hire market by telling your customers "you wanted A but I produced B instead".

Re:Developer rebellion?

[turbidostato]

"You asked wrong. You don't ask for the priorities, you ask for the order he'd like them resolved in."

"all of them by the end of this week, or yesterday, whatever is sooner".

There.

Re:Developer rebellion?

[overnight_failure]

If you think it's waterfall with shorter iterations you may be missing the point. I'd also say 'agile' covers many different methodologies so your generalisation isn't really applicable.

Re:Developer rebellion?

[turbidostato]

"And strictly speaking you shouldn't speak costs but you should speak hours"

For what you say so are talking about a specific incarnation of "agile", namely Scrum.

Well, being nitpicky, you shouldn't talk about hours either*1, but about "percieved difficulty", whatever that means (it is a "perception" an expert-in-the-field will do when confronted to having to do the thing and that's the best we can have: that's why you have the fibonacci cards instead of simply allowing the developers say "I think this will take me 20 hours").

Another point is that, at least on a mature team, you don't need nor should say what fits in the next sprint, because it is a calculated value: "sumatory of the difficulty points on the N first task on backlog / team speed" will automatically tell you what to expect to be done by next sprint end*2. The burndown chart is the tool both the pigs and the chickens have to learn to do better predictions over time.

*1 And it makes sense: number of hours X cost per hour will automatically tell you a money figure. You are not expected to talk about money, despite of the fact that money is and should be the most important consideration for the customer, because you can't and shouldn't talk about hours either.

*2 On a side note, being clear about the fact that the sprint goals are strictly a calculated value helps against "the mythical man-month" problem: a manager feels a project is under goals/overbudgeted and feels the temptation of adding new resources late in the project. Question: how much will it help to make the project evolution faster? Answer (in Scrum): who knows? we don't know how much this new guy will increase the team's speed, if at all. Again, about 1, if you fail at understanding that card points are not hours, the output of a new developer on the team would be obvious (and wrong): adding a new member to the team adds 40 hours a week more and so, you can perfectly can calculate the new burndown chart. Only it doesn't work that way, does it?

Re:Developer rebellion?

[CyberLife]

One of the assumptions in Agile is that at almost any point you could go back and recode a significant amount of the work once you realize that you've been going down the wrong design path. Sounds nice on paper but in reality I doubt that ever happens.

Happens in my company all the time, but it requires competent management and lots of discipline. The software design has to support such changes, as does the work environment. If you've got a jumble of spaghetti and a boss who just wants it done, you've got management problems. No system is going to be very effective.

Re:Developer rebellion?

[Surt]

Yep. Nothing in here really disagrees with my claims, which were related to the customer facing bugs described by the GP.

Re:Developer rebellion?

[Surt]

Then he failed to answer the question of order. Now you face a decision: push back now while he can still get something he wants, or push back later when you've done some of the work and discover he got none of his actual top priorities. It's going to be tempting to go with the first option (delays pain), but with experience you'll discover that the second yields less total pain.

Re:Developer rebellion?

[Surt]

I'd say one of the following:

Making a change to the ORM will make required features possible.
Making a change to the ORM will allow us to deliver features faster in the future.
Making a change to the ORM will improve reliability.
Making a change to the ORM will improve performance.

Lots of very simplified options. Use the one that is closest to the truth. If none of them are true, question whether there is really a benefit to the ORM change.

Re:Developer rebellion?

[modmans2ndcoming]

Bug fixes do not take precedence over features and the two should not be mixed.

Re:Developer rebellion?

[asdf7890]

The basic thing to keep in mind if that your boss, or the client don't trust your effort / time estimations, agile won't work.

Herein lies one of my problems with what my people are calling Agile (everyone I talk to seems to have a slightly different, sometimes wildly different, idea of exactly what "agile" means - ATM it seems to me to be "what we've always done to an extent, but more formalized and with responsibility more evenly spread"). Our company/group is going through a very fast change at the moment (most of it for the better: resource for things we've been begging for resource for for years, better coordination/sharing between parts of the group, commitment to proper planning, and just general investment from up high to refresh+grow our people and equipment) and "agile" is one the BigThings.

I'm liking parts of it, but some of it grates (the terminology for a start: the next person who calls me a "scrum master" is getting rugby tackled or, if I'm having a bad day, pushed down the stairs).

One of the issues I'm having is that people are trusting my estimates too much IMO which pushes me out of my comfort zone quite a bit as I know that tracking and estimating time is very much not my forté. Though I think part of the problem is one step above my line manager, where there are a couple of people taking estimates too literally which seems to me to go against the methodology they are asking us to follow: they ask for a ball-park estimate, but then expect a detailed report if things take more or less time than that "guess" (and preparing that report, or just having meetings about it, eats into the next period's hours for someone). As it happens I've surprised myself by being fairly close to the mark most of the time thus far, when estimating my ability to get X done in a given timeframe, and other peoples' abilities to do the same, and including "coordination time", but I fully expect at some point soon there will be a massive underestimate (there have been some underestimates already, but some overestimates too and they've more-or-less cancelled out and where they didn't I pulled extra hours and made them look like they did) and excrement will be introduced to the air circulation device...

One of the things I'm not getting out of the change that I've been nagging about wanting for years is time to adequately document work so that later maintenance is less arduous. Tasks like that are considered and get the own "card", but those work items don't seem to gather any priority.

Though as I've expressed my concerns more than once I'm filing it under "things I can say 'I told you so' about when the time comes" for the time being. Having said that, the things that look much more positive in the future as a result of the investment/expansion/improvement are outweighing my concerns at the moment - I'll take a long look at the situation again when I can see where some more of the many balls that are up int he air right now are likely to land.

Re:Developer rebellion?

[complete loony]

I thought that one of the points of agile / scrum, is that you only give an estimate in hours when you have broken down a piece of work into smaller tasks, each of which should only take a day at most to complete. ie, when you have almost finished designing the solution and now just have to implement it.

Are you giving estimates in hours before that process has been completed? Is your task breakdown insufficiently detailed? Do some of your tasks have big unknowns?

At the time a task goes over, or the discovery of an unknown or additional piece of work that your task breakdown didn't cover. Create a new task, give it an estimate, and quickly document why it was required. Before the next iteration, review all of these extra tasks and try to learn something from them.

Re:Developer rebellion?

[DNS-and-BIND]

You don't need that accent on the "e" of "forte". You're thinking of the Italian word forté, which means loud. The English word forte, meaning something you're good at, derived from the French word fort, in the sense of fortification. It's pronounced "fort", the Italian word is pronounced "for-tay". The more you know!

Re:Developer rebellion?

[Nursie]

Unit testing is one example...

If you don't add unit testing and source control together....

WOW. You think unit testing and *source control* are properties of an Agile workflow?

No, they are the properties of a competent engineer or engineering team and have been since long before agile.

And you don't think that's something new?

Nope.

Having managed developers before and after "agile"

Given your comments on source control, you shouldn't be managing anything.

Re:Developer rebellion?

[pijokela]

Your situation is probably very common - good luck. Just a f

- It's a real problem if you estimate all the stories/use cases/features. The team is supposed to do that so that they can commit to doing the work in the estimated time. Maybe you should stop doing estimates at all? That would force someone else to do them.
- If you're the lead designer (and while scrum does not have that role the team usually has someone the others trust), you are not the scrum master. This is important. Go ahead with the tackling, or better yet, point out that you just cannot be the scrum master. IMHO it's better to make a project manager or junior dev the scrum master.
- Do not make estimates in hours or days. Make estimates in points. Pick out some example features and decide that feature X is 5 points and feature Y is 10 points. Then estimate all the other features with points. Now, all your devs are not as productive, but hopefully they can agree that Y = 2 * X in size. After some sprints you will know how many points you get done in a sprint and it will provide you with quite accurate calendar estimates.

So, the short version is: you are not doing agile, but maybe it'll work great for you guys? Good luck.

Re:Developer rebellion?

[asdf7890]

Maybe I'm loud about the things I'm good at!

Re:Developer rebellion?

[hey!]

WOW. You think unit testing and *source control* are properties of an Agile workflow?

Wow. You think you can have Agile workflow without them?

Re:Developer rebellion?

[complete loony]

Another thought; You know your estimates are inaccurate right? Are you attempting to report the potential accuracy of your estimate? Or are you reducing the problem to a single number?

Your estimate should include some measure of the risks involved, and some measure of your past accuracy in estimation. If you think a particular problem will take 40 hours to solve, tell management that it could be between 30 and 55. Let them know just how inaccurate your ball park estimate is.

Re:Developer rebellion?

[Nursie]

No, I don't think you can have anything you can remotely call a development process without them, that's what I think.

Sorry if it wasn't clear, but the moron I was responding too seems to think that these items are unique to an agile way of working. That is incorrect.

Re:Developer rebellion?

[Nursie]

And now I look at the comment history it turns out to be the same moron, what d'you know.

I repeat, if you were managing developers "before agile" that weren't already using these things then you and they were incompetent. Not agile or waterfall, not old or new way of doing things, but simply incompetent.

Re:Developer rebellion?

[Money for Nothin']

This. I would shower you with mod points, if I could.

As a professional developer since the early 2000s, I've been saying the exact same things about agile processes ever since I was introduced to them. I've come to like TDD (if it's taken as a guideline rather than an ideology in which perfect code-coverage is achieved), if it's combined with heavy, Waterfall-like requirements analysis up-front, and a reasonable amount of documentation.

But on the whole, everything else seems to be a management trick to try to screw devs into longer hours for no extra pay, and into producing more-frequent status reports, more-fragile/less-error-handling software, with a shorter time-to-delivery.

After seeing dozens of projects numbering in the double-digits this way (a few of which I've participated in), across almost as many organizations, I'm convinced that most of agile methodology -- in practice, if not in ideal -- is bullshit snake-oil sold to senior management to try to make junior management look "proactive" and up-to-date on the latest tech and management trends. These junior managers are complicit with consulting firms selling their business process services to convert clients to using agile methodology (I was once such a consultant paid partly to spread the gospel). But frankly, this is the standard relationship seen between consulting firms and their clients: clients buy-into the idea that the unearned perception of competence propounded by the consultancy, and believe (wrongly, in a significant percentage of cases) that the consultancy's employees are more-competent than their own... "A fool and his money are soon parted".

The best I can say about Agile is that I believe at the time it was created (back around 2000), by Martin Fowler, Kent Beck, etc., it may have been a clever way to stanch the offshoring trend of the time, by claiming that close face-to-face interaction between project stakeholders (devs, managers, BAs, end-users, etc.) was critical to project success. I've found this is actually very, very true -- but this is frankly a very, very old management lesson. That, and I don't think Waterfall (which I've also spent lots of time doing) is the right methodology, either. The least-bad methodology really depends on the purpose and reliability requirements of the software project...

Re:Developer rebellion?

[hey!]

And now I look at the comment history it turns out to be the same moron, what d'you know.

Maybe that should tell you something about your reading comprehension skills.

*Nothing* about agile is unique to agile. It's an umbrella term for a set of best practices that have been proven to work well together. A little thought will show that all those practices *had* to exist before the term existed to be included in the term.

You are confusing "Agile" with "Scrum".

Re:Developer rebellion?

[jemtallon]

Oh good - so none were high priority and you could take your time on any of them

Requirements do change

[Anonymous Coward]

All the planning in the world can not assist with political changes in a business. Requirements are a moving target and agile is the best method formal framework available for integrating those new requirements into the workflow.

Traditional waterfall does not provide such flexibility and having to repeat analyses due to changes is both time consuming and a waste of financial resources.

I delivered some of the largest systems available using this framework and it works well. It all depends on the people involved.

Re:Requirements do change

[dgatwood]

All the planning in the world can not assist with political changes in a business. Requirements are a moving target and agile is the best method formal framework available for integrating those new requirements into the workflow.

Maybe, maybe not. If the requirements really are constantly changing, Agile poses a very real risk of never producing a working product. At some point, you have to step back and say, "Okay, we're never going to have a working building if we can't decide whether we're building a house or an office building." At some point, you simply must stop doing the agile stuff to just beat on the project for an arbitrarily long period of time until you have something that is functional for some fixed set of goals, and worry about dealing with the fallout later.

Also, Agile tends to assume that everything can be broken down into subtasks that take only a single iteration to complete. In practice, this is not always the case, particularly with complex software.

Finally, Agile has a tendency to fail in its goal of producing software that is actually usable by its intended consumer. Because the design work is done iteratively, it is very easy to go off on tangents and iterate on some part of the design, while failing to design the whole. This problem can also plague the architecture underneath if you aren't careful.

Re:Requirements do change

[SpzToid]

Thank you for describing Agile so I could understand it better, however I try to see The Point, aside from causing me deadline stress with regularity.

I always try to point folks to this wikipedia page that describes RUP; especially the graphic. In fact I have found on every single project whenever I have any say on the matter, all the stakeholders adore planning based off of this instructional page-as-a-plan. I wish I could say this happened to me a lot.

Usually discussing the graphic in an important stage is enough to set the pace of the project, in my experience on more informal projects.

https://en.wikipedia.org/wiki/IBM_Rational_Unified_Process

Re:Requirements do change

[mwvdlee]

It is my understanding that ever with things like Agile, you still have overarching phases. You still need to have an overal design, you still need to test the product as a whole, you still need an architecture. It's more about subdivision than simply splitting a task.

Re:Requirements do change

[ninetyninebottles]

Maybe, maybe not. If the requirements really are constantly changing, Agile poses a very real risk of never producing a working product.

I'm not really sure that is any worse than not producing the product needed.

At some point, you simply must stop doing the agile stuff to just beat on the project for an arbitrarily long period of time until you have something that is functional for some fixed set of goals, and worry about dealing with the fallout later.

If the goals are never firmed up, all projects fail, even if you abandon Agile. In my experience, Agile is just a good way to make it very, very visible to all the stakeholders that this is what is going on so they can do something about it. When managers are constantly telling you to change things, they often don't understand the costs. With Agile, everyone sees the forecast for completion growing or shrinking as they change it each iteration.

Also, Agile tends to assume that everything can be broken down into subtasks that take only a single iteration to complete. In practice, this is not always the case, particularly with complex software.

It does? I agree breaking things up into too many subtasks can be a common failing of agile implementations, but I see things estimated at 2+ iterations all the time.

Finally, Agile has a tendency to fail in its goal of producing software that is actually usable by its intended consumer. Because the design work is done iteratively, it is very easy to go off on tangents and iterate on some part of the design, while failing to design the whole.

I've seen this and I've worked in situations where all the design has to go through the designers before the developers, so when a customer requests a change in scope or purpose, they have to write a card for the UI specialists to design that change and write cards for the developers to implement it. This works fairly well in most cases and prevents the problems you're talking about.

This problem can also plague the architecture underneath if you aren't careful.

Agreed, this requires a significant number of competent engineers in a team and developers that remember to include architectural refactors into estimates by default. It also requires a culture of building solid, maintainable code and not relying on your fellow coders to go back in and fix your lousy hacks. (I've seen that happen as well, but the team was also collectively in charge of hiring and firing, so offending coders did not last.)

Re:Requirements do change

[Ryanrule]

If the requirements are moving target, the project is as good as dead.

Re:Requirements do change

[Brain-Fu]

Finally, Agile has a tendency to fail in its goal of producing software that is actually usable by its intended consumer.

That is *exactly* why you are supposed to be demoing the software to the client on a daily basis. If you aren't doing that, your failure is not the fault of agile, but of your misimplementation of it.

Agile is built on a different philosophy than waterfall, and those who cannot grasp those underpinnings will *always* do agile wrong. They will then blame agile for their own failures.

Agile *is* wrong for some environments. But it is a perfect fit for others....assuming it is done right.

Re:Requirements do change

[Surt]

Agile should pose zero risk of never having a working project after the end of the first sprint, at which point you should have a working product, which you will refine with additional features over time.

And looking at it more realistically, if your requirements are changing that drastically, you have something wrong with your process other than agile. The real problem is likely with your product managers, who are doing a poor job of defining the product with your customers.

Re:Requirements do change

[Kjella]

Maybe, maybe not. If the requirements really are constantly changing, Agile poses a very real risk of never producing a working product. At some point, you have to step back and say, "Okay, we're never going to have a working building if we can't decide whether we're building a house or an office building." At some point, you simply must stop doing the agile stuff to just beat on the project for an arbitrarily long period of time until you have something that is functional for some fixed set of goals, and worry about dealing with the fallout later.

Well if your requirements are that chaotic, you'll have at least as many problems in waterfall. Agile is a bit more "what do you need the most", so maybe say dry walls, electricity and plumbing. Agile is the "we can retrofit this" concept, if you want downlights we can add that circuit later. If the bathroom needs to be handicap friendly, we can redo the floor plan later. If you want to put in a jacuzzi, we can fit that later. Waterfall is the "let's think this through" concept, maybe we can do all this electricity, plumbing and floor plan once and do it right. Particularly if you have to redo a perfectly good paint job because you had to redo the floor plan or tear up the foundation to lay new pipes. Neither is a miracle cure, if you can get it mostly right the first time do that but if not then you just have to start somewhere rather than wait every detail to be done.

Re:Requirements do change

[xedired]

If the requirements really are constantly changing, Agile poses a very real risk of never producing a working product. At some point, you have to step back and say, "Okay, we're never going to have a working building if we can't decide whether we're building a house or an office building." At some point, you simply must stop doing the agile stuff to just beat on the project for an arbitrarily long period of time until you have something that is functional for some fixed set of goals, and worry about dealing with the fallout later.

I don't see it the same way. One the one hand, if the requirements keep changing, developers must change direction, too. What's the point of delivering something that no one wants anymore? If your goal is to deliver functionality that the market no longer wants, then your business will go out of business. Fast.

But this "contract" between developers and the business team is not one-way. The business development team _must_ define good requirements. Typically this means delivering _small_ features and getting customer feedback frequently. But if the business team tells the development organization to "build Rome" and then two weeks later they tell you to build Toronto and then two weeks after that they tell you "No no no, build Rio," of course the developers will fail. Rome wasn't built in a day, and big software is not either.

Also, Agile tends to assume that everything can be broken down into subtasks that take only a single iteration to complete. In practice, this is not always the case, particularly with complex software.

I disagree. Is managing complexity not the point of software engineering? To break complex components into smaller components and then "assemble" systems? You can't deliver Rome in a day, but you can deliver a road, or an aqueduct, or a market place. The _cumulative_ result of all the iterations is the ultimate goal, but for one iteration, you deliverable is much smaller.

Finally, Agile has a tendency to fail in its goal of producing software that is actually usable by its intended consumer. Because the design work is done iteratively, it is very easy to go off on tangents and iterate on some part of the design, while failing to design the whole.

Again, I disagree. Because you are iterating, it should be _difficult_ to go off on tangents. When you are done with your (short) iteration, you ask yourself, "What should I work on next?" A sane organization will choose to work on the most urgent task. A sane organization will not choose to work on a tangent.

Re:Requirements do change

[emddudley]

If the requirements really are constantly changing, Agile poses a very real risk of never producing a working product. At some point, you have to step back and say, "Okay, we're never going to have a working building if we can't decide whether we're building a house or an office building."

This is true. In After the Gold Rush Steve McConnell makes the point that "Software Isn't Soft" (p. 19):

As software systems have become more complex ... [the] notion that software is easy to change has become on of the most pernicious ideas in software development. Several studies have found that requirements changes—attempts to take advantage of software's supposed softness—are among the most common sources of cost and schedule overruns.

Flexibility costs money up front. Limiting flexibility saves money up front, but typically costs disproportionately more money later. The difficult engineering judgement is weighing the known present need against the possible future need.

Re:Requirements do change

[CyberLife]

Your entire post reeks of bad management. Anyone who initiates a project without basic boundaries is a moron. Anyone who cannot decompose tasks is unqualified to lead. Anyone who allows things to go off on tangents should be fired. It's that simple.

Re:Requirements do change

[dgatwood]

Well if your requirements are that chaotic, you'll have at least as many problems in waterfall.

No, you won't, because the waterfall model requires you to put everyone in a room and not let them leave until they have agreed to a set of requirements that they can live with. And anything that didn't get hammered out at that initial meeting, unless it really is absolutely a show-stopper, becomes a "we'll take a look at it for version 2.0" feature.

Neither is a miracle cure, if you can get it mostly right the first time do that but if not then you just have to start somewhere rather than wait every detail to be done.

No, if you can't get it mostly right the first time, then your software architect skills are not up to the task of writing that particular piece of software. Thus, the right way to approach the problem is to hire a software architect who can get it mostly right the first time.

Re:Requirements do change

[vux984]

Suppose your project is to build a cool new distributed file system targeted at high performance hierarchical enterprise storage based on a few clever innovative ideas about how to look at the problem differently.

I don't really think your example is applicable, the requirements for the file system are going to be pretty well defined up front. There'd be no reason whatsoever for constantly showing up with a new version, and then revising it.

Even if you were doing something "agile-like" you wouldn't tackle it the same way you'd tackle automating business processes -- which are never well defined, and difficult to communicate.

Re:Requirements do change

[dgatwood]

One the one hand, if the requirements keep changing, developers must change direction, too. What's the point of delivering something that no one wants anymore? If your goal is to deliver functionality that the market no longer wants, then your business will go out of business. Fast.

I think the core problem is not that the basic requirements change, but rather that some key aspects of development, such as UI design, are black holes. The requirement is a usable UI. However, if allowed to do so, the details will change at such a rate that they suck all the developer time away from everything else. "Ooh, could we make it mauve instead?" And maybe we should put this button over there instead of over here. If you don't nail down the design ahead of time and get proper buy-in from all the stakeholders, you're screwed. Iterative design results in design-by-committee unholiness—a product that satisfies no one and takes ten times as long to build.

Re:Requirements do change

[thaig]

Getting everyone in a room can still lead to the wrong design. Situations change over time and no matter how good you try to be up front you can be faced with situations that demand change and make your original design useless. I certainly have. It is often the case that there isn't anyone in the world who knows all the details or that "everyone" is 1000s of people and beyond that there are just mountains moving in your business and you have to move with them.

Scrum makes you manage your work regularly, see early when it's going wrong, adapt to get back on track. It gets your whole team involved and you end up with solutions that were thought up by your more junior team members or people working on a totally different bit of code.

Architects are useless in waterfall because they can be long gone by the time it becomes clear that their architecture is a total fuck up.

Re:Requirements do change

[Kjella]

No, you won't, because the waterfall model requires you to put everyone in a room and not let them leave until they have agreed to a set of requirements that they can live with.

That only works on the absolutely tiniest of projects. My usual impression that the big wig with the sign-off power is far too busy and important to be on your project. You get appointed some kind of representative, who is supposed to gather requirements from the users - or usually just a representative subset of them, compile it, hopefully do some kind of QA and present it for the big wig to sign. At best possibly the one person on your team has some grasp of the total solution to be delivered, but the coverage is spotty and the requirements are ambiguous, conflicting, don't contain things they think are implicit or obvious or just not detailed enough.

That you could in theory hammer out into a very detailed and implementable spec, but what you also get is feature bloat because if it's not in the spec it's out so you try to include every feature that might be nice to have or that you might possibly need. But I suppose all of that would be fine if eventually it delivered well, the problem is most IT projects fail. And they fail not because of these bells and whistles but because they fail to deliver the core functionality and value. To use a car analogy, it's like spending a ton of money on interior decoration only to find the engine design is a bust and the car will never roll off the production line or the world changed between when your SUV design started and it was delivered.

Of course those that profess the waterfall method tend to say that with enough planning you should never have a failure, if you just do the paper exercise well enough you should know up front whether it'll be a success or not. Agile is saying the only true proof is to deliver, so you start with what is supposed to give most business value and you either succeed and expand or fail and fail early. If I'm going for a drive I haven't planned every turn of the wheel, acceleration and breaking up front. I know the direction I'm going, probably the route unless there's a detour but the details are worked out as I go.

use your Brain cells... if you got some left

[fluffythedestroyer]

If devs and other people that use Agile don't documents their work for future use and maintenance I think it's clear that its a failure right at the start...Anyone with a brain cell will know that.

Re:use your Brain cells... if you got some left

[modmans2ndcoming]

yeah...they miss the part where you are suppose to design tests, document what feature is being tested and build against those test and comment the crap out of your code so you can run a nice utility to generate documentation automatically for you.

Re:use your Brain cells... if you got some left

[CyberLife]

API-documentation comments can be a good thing. General commenting within the code itself, not so much. If one's codebase requires such comments to understand it, they've got problems.

Re:use your Brain cells... if you got some left

[Zero__Kelvin]

"General commenting within the code itself, not so much. If one's codebase requires such comments to understand it, they've got problems."

I can't agree with that at all. Sparse, well placed comments are invaluable so long as they aren't describing what the code is doing when that should be obvious from reading the code. There is plenty of additional information that can be very useful. History of the code. How it was in one repository up until version x and then switched over to git ;-)

Often times a design decision is made that is not intuitively obvious, and it is important to remember a lesson learned. These are just a few very valid reasons to comment, but DoItRight(tm)

Right people, right results

[QuietLagoon]

The poll results correlate well with my experiences. I've still not seen a well-functioning agile implementation that has been working for more than three to five years. Once maintenance is required for the undocumented code, and the developers who worked on it have left, the problems with agile start snowballing.

Re:Right people, right results

[Anonymous Coward]

It works well with a small team and low budget where the final design is in flux. Software development is a learning process and agile can give you solid learning cycles when you have a tight feedback loop between the users & developers. Where I've seen it fall apart most is on large teams that are spread out around the globe - which is more and more common. If the team isn't physically and socially "close", agile can be counter-productive. Make no mistake though, waterfall has built-in costs that add little value to the development cycle but can pay dividends on systems with a long life and frequent updates & maintenance. Teams need to be willing to adapt to whatever processes is needed for their problem/project.

Re:Right people, right results

[Anonymous Coward]

Even the part about being spread out across the globe doesn't have to apply. I work on a team that is in England, Poland and the US and I communicate with these co-workers much better than all other teams that I've worked on before. We do Scrumban and it works very well! I agree about the size of the team though, smaller is better. Many large companies like to throw people at a problem. Throw fewer, more competent people at a problem who are well motivated.

Re:Right people, right results

[Gorobei]

Where's the tests?

The article also goes on about that there's no documentation, no process etc. From my experience agile projects are better documented via tests than other projects via "documentation". And because of this maintenance is easier in the long run.

Agile is not an excuse to lower quality and neglect software engineering.

Exactly right. Tests are requirements are documentation.

Want a new feature? Add a test.
Want to report a bug? Add a test.
Want to understand the system? Read the tests.

My current project has >1K devs, and >1M LOC. The doc is under a hundred pages, and that is mostly "how-to" stuff. There are also hours of "why we did X" videos to explain the design. Almost no comments in the code: if the code is unclear or poor, we just reject it: no one is allowed to use comments to explain how something works.

One critical module (approx 20K LOC) has >1K tests. Its release cycle is essentially daily, numerous devs in various teams have contributed to it, and it almost never breaks. The test pack is what allows it to be agile and replace >1M LOC of legacy system code.

Re:Right people, right results

[Brain-Fu]

Just make test case documentation, code comments, code-reviews, and whatever documentation you need be key deliverables of your sprints. Also, if you can't hold a developer for five years, then you have a morale problem that will cause such pain no matter what process you use. Or maybe you have a bias for cheap entry-level developers over experienced ones, which will also ruin all your code no matter what process you use.

Agile might not be right for your environment, but from what you say, it sounds like you are doing agile wrong.

My experience with agile has been the exact opposite of yours.

Re:Right people, right results

[Surt]

I'm currently in my personal year 8 with a company that has been doing agile for the last 11. We've had most of the original team leave at this point, so that there are only a couple of people left more senior than I am.
Undocumented code isn't a fault of agile, that's a fault of the team. Documentation should be part of your work product, and it should be scheduled right along with the other work, or an acceptance criterion for the other work.

Re:Right people, right results

[Gorobei]

Unless by >1M LOC, you could have also have said >10M LOC, your example doesn't seem to speak very well for agile.

My last two projects were 50M LOC and >10M LOC. Both agile.

My current project is only a couple of million lines of code because it is young. I am planning for 20M LOC by 2016.

Re:Right people, right results

[The Mister Purple]

I agree partially, but uncommented code is classic "they can't fire me because nobody can understand this but me" prima donna behavior (even if from a group). Comments tend to stay with the code, everything outside the code (videos, emails, test documentation) can get detached and lost much more easily.

Re:Right people, right results

[Gorobei]

Agreed. That's why my group implemented a rather brutal "it must be done so that an average person can understand it" policy. We reject code for spelling mistakes, bad idioms, pointless design pattern layers, etc.

Of course, you need senior management buy-in to do this kind of thing: you have to able to fire managers who don't get the "code produced by programmers is just like text produced by lawyers" kind of thing.

I wish I had a dollar for every screwup who tried to justify her project with "but it works!" Sorry, I don't care. It's a complete mess. You lose, clear out your desk. We will rewrite.

Re:Right people, right results

[fermion]

It kind of reminds me of prototyping. I have been in situations where the prototyped system, often done Ina RAD has never been reimplimented for production. Prototyping is important, and underused. Specifications change as a project develop and the process and minimum deliverables are better understood. What funding agents seem to be looking for is a way to skip prototyping, which is dangerous as specifications evolve quickly at the early stage, or build a prototype that can be quickly converted to a scalable production product. This may be possible if money is put in earlybtobsuport future development. Of course that money could be wasted if the prototype is not viable. Which is today Agile is probably a perfectly good process, but maybe it should not be sold as a way to save money, but to get a product running quickly with additional costs incurred later

Re:Right people, right results

[Anonymous Coward]

Almost no comments in the code: if the code is unclear or poor, we just reject it: no one is allowed to use comments to explain how something works.

There is no way for code to be as clear as plain English (and the occasional bit of ASCII-Art). Either it is too verbose, and mundane details mask the structure (COBOL...), or it's the other way around.

Re:Right people, right results

[Gorobei]

5 devs, 700K LOC seems reasonable.

1. I expect 20M LOC within three years, 5x30=150
2. No way we can hire a perfect A-team at this size, so, 3 to 1 and try to get some talent we can nurture: 150x3=450
3. We are aiming to replace 100M+ LOC, so need people with expertise in the current systems (say 600 people.)
4. Chuck in a few PMs, auditors, HR, etc: that's another 100.

Welcome to big project hell.

Re:Right people, right results

[Gorobei]

There is no way for plain English to be as clear as code. Code does what it says it does. English says what it wants or thinks should happen.

Seriously, it's the difference between having sexing with someone and reading a story about having sex with someone.

Re:Right people, right results

[dkf]

There is no way for plain English to be as clear as code. Code does what it says it does. English says what it wants or thinks should happen.

But keeping track of what you think should happen is important too. Code does what it says it does, but that's all it does. Documentation serves a different purpose.

Mind you, the best documentation I ever saw was a comment in the code that said that the algorithm implemented was documented in an academic paper from about 20 years previously (well, it said exactly what the paper was). It didn't say anything else, just pointed to the definitive explanation of what was going on and why to choose it. I suppose that for something newer I'd expect a URL or DOI; it's still conceptually the same thing.

Re:Right people, right results

[purpledinoz]

My experience is, no matter what process you use, bad developers and management will result in a disaster. A group of great developers and management will make a project a success. Anyone who is vehemently for or against Agile (or any development process) isn't really thinking critically and just jumping on a pro/con bandwagon.

Like any new method

[obarthelemy]

in any field: the early adopter are intelligent, motivated people who know what they're doing and understand how the new method is supposed to work. Later adopters are mediocre hacks who don't perform well to start with, and are probably looking for a way to obfuscate their lack of skill and motivation, or, at best, don't get how the new method is supposed to work.

Re:Like any new method

[devforhire]

In the last 8 years as a developer, I've seen 2 types of "agile."

Agile Fail:
      This is by far the most common type, where a trendy word is used to defend lack of project structure/discipline/planning. IMHO this is not too much better than waterfall in the end.

Agile Succeed:
        I've seen this once. This requires an intelligent, experienced, and disciplined team the whole way through (devs, managers, sys admins, and yes client too.) This works because you have people with the intelligence to understand the core principles of "agile" and apply them correctly to the individual project; the experience to know what "just enough" means in terms of docs, structure, managing, etc; and discipline to strictly follow agreed upon (within the team) best practices and standards. This is an incredible way to work and we did amazing things; I do not expect I will see it again because one bad person on the team and it falls apart.

Re:Like any new method

[undefinedreference]

The variable that the successful project had is what makes projects succeed without regard to methodology: A team of skilled, intelligent, and disciplined participants.

In my 16 years in the industry I've only been on a couple teams like this. The results were exceptional, but it was an anomaly in a sea of mediocrity and failure (at least when I've worked within a team; lone-developer projects tend to have extremely high functional completion rates but long lead times).

Excellent developers will simply leave a poorly-managed company and over time the poorest-quality developers will concentrate within these organizations. Due to various factors these groups outnumber excellent teams by at least ten-to-one, and probably closer to twenty-to-one. This roughly matches the development project success rates I recall hearing from the grissled old developers that became professors... Methodology cannot correct for poor management and developers, simple as that.

Agile

[Stirling Newberry]

Is a way for managers to tell other managers that the features that no one really cares about will be delivered by a date that no one believes in.

Re:Agile

[Surt]

I think you just described waterfall. In agile, the manager is supposed to tell the other manager those features will never be delivered.
(I'm serious: a feature no one cares about should never make the priority queue, and therefore never get done).
Putting a hard date to feature delivery is the very hallmark of waterfall.

I love it when XP/scrum practictioners defend it

[Anonymous Coward]

By saying, you need experienced developers in charge to prevent the architecture from going to hell, or from changes being introduced just to close a bug without addressing the underlying issue, or introducing more issues than they fix, or thrashing between competing ideas of how the code should be implemented etc.

Yes, but if you had those guys in charge then you'd probably get good results with any methodology.

As others have said, not a panacea

[Just Brew It!]

IMO agile methodologies can work phenomenally well if you have a development team where everyone is technically solid and works well with others. Take either of those factors away and it is a recipe for chaos; with an "average" development team you're probably better off with something more structured.

Re:As others have said, not a panacea

[GreyWolf3000]

Most methodologies work well in a "development team where everyone is technically solid and works well with others."

Regular 2-4 week iterations, mandatory automated testing, replacing boring waterfall meetings with short 10 minute scrums, and keeping the stakeholders involved at all times are things that every solid developer should welcome.

That's about as far in to "Capital A" Agile I've ever cared to go. Any more than that and we're too focused on process, IMO.

Re:As others have said, not a panacea

[Just Brew It!]

Most methodologies work well in a "development team where everyone is technically solid and works well with others."

Agreed.

But IMO more structured methodologies can mitigate the negative effects of team members with less effective development and/or communications skills. Unfortunately, this also limits the productivity of the star performers, by bringing everyone's productivity down closer to the lowest common denominator. And will hold back the entire effort if the team has the skills to pull off an agile development effort.

Re:As others have said, not a panacea

[Surt]

Agreed. Agile is the solution to a particular problem, but that problem is not incompetent development team.

Re:As others have said, not a panacea

[Just Brew It!]

What if the choice is to deliver 2 years late or not at all? 50% of development teams are of average skill or worse!

Not lazy devs, just unrealistic deadlines

[gaygeek]

In my experience, agile is not about lazy developers not wanting to do the boring work, it's about the business owners and project managers wanting to force unrealistic deadlines on projects such that there is no time for those tasks because of the tight deadlines and quick release cycles. It is rare that they allow the principle that you deliver what you can by the release date, but rather they want everything they asked for and the devs need to make it happen.

Re:Not lazy devs, just unrealistic deadlines

[Stirling Newberry]

Exactly, crucial to agile is the concept that features are pushed to backlog if they can't be delivered, and that programming teams have the ability to negotiate over delivery. However, as with almost any system, give one side all of the power, and it fails to work.

Re:Not lazy devs, just unrealistic deadlines

[dkleinsc]

One thing that I've learned, working in a bit of a project management capacity, is that for a lot of businesspeople, the only time frame they actually understand is "I NEED IT RIGHT NOW!"

In fact, I only really remember 1 project where there wasn't an issue. End result: We finished what we had originally set out to do 2 weeks ahead of schedule, added some polish for a week, and released it a week early. All because the smart business manager and project managers had done everything they could to allow the development team to succeed: (1) Determined their project schedule from the development teams' estimates rather than the business manager's enthusiasm, (2) left appropriate time for mistakes to happen, (3) fought any attempt at scope creep, and (4) ensured that people who weren't on the project kept out of the hair of those working on the project.

Re:Not lazy devs, just unrealistic deadlines

[overnight_failure]

I'd also say I have NEVER seen a business actually commit into any of the methodologies. That's why the phrase SCRUMBUT was coined.
Nearly every non-technical business person I've met has the 'get back to me when it's done' attitude.

Don't blame Agile for bad recruiting results

[ansak]

Agile is just a structure. Like anything else, it's only going to be as good as the people you put in place to execute it. A properly constituted agile team will put documentation (of designs, code, deployment, whatever) up as stories/tasks that need to be accomplished right alongside working features. Documentation is an end-product just as surely as working code and unit tests are.

If the team doesn't identify those tasks and sign up for them, you hired the wrong people. Reform your recruiting process before you blame a process that delivers a working solution at the end of every sprint. And if your so-called Agile doesn't pretty much do that, then you really are being scammed.

cheers...ank
(I've been a developer for 26 years; some form of Agile has covered the most productive and enjoyable parts of my careeer)

Re:Don't blame Agile for bad recruiting results

[buddyglass]

Good systems can look bad with bad actors and bad systems can look good with good actors, but that doesn't mean there aren't still differences between systems.

It's just good business

[Anonymous Coward]

The goal of development is to produce and deliver working software that aligns with the business objectives in a cost effective manner.

Agile is an attempt to achieve these goals and was conceived as a response to the failings percieved in waterfall. This is achieved by ensuring that, on a frequent basis, developments goals are focusing on businesses needs. Now this isn't to say that you can't screw up with agile. You can consistently deliver the wrong product or fail your iterations. But the business now knows it after a few weeks and can adjust. This compares with failing at the end of a 12 month Dev cycle. Both fail but it costs a lot less to fail with agile.

As for documentation, agile does not necessarily preclude documentation. Instead it says if it doesn't provide a net positive value don't do it.

Re:What is Agile?

[kestasjk]

Am I supposed to know what "Agile" is before I read an article rubbishing it, or can I just skip over the concept entirely now?

Whoa whoa whoa.. "Article"? What the hell is an "article"? Am I supposed to be some kind of psychic wizard in charge of marketing at Forbes or something to know what an "article" is? How about an explanation?

Agile is not the problem

[laffer1]

I'm the first to agree that Agile doesn't work for every company or every situation. However, if done correctly, it's a very useful process and I've personally seen it succeed. Most people ignore some of the rules and that's where they get into problems. I've seen craziness like project owners also be team leads or have direct hire/fire power. The second someone has to worry about their job, idiocy is not pointed out as it should be. Agile lets you change course, but it's not meant to make things 2000% faster to develop. Any failure of agile or the other extreme, waterfall, is always because someone didn't follow the rules and didn't implement the process correctly. I've never seen waterfall work correctly because it requires a lot more planning up front and everyone wants to change course in the middle of the process.

Business people don't want process. They want speed. That has to change. No one cares about quality or bugs until customers are complaining and sales are lost. Business people need to learn patience. Developers need to learn to stand up for process. I used to doubt it myself until I worked at a company with a functioning process. Today, I'm working for a company with no process again and it's a nightmare.

The best thing about agile is that you have clear deadlines and actually feel like you're making progress during the programming process. If done right, it can be a real morale booster.

Re:Agile is not the problem

[cpscotti]

Not the problem but is neither the "golden solution".

I work on an Agile team that because they are agile they believe they can change things, requirements & focus every two weeks. Plus, anyone that says waterfall doesn't work is ignoring ALL *critical* software we depend on. Do you think airplane control systems are developed using agile? Bankin systems? Stock exchange? Power grid... your OS for fuck sake (be it linux, MacOS or the other one).. none of them were fully developed using Agile.

Agile ADDs a lot of good stuff on top of waterfall and is more transparent and flaws/problems become apparent earlier - that's all. It doesn't solve *the problem of sw development*.

I bet you that in 10 years there'll be another *agile* with a different name and book that will promise that THEY are solving the problems. Smart people take agile and try to make it better, dumb people follow it like religion (and like any religious one, they sin).

Re:Agile is not the problem

[UnknownSoldier]

> Developers need to learn to stand up for process. I used to doubt it myself until I worked at a company with a functioning process. Today, I'm working for a company with no process again and it's a nightmare.

A process isn't a silver bullet either. Sometimes the *lack* of process IS the process too. Let me explain this heresy ...

On one job I worked at we didn't have a process for the first 6 months. We had 5 developers. Normally this would of a recipe for complete disaster. Except we had 3 things in our favor:

- Everyone was senior with lots of experience
- Everyone had a clear vision of what we were building
- Everyone had a passion for making the best product we could

Everyday us programmers would talk with the lead saying I'm working on this sub-system .. How do we do we need it to interface with the rest of the systems?

By not having management stop productivity with the typical bullshit meetings us programmers had all the time we needed to design & implement. It is one of the few times in my life where I have seen total anarchy work beautiful. It is akin to Valve's "Cabal" system -- there are no manager; everyone is on the same level. This is a must read for anyone wondering how an anarchistic system can even work
http://newcdn.flamehaus.com/Valve_Handbook_LowRes.pdf

With the RIGHT people a formal process itself is not even needed. BUT I would agree though this is extremely rare; having some structure is better then no structure.

Recently there was a talk on innovation. Sometimes the best thing a company can do is NOT DE-motivate people.
http://www.dilbert.com/strips/comic/2012-07-06/

Agreed and...

[LostMyBeaver]

I like the morning meetings, but I have found the concept of a sprint to have killed off most of the design and planning phase, especially as a group when needed. Most of the projects I work on should have all the developers/engineers/scientists locked in a room together for two months before a single line of code is written. We should have a project manager with better than entry level knowledge in all fields and as a bonus based on recent methods should have tests for every component written before and/or after implementation.

I think extreme programming combined with project management and morning scrums would be much more suitable than Agile which tends to make me see most projects get to the 90% mark muh faster, but fails drastically at the end since the lack of proper planning made integration of components extremely impractical. I still like it best when 1-2 guys spend some time to build the base product and then a team is assembled to evolve it... It avoids too many cooks.

Re:Agreed and...

[ATMAvatar]

One of the main things you should be doing when practicing agile is continuous integration. The point is that you should be able to release at the drop of a hat. It has been a long time since I have had to worry about long-delayed integration woes.

Re:Agreed and...

[dgatwood]

Failure to integrate is an avoidable problem; you should have been doing that all along. What I've seen is that you get 90% of the way very quickly, but then because of the lack of sufficient design and architecture planning up front, you end up with a design in which the remaining 10% takes 90% of the time.

In other words, it's an interesting way to build a prototype that you never intend to ship, so long as you understand that the next thing you should do is throw it away, design a proper architecture based on the lessons you learned along the way, and borrow only fragments of the code from the prototype as you build the final design using a more traditional process. If you try to evolve the prototype into the final design, you're in for a world of hurt.

Re:Agreed and...

[IICV]

One of the main things you should be doing when practicing agile is continuous integration. The point is that you should be able to release at the drop of a hat.

That's one of the problems with these self-reported "Agile" failures - sure, it borders on a no true Scotsman argument, but if you're "doing agile" with five or six week "sprints", hour-long sit-down meetings instead of standups, no product manager, no backlog, no continuous integration - then can you really say that agile methodologies failed?

What really happened was you were trying to do waterfall faster, which just doesn't work. It's like saying baseball doesn't work because you made a few "tweaks".

Re:Agreed and...

[turbidostato]

"One of the main things you should be doing when practicing agile is continuous integration."

Well, tell me exactly in which sprint did the customer asked for "continous integration" then. Because, you remember, if you are not promoting the customer's needs from his own point of view first, you are not doing agile, do you?

Re:Agreed and...

[b4dc0d3r]

Most of the projects you work on are not representative of most of what everyone else works on.

I work with a competent set of people, and we can trust each other for the most part to do the right thing. If we all estimate together, and one person is continually missing estimates, that's a red flag. Otherwise, that means we're still on the same page.

Our customer had a bad experience with waterfall, and expects the type of frequent updates you get in Scrum. Also, the power to decide which features get added or removed from a sprint due to changing conditions.

It works perfectly for us because of the development team, the environment, the customer, and the code we inherited. There is no way to say that it would work in any other situation blindly.

My general attitude towards choosing a methodology is that someone with knowledge of the environment and the authority to make a declaration, gets to choose how it goes. Based on feedback from the customer and employees, this decision might have to change.

I have been in a Fortune 20 company, where the business did not allow for Agile anything because it's too big to communicate anything across all of the teams. I've worked where IT is just an afterthought, and Program Management just barely understands what we do.

The fight with program management is, they know how long it takes to build this component or put them together to build a part. They can't understand why we can only give a rough estimate. If I've done it before, I know how long it takes, because it's done. Zero time. But that's never the case, it's always something new - either slightly or significantly, in which case your estimate will be off slightly or significantly, respectively.

The best way to describe the benefit of Scrum is that you divide work into small parts, and can show progress weekly or biweekly. You can still have an overall waterfall process with set plans and delivery dates, while implementing the parts of Agile that make sense for your team.

Re:Agreed and...

[shutdown -p now]

You need to go one step ahead and ask why people are "doing agile with five or six week "sprints", hour-long sit-down meetings instead of standups, no product manager, no backlog" etc. And that often happens because they have a project that by its nature is not particularly suitable for Agile - i.e. it's large and not easily componentized - but they feel the urge to tuck "Agile" in there somewhere because they know it magically makes things better.

Mod article 'flamebait'

[Tony Isaac]

The survey doesn't discredit Agile. What it does is show that there is wide misunderstanding of Agile, including by those who claim to practice it. I've worked in such a shop, where Waterfall was the methodology, but it was presented as Agile. I've also seen Agile work beautifully, and I've personally implemented it successfully.

What Agile really does is take into account the fact that it's not possible to fully anticipate and visualize all necessary features before a project begins. This is no different from any other physical product development, say, designing a new gadget. Lots of planning can and should be done up front, but once a prototype is complete, it will become evident that changes need to be made. Waterfall assumes that the product can be well understood from the beginning, like building a building. If you are building software that is nothing but data entry screens, maybe Waterfall can work. But for anything novel, it falls far short.

Trolling?

[ausrob]

The thing smells of trolling. I'm happy for people to 'call BS' on some of the garbage people say (by way of promoting) Agile practices, but honestly, who thinks 200 people is a wide enough sample range to denounce an entire methodlogy/ideology? Reads like a cheap shot.

Re:What is Agile?

[malakai]

<Waves his hands in front of your face> This is not the news site you are looking for.

Agile as a last gasp answer to offshoring ?

[CalcuttaWala]

This whole concept of Agile was dreamt up as a last gasp response to the offshoring of development work to inexpensive developers in India. Nothing more.

Flamed

[WilyCoder]

I realize I might get flamed for this, but I wanted to say it anyway: I think agile is a complete waste of time. Its micro management wrapped up in a fancy, marketable term.

I've been a senior developer for about 8 years now. Never used Agile, never had a need to. Hire the right people and there is no need for agile.

Ok, my flame suit is on.

Re:Flamed

[Anonymous Coward]

I've been an Object Oriented developer for 23 years and Agile development for 15 years. It beats the HELL out of the "Waterfall model" of software development.

But like any other process, it can be abused

Re:Flamed

[Surt]

If you perceive it as micromanagement, whoever is running the process is doing something wrong. It should appear to the developer as if they have much more control.

Re:Flamed

[mattpalmer1086]

Well, just because your development process is working fine doesn't mean Agile is a waste of time.

I've been responsible for scrum / scrumban implemented in two separate and very different organisations over the last 5 years. In each case it's worked very well, but in different ways. In both cases, we adapted it to fit in and provide what each organisation needs. This requires intelligence and an understanding of what the organisation needs and what Agile can (and cannot) provide. It also requires buy-in to experiment and find what works and what doesn't.

It's also not micro-management; quite the opposite. It's about empowering teams to own their work, and to develop a new product in the face of changing requirements. I've seen shy developers suddenly start having great ideas about how to improve the development process, and gaining confidence and stature as they see their ideas implemented.

It also involves the stakeholders more directly in the development process. I've seen stakeholders move from cynical and disengaged to becoming a real development partner (the short iterations and product reviews are wonderful for that). Many people simply can't visualise what they really want from a product until they see something. They are not abstract thinkers. When they can see something, it's amazing what fantastic feedback and ideas you get from the people you're building the product for. It's even better when the same people see the changes they requested appearing a short time later in the product. This empowers the client as much as the development team. Done right, it's amazingly helpful.

I did have a fight with some of the more traditional project managers, who saw getting ongoing good feedback from the customer as a failure of our requirements elicitation stage. But for them, ongoing change is a sign of failure in an earlier stage - very much waterfall thinking.

Anyway, that only scratches the surface. I think Agile has a lot to offer, as long as you understand it's not a magic bullet. You still need good people (and it may be true that good people could use any methodology and produce good results). It does encourage a team spirit and a partnership attitude done right, which I haven't got from any other development or project management methodology.

Genuine question: how do you do development - any good ideas you could share?

Re:Flamed

[overnight_failure]

I don't think you get to make a generalisation about a group of approaches to software development when you have never used them ;)

Not having the need for them is perfectly valid though, if you're in that kind of situation then you're actually very lucky. Things like Waterfall can work and work well, the whole point though is that one size doesn't fit all. So whether you're Scrum or Waterfall it doesn't actually matter. Just like development tools, you use the best thing for the job.

Re:Flamed

[mattpalmer1086]

It's a huge and arrogant mistake to think that stakeholders aren't talented people (well, they may or may not be, like anyone else). It is true that they almost always aren't talented at software development, and often not great abstract thinkers. From their perspective, you are not talented at retail, or industrial processes, or finance, or... well, whatever they actually know about and you don't.

I'm actually quite appalled at your derogatory attitude to your customers and development partners. Were you just trying to make a point, or do you really believe what you said?

Re:Flamed

[oursland]

Never used Agile

Sounds like you've constructed an opinion based not on experience or evidence, so why should I care for anything you say with regards to this matter?

Everyone knew Agile was a scam.

[Anonymous Coward]

Agile was meant for producing disposable code with few people. Such as MS Access documents that tell you the amount of wood a house is going to need, or a quick and dirty C# program that reports to you on how your web-servers are doing so you don't have to spend $10,000 per server for a whatsupgold license, or....*insert "If we could do X for Z Cash that'd save me Y money" statement".

Check out this picture.
http://en.wikipedia.org/wiki/File:Agile_Software_Development_methodology.svg

Someone thought that was a GREAT way to build complex enterprise systems. Afterall, there's a lot of movement in there, and execs with high blood pressure love seeing Chinese fire drills.

The end result is burnt out developers produce a large amount of bug ridden code which gets stacked ontop of each other in a process known as fudgepacking. A Fudgepacker is someone who builds the integration layer between the pieces of fudgey goodness which usually results in Enterprise systems with operating procedures which state "If the software gives an error, that is normal, click OK", and because management pushed it, even though the numbers LOOK wrong they are actually right which leads the entire org off a cliff. After-all, no developer knew what numbers should look correct.

If caught just before going over the cliff, two things happen. First, the lemmings argue about who's got to jump off the cliff first. Second, after the appropriate blood sacrifice upon the alter, management asks to get it fixed. Problem; the fudgepack..er..integration specialist costs $250k/year and jim says it's jacks code, so they blame jack and jack is tasked with fixing it. Well....

Cost inevitably gets out of hand in such a world which leads to outsourcing as a "risk" instead of looking for an actual solution because choosing the wrong solution makes it look like you're doing work to investors and the investors know, while it's likely you'll fail, if you do, and you look like you tried hard, some other sucker may buy your work thinking it just needs a tweak.

Everyone who does software development just wants to build indisposable code; systems that are rock solid and work well for decades. This requires a lot of work, planning and a lot of research by the business to build a [i]design document[/i].

All software methodologies are snake oil

[pauljlucas]

If you have a group of talented developers, all they really need to do is programming, motherfucker. (It helps if you read it in Samuel L. Jackson's voice.)

Re:All software methodologies are snake oil

[Surt]

Labeling Agile as a software methodology is misleading. It's a process methodology which should live at a level slightly above the software engineering. You should do your programming motherfucker, and what you should program should be guided by the Agile process.

Re:All software methodologies are snake oil

[istartedi]

This is the 2nd time I've seen a link to that site, and I get a kick out of the fact that it doesn't work right in IE8.

Testing, motherfuckers!

Re:All software methodologies are snake oil

[shutdown -p now]

You assume that the owner of the site actually cares about it not working in IE8.

Re:All software methodologies are snake oil

[Johann Lau]

You say that like it's a bad thing?

Re:All software methodologies are snake oil

[istartedi]

Why yes, yes it is. First, it's bad because the web is so sadly broken that you actually have to think about browser compatability. Next, it's bad because MS is losing the browser war and doesn't even realize it. The fact this is MS's fault is beside the point. A majority of people on Slashdot hate MS for breaking web standards, but they don't call out other people for doing the same thing. Yes, MS was bad at standards compliance to say the least; but never had the gaul to break something as fundamental as URLs! Google does this shebang travesty, and... where is the outcry?

Finally, it's bad because we're dividing the web into two worlds. The "your father's web" and "we're too kewl for IE" worlds. I like my Oldsmobile. It's comfortable. Yeah, I can pretend to be kewl, and fire up Chrome to make your stupid site work; but most of the time I don't want to.

Yeah, I know a lot of people on Slashdot have been wanting MS to go down in flames. There's a saying where I'm from: Watch out what you ask for. You might get it.

I fear the community will have to experience a web without MS being a major player before they realize what this means.

Really though, I just wish IE would fix their scripting engine. That seems to be the biggest problem. There's a broker site I use. They're not known for playing the "kewl" game, and yet IE has become unreliable there. You may or may not get a listing of all strike prices on options if you ask for it. It's as if a variable has been unitialized or something. Do it in Chrome, and it just works.

Re:All software methodologies are snake oil

[Johann Lau]

How do Google (or Twitter, for that matter) break URLs?

I like my Oldsmobile. It's comfortable. Yeah, I can pretend to be kewl, and fire up Chrome to make your stupid site work; but most of the time I don't want to.

Well, I guess there's no a programmer lost on you then.

I like not programming for a shit browser. It's comfortable. "Kewlness" has nothing to do with it. It's called knowing what's good, and acting accordingly. When it comes to the sore that is IE, I'm not responsible for proliferating it. Nothing more, nothing less.

I fear the community will have to experience a web without MS being a major player before they realize what this means.

You could say that about anything, it means zero. Are you thinking of anything specific, or is that random FUD, to defend your choice of a crap browser?

Re:All software methodologies are snake oil

[istartedi]

1. #! (Shebang). Google uses it for some AJAX purpose. I've had people post links with shebangs in them, thinking it would take me to a page. Instead, it took me to the homepage becasue IE is using # for its intended purpose--to take you to a subsection within a page. Since there is no ! section, it just takes you to the base URL. AFAIK, Google is out of compliance, didn't run this by any kind of standards committee, and just hacked it in. Feel free to correct me on that if I'm wrong.

2. I don't know what you mean by "no programmer lost on me". "shit browser" is a subjective term. Becoming a platform bigot is facile. Writing cross-platform code is what real programmers do. I couldn't live with myself as a programmer if I lost 50% of potential users because my code was insufficiently portable. One of the biggest inspirations for me was opening up the libjpeg sources and seeing that it was possible (in C!) to write code that not only ran on *NIX and Windows, but obscure systems like Amigas, and various RISC archs I'd never heard of. Ironicly, the web is supposed to be platform neutral, and it is now, IMHO, less platform neutral in practice than C which is supposed to be just one step above assembly.

3. Competition is good. One less competitor is not good, especially when it created an ecosystem where anybody could write applications without having to put them in the Jerk Store.

Re:All software methodologies are snake oil

[Johann Lau]

1. #! (Shebang). Google uses it for some AJAX purpose. I've had people post links with shebangs in them, thinking it would take me to a page. Instead, it took me to the homepage becasue IE is using # for its intended purpose--to take you to a subsection within a page. Since there is no ! section, it just takes you to the base URL. AFAIK, Google is out of compliance, didn't run this by any kind of standards committee, and just hacked it in. Feel free to correct me on that if I'm wrong.

Ohh this is uncomfortable for me, because IMHO you are kind of wrong, but it's also not a practice I'm very happy with.... It's not that IE does anything different, all browsers with Javascript turned off would behave like it on those sites. But if Javascript is turned on (and the scripts on the site don't break with IE, as they might have in your case), then it does the whole dynamic page loading thing. It doesn't have to do with standards as much as with Javascript, or as you said, testing in IE :P

But it's not Google who started with this, Twitter was, and they're now reconsidering haha:

http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html

From what I can tell, the only thing Google has to do with it (other than using it themselves) is recognizing the "bang" (exclamation mark) when crawling: http://www.socialmagnet.co.uk/2011/03/what-is-the-shebang-hashbang/

2. I don't know what you mean by "no programmer lost on me".

It wasn't meant as an insult, it's just I never heard of a programmer that uses Internet Explorer as their default, and surely not as their only browser. And any aspiring programmer surely would JUMP on the opportunity to have a "better, cleaner, faster" viewer of the web, by using a modern browser, when it's just a click and a download away. It's just I kind of associate curiosity and early adoption with the whole coder thing.

Writing cross-platform code is what real programmers do.

Exactly! Which is why real "programmers" (some would frown on calling HTML/CSS code, but personally I say bleh to all that, it's "codified stuff" for sure) code to web standards, not browsers.

If the site is correct HTML and CSS and doesn't work in Internet Explorer, then it's the fault of Internet Explorer. If you use an old browser, it's your responsibilty to either upgrade, or just accept that you're doing this to yourself.

I couldn't live with myself as a programmer if I lost 50% of potential users because my code was insufficiently portable.

IE is the only browser that only runs on Windows. So yeah, how can they live with themselves, right? :P

And they're not loosing 50% of potential users. They're loosing those of their potential users who are too lazy to check back after work with their own computer, which, as I already said, hopefully will not only have IE on it. So they're loosing 50% of onlookers maybe, but not because anything is wrong with their code.

Ironicly, the web is supposed to be platform neutral, and it is now, IMHO, less platform neutral in practice than C which is supposed to be just one step above assembly.

I'm not saying Webkit or Mozilla are saints, I hate vendor prefixes for example. But still: if you write valid HTML4/5 and CSS3, it will either show up correctly, or degrade gracefully recent versions of all other browsers. Not in IE.

And what you are asking for, that people bend over backwards to make all sorts of duct-tape fixes behind the scenes, just to get IE to render properly, leads to the problem, the expectation of people that they "should" be able to browse the web with a shitty browser. (An

Re:All software methodologies are snake oil

[istartedi]

It wasn't meant as an insult, it's just I never heard of a programmer that uses Internet Explorer as their default, and surely not as their only browser. And any aspiring programmer surely would JUMP on the opportunity to have a "better, cleaner, faster" viewer of the web, by using a modern browser, when it's just a click and a download away. It's just I kind of associate curiosity and early adoption with the whole coder thing.

Thank-your for an intelligent reply that turned down the volume on argument. It's pleasant and all too rare. That said, let me just focus on the one point emphasized above, as it's the most interesting one to me and I can fit in the reply while my friend is showering before we go out to dinner.

Yes, I realiize I might be an anomoly in this regard. FWIW, I'm 44 years old. That might have something to do with it. When smartphones came on the market, my first reaction was "I already have a prescription. I don't want to make my eyes any worse".

I don't see myself as a techno Luddite though. Rather the opposite, I see myself as a connoiseur and a critic. My priorties are different than those of many others. I like IE because it has an interface that I'm used to. Take tabbed browsing, for example. Hate it. Why? Not because it's new; but because it's an old thing that's been displaced into a new space where it doesn't belong. I already have what ammounts to "tabbing" for all my applications--not just the browser. It's called the task bar. I'm used to doing this for everything from DOS windows to text files, and switching between one thing or another regardless of what the application is. Tabbed browsing is just a nuisance because I have a deeply ingrained pattern that says, "when you want to get away from that page, click the X". Now when you do that in Chrome which, encourages you to use tabs... you lose all your pages. I have to slow down and think when I'm in Chrome. Maybe this is more expensive when you're middle aged.

Early adoption? I understand that many associate that with technical people; but on the flip side you have guys like RMS who will probably give up EMACS when you pry it from his cold dead fingers. Strangely, I'm the philosophical opposite of RMS in a lot of ways; but oh crap... my friend showers fast, and I need to shower too...

Anyway, thanks again for being an interesting correspondant; and maybe I'll find the time to bang out some more thoughts later...

Re:All software methodologies are snake oil

[Johann Lau]

I usually start out flaming, and then it either gets worse or better depending on wether the other person flames back. So no need to thank me for being somewhat civil at last, thank you. I'm a cursed rabid dog, and I need to hear calm voices to turn into a coherent human, for a bit. But I digress.

I think it may be true that not many web "programmers" uses IE.... but saying that about programmers, yeah, that's silly, use what works for you. If you make websites, you'll come to hate (old) IE soon enough, nobody will have to convince you ;)

There is Chrome Frame, it basically allows you to use Chrome's rendering with IE -- only if the website contains a meta tag requesting it, but there is a way to make it default: http://www.chromium.org/developers/how-tos/chrome-frame-getting-started#TOC-Chrome-Frame-as-a-default-renderer

The idea basically is that you'd have more compatible rendering while keeping the user interface you're used to.

Strangely, I'm the philosophical opposite of RMS in a lot of ways; but oh crap... my friend showers fast, and I need to shower too...

You clearly ARE the staunch opposite of... the man who never saw a shower! *ba-dush* ^^

Re:All software methodologies are snake oil

[istartedi]

LOL, I wasn't going to make the shower joke.

While AFK I had time to reflect more on "early adopters". Right now, at this point in history, the early adopters seem to be winning. By winning I mean that if you are the type who picks up new tech, you learn more, get better jobs, end up with 5 years experience in 2 year old technologies required to get the job, etc.

I look at that and think, "I should become an early adopter". The problem with that is that you can't fake it.

Now, this isn't to say I dislike change. It's to say I dislike change for change's sake. For example, when I was in school e-mail was just becoming widely available to students. This was fascinating to me. I could (and did) correspond with students and professors at other universities all over the country, and even the world. This, and the Internet in general were a change that I embraced and delighted in fully. I look back on that and I think it's because I regarded a world where people could communicate freely as being better than one where they couldn't as opposed to meerly different

In fact, at the time I had access to Sun workstations with XWindows. A new Windows machine appeared in one of the other labs. I tried it, and it took 3 minutes just to boot. In retrospect, they had probably attempted to install on a machine with insufficient hardware; but that was my first impression of Windows. I wondered why anybody would want to use it.

When I was out of school though I was forced to buy computing on an underemployed budget. I made less than $10k my first year out of school! I was busted back to connecting to networks through BBSs with a 286 that I picked up from a school for $115. I found out about the sale through a print classified ad. It all seems so quaint now. Somewhere along the line I developed a keen sense not only for what it meant to work under tight economic constraints; but what it meant to be a "common" person as opposed to the world of "privelege" I experienced at the university.

That's at least part of the reason I cling to technologies that are popular with the uneducated masses, as opposed to what's current with other tech-savvy people. I felt concerned that if I started doing everything in Linux (later Mac) I would lose touch with what other people experienced. Flash forward to today, and the idea of buying a hot new device for $600 every year is not exactly working class either. I'm also back to being concerned about my economic circumstances. Priorities. I want to keep my 6 year old Lenovo running as long as possible. What a fine machine it is... all too often destroyed by web devs who think it's a good idea to display dozens of full sized images and all the forum replies on a single page. Can you say "swap"? I think it could handle another stick of RAM; but dammit, I shouldn't have to buy one.

Anyway, Chrome frame sounds like an interesting idea. It's obviously a short-term fix though. We live "in interesting times". When the Lonovo dies I'm not sure which direction I'll go in...

Oh, I've only touched on a few themes here. The subject of change, the dynamic of forced vs. voluntary change, technology's place in society, etc... this could blow up into a much larger essay or even a book. A book based on a Slashdot thread... yay! Not enough hours. That's my last word on this particular thread; but I'm still a regular poster here (after 13 years!), so you'll see me around and I'll mark you as a friend.

The reality...

[Junta]

*Anything* that becomes the most popular 'brand' will become distorted to the point it's hard to say precisely how meaningful the application of the name in a given circumstance is. Agile and Cloud are the two terms in the computing industry the most afflicted by this phenomenon.

In fact, I would say an organization getting very picky about using every little piece of 'Agile' terminology is more likely than not in a scenario where they really aren't doing 'Agile'. Many just rename their 'product requirements' to 'user stories', 'milestones' to 'sprints', and 'status meetings' to 'scrum' without actually changing anything about the way they do things other than renaming (well, and putting the exact same project management data they had before into new software tools that advertise 'Agile').

It's just like how anything that has network connectivity now is advertised as 'cloud enabled', without regard for anything but the ability to transmit and receive IP as a qualifiaction for 'cloud'.

What are they trying to sell?

[goombah99]

Anti-agile services.

It's a myth that agile is undisciplined

[Anonymous Coward]

We have to practice planning and create documentation like everyone else, we just do it on rapid iterations. Agile done right will force discipline on developers and they will hold each other accountable for deliverables.

In our company there's really no alternative to agile, because our customers never know what they want. We've tried various "waterfall" methods over and over, with the same results each time--the initial requirements are vague and/or poorly understood, leading to a lot of wasteful development and missed expectations that cause the project to be late, sometimes cancelled, or if it ships it doesn't work the way the customer wants it to.

I have issues with the TFA

[thinkingsites]

From the TFA:

* Sixty-four percent (64%) of survey participants found the transition to Agile confusing, hard, or slow. Twenty-eight percent (28%) report success with Agile.
- I'd like to see the number for success in waterfall.

* Overwhelmingly, 40% of participants that use Agile did not identify a benefit.
- How is 40% overwhelming? I though overwhelming meant much larger than a simple majority. What about the other 60%?

* We received some unprecedented scathing and shocking comments about the level of competence, professionalism, and attitudes of some members of the Agile movement.
- Having not met them, I can't vouch for the Agile leaders. However, we're using their product, not their personality.

* Be aware that the Agile movement might very well just be either a developer rebellion against unwanted tasks and schedules or just an opportunity to sell Agile services including certification and training.
- Sure, it's another developer rebellion... against bad practices. Agile does not mean you get to avoid the necessary tasks like documentation. And who doesn't want to make money? If that's what they do fulltime and it's valuable they should be able to earn a living. That's the pot calling the kettle black with them pushing their $150 report.

I'm not an agile fan boy but it's a better alternative than A) bad managers thinking they're managing a project correctly or B) planning a massive project and having it shift underneath you.

This just sounds like a smear to get attention.

Re:I have issues with the TFA

[IICV]

We received some unprecedented scathing and shocking comments about the level of competence, professionalism, and attitudes of some members of the Agile movement.

I loved this line, it sounds so much like "what the hell, Agile encourages developers to talk back? This is bullshit, slaves do what they're told".

Re:I have issues with the TFA

[PhotonSphere]

From the TFA:

* Sixty-four percent (64%) of survey participants found the transition to Agile confusing, hard, or slow. Twenty-eight percent (28%) report success with Agile.
- I'd like to see the number for success in waterfall.

* Overwhelmingly, 40% of participants that use Agile did not identify a benefit.
- How is 40% overwhelming? I though overwhelming meant much larger than a simple majority. What about the other 60%?

Agile is not Easy

[Moe Taxes]

Just because you're fit doesn't mean you can tear up the parkour course.

If you've done agile right the code is the documentation, and it reads like documentation.

Agile is not developer centric, it's user centric. If what you are doing is developer centric, it's not agile.

The toughest thing in Agile is getting a good person in the user role. That's why it works great for consultancies where the user pays for the privilege of guiding their project every day, and not so much for the enterprise where nobody wants the responsibility. It is a better career move to wait and throw bombs at a failed project then to get involved and make decisions everyday.

Re:Agile is not Easy

[st0nerhat]

Agreed. Agile really was designed for frontend applications where the majority of the work is in the user interface. Games, web sites, iPhone apps are great candidates for Agile/Scrum. But I would never Scrum a prison door controller or a missile guidance package. Some things you have to get right once or not at all. Secondarily, Agile is not a one-size-fits-all. A consultant cannot set up the process for an existing team. Every company takes the form and modifies it to produce better outcomes. Sure the book-Agile is bad, but I love the Agile we run in my shop.

The metaphor of Agile

[ddtstudio]

First off, I'll say that I have little to no direct experience working in this system, as I am not a developer. But as has been pointed out to me by many Agile-experienced managers and developers, what I have done -- worked at monthly, weekly, and daily newspapers and news sites -- is very similar in structure. That is, we have daily meetings about what we're working on and where that is, the editorial goals, checking in on longer-form projects, and then going off and working our asses off.

Of course any snake-oil consultant can come in, propose a "just-add-water" buzzworld-compliant solution, and screw up any endeavor. See also: metaphors about having only hammers.

But I think the key is that at least in journalism, we had an existing superstructure and larger mission, and regular content that we delivered, so that kept us on track and gave us regular learning feedback. Think of it as daily iteration based on user research.

Do software/hardware projects have that sort of thing? Is the superstructure in place, and does Agile fit into that, rather than imposing Agile because... well, it's Agile?

agile solves analysis paralysis

[systemsplanet]

agile can be summarized as "just do it". it works well,in my experience, at cranking out code and a semi usable product. after a few years of bolting on enhancements you may wish you spent more time designing. however, it's easy to design something that don't work. at least with agile you get something working fast. as fast as the web changes, we really need fast solutions to current problems.

Agile works - My experience

[turgid]

Agile does work, and it works well provided that you have cooperative managers and good developers (or at least good lead developers).

Agile fails when management dictates what the developers do, management doesn't trust the developers, the developers are clueless or the developers are lazy.

Clueless, ignorant, lazy people cause projects to fail no matter what methodology they follow.

You don't need to spend money to "do Agile." If you want the official training, you can pay for it. There has recently been a break-away movement by the originators of Agile/Scrum to go back to basics and to provide much lower cost certification.

I was trained in Scum/Agile/Design for Lean Six Sigma to the green belt level and have over 4 years experience. I went to a new job and initiated Scum in my new team. I gave a presentation to all of the engineering staff, got their buy-in and my software team started working in sprints. I was the scrum master for the first few cycles and now we're taking it in turns to get experience.

I've tried to start with the basics and to avoid it turning into a "cargo cult." It's working very well. The PHBs love it because they know what's going on at all times without many frequent boring meetings and they get a demo once a fortnight of the new "value" that we've created in line with our sprint goals.

The developers like it because the work is in bite-size chunks, management can see progress (and so we get credit and praise), interruptions and emergent work are monitored (the effect on progress can be seen) and we are delivering working incremental pieces of the product and integrating and testing them early.

Progress and quality have never been so good at this place, and the developers are enjoying being seen to be delivering and having things that work.

The engineering director is so impressed that he wants the other teams to adopt Agile/Scrum too. I'm getting moved to another team temporarily to get them started on scum.

I also use Test Driven Development to write my code and have implemented a test stub mechanism of my own. My colleagues have seen how successful it is and are starting to learn how to do it as well.

Re:Agile works - My experience

[fotoguzzi]

"I was trained in Scum/Agile/Design for Lean Six Sigma to the green belt level and have over 4 years experience."

No buzzwords here, thankfully. Is Scum that super-stripped-down version of Agile that I have heard about?

Re:Agile works - My experience

[turgid]

No, it's something to do with a worn-out keyboard.

Re:Agile works - My experience

[codepunk]

I am glad he brought up Six Sigma, my god I am happy to have bailed out of the Manufacturing Industry.

Re:Agile works - My experience

[turgid]

An Agile'ist would say "We didn't need any planning or complex equipment, we just set off walking! And we've established a velocity of 48 kms per day! We're well on the way!"

Wrong.

"Agile" (of which Scrum is one tool) has several ways of planning and they are integral to the system.

Starting with Scrum, you work from a product backlog, which has major product features as agreed between Marketing/Product Development and the Customer. They are in priority and urgency order.

I've found that sprints of 2 weeks to be the optimal length. When I worked with 4 week sprints, things weren't tightly focused enough. The feedback loop was too long.

So at the start of the sprint, you (the engineers) decide what features (from the product backlog) you are going to implement and you break this work down into stories and tasks that will take only a few hours each.

Part of these stories and tasks will be "modelling" i.e. design work (we don't call it documentation - that term is reserved for retrospective design and behaviour analysis).

All of the design and planning has to be planned in to the sprint as proper work. You don't try to slip it in under the radar as most PHBs would like (hey, I'm paying you to write code...) otherwise the system doesn't work.

You can read about Agile design in "Applying UML and Patterns (An Introduction to Object-Oriented Analysis and Design and Iterative Development)" by Craig Larman.

You don't have to agree with or believe everything, but it will give food for thought.

I like Scrum/Agile/Lean because I get things done quicker, more accurately, more reliably and with better records of what I've learned than any other systems I used before (e.g. the crack-the-whip, discipline and long hours school of engineering and the anything-goes-it's-cool-man-testing-is-for-people-who-can't-write-code places).

Test Driven Development is vital for being "Agile." It gives you confidence early that what you've done works, and it gives you the freedom to make large, quick changes to your code and to refactor as needed since you have tests in place to ensure that you haven't broken anything. It takes years of practice, but I find it very powerful. I often crank out 1000 lines of working C code in a day now. I used to struggle to do 50.

Scrum is a feedback cycle that is intended to keep you pointing in the right direction. If you do it right, it works.

If your managers are lazy, ignorant, unsupportive etc. it won't work, because they are part of the feedback loop and they have important responsibilities to enure that the right kind of information comes in, and that customers are kept informed of progress.

If your managers are the old-fashioned, dictatorial, don't-trust-the-non-management-level-staff kind, you will struggle. When I started doing Scrum, I worked for one of those. It worked much better after she retired.

As for your last point, I have no idea how you'd do a controlled experiment. I suppose the best you could do is a statistical study of tens of thousands of projects.

Re:I love it when XP/scrum practictioners defend i

[ATMAvatar]

Yes, no methodology is going to be a magic bullet that turns a loser team into a superstar team. Agile was never intended to do so.

What agile processes attempt to address is the transient nature of requirements. Large, monolithic processes do not respond well in cases where the client doesn't know exactly what they want up front.

The reality is that clients often times add things during the process, and just as often as not, they do not realize that what they said they wanted wasn't really what they wanted. Providing continuous feedback and re-adjustment helps to mitigate this problem.

Agile is mind control for programmers

[ToasterTester]

I work in a Agile shop, but lucky for me in DevOps. All the SCRUMs, Code Sprints, developer trying to play QA is just a way to be cheap and to the "Suits" with OCD be controlling. The last big product rollout they got all their constants to come in and create code sprints and try to whip everyone up. A week in all the developers were ticked off and burnt and told the "suits" can hit the targets with all time wasted on writing test cases and not code. So the drop the Agile crap and got the rollout done. Think the "suits" would learn, no development is back to Agile suckage. Where I'm at Agile is all about control and trying to make 60 seconds of every minute work.

PMP Backlash

[tomhath]

Anyone who has been forced to work with certified Project Management Professional project managers will understand why organizations have looked at agile. PMP is the worse of waterfall with a bunch of useless buzzwords. Agile breaks that cycle but does introduce some other problems.

The biggest problem with developing software is that any non-trivial system takes time to deliver regardless of the methodology, You can take time to properly spec out and design a bridge over a river because it'll be good for 50 years. But the world of software changes so fast that any system is obsolescent by the time it's done, and if you spend a few months specing/designing it's time for a redesign before you even start writing the code.

Re:PMP Backlash

[urusan]

The biggest problem with developing software is that any non-trivial system takes time to deliver regardless of the methodology, You can take time to properly spec out and design a bridge over a river because it'll be good for 50 years. But the world of software changes so fast that any system is obsolescent by the time it's done, and if you spend a few months specing/designing it's time for a redesign before you even start writing the code.

This is true most of the time, but there are a few shockingly old systems in places where high reliability is required. They tend to show up as controllers for things that last a long time (like nuclear power plants or airplanes), in work environments with a highly conservative culture (hospitals), or in places where uptime trumps many other concerns (financial backend or power grid calculations). In these cases, it's critical to treat software similarly to building a bridge you expect to last 50+ years, because you really have no idea how long someone is going to keep using it (and anyway, you really don't want it to fail even if it is new).

Of course, this kind of software represents a tiny percentage of all software. In most cases today, you're right. It certainly doesn't make sense to ensure that a new video game or office productivity feature is perfect if by cutting down on quality a bit we can get it to market faster. That said, you never know when your non-critical software might be used to make this kind of critical software. OSes and libraries are particularly likely to be pulled into such a project. Furthermore, the amount of critical software is likely to expand in the near future. A good example from the recent past is that back in the really olden days there weren't computers small, light, and cheap enough to put into aircraft to control their flight, but nowadays fly-by-wire is common. There aren't any 50 year old fly-by-wire aircraft because the first ones were built 40 years ago. How long will some people hold on to their early model self-driving cars? As computers become more cheap and ubiquitous, these issues will become more widespread.

Durability and reliability requirements are important to consider early in any project, and different answers will lead to the need for totally different approaches to developing the software.

Re:PMP Backlash

[N8F8]

I'm both a PMP certified and a ScrumMaster and it's really annoying when advocates of one system attack the other out of misunderstanding. Agile isn't "anti-management and anti-process" and PMP isn't uber rigid. PMP did evolve from a construction mindset but should be tailored for other areas like software dev. The real problem is people turning process into a religion. There aren't hard-and-fast laws. They are guidelines Use what makes sense and tailor the rest to work for you. You want repeat-ability in your work process for many of the same reasons you want repeat-ability in your code.

CCP games really likes it

[emagery]

The developers of EVE online adore agile and have noted a dramatic uptick in productivity, reliability, and content delivery since adopting it... and even went so far as to do a presentation about the whole thing. So I guess it CAN work... it just doesn't necessarily work by default

Re:CCP games really likes it

[gweihir]

If you have really good developers that do all the planning, structuring and documenting on their own, then Agile can remove problems caused by dysfunctional processes. It can never turn bad developers into good ones.

Re:CCP games really likes it

[emagery]

I've no basis for arguing with that =3

Re:CCP games really likes it

[Pembers]

Agreed. (Posting to undo a moderation that I fat-fingered - sorry!)

Agile vs. Agile-speak

[DaveAtFraud]

I have yet to see a development group that says they are doing some form of agile development that actually implements the claimed methodology. What I have seen is full implementation of "agilr-speak" where agile terminology is applied to what is esentially just yet another death march development effort. Re-writes become refactorings and milestones become sprints but only the terminology changes. I don't see this as something the developers do so much as something management does since it's a way to supposedly get all three of "good, fast, cheap" without actually defining a product goal, creating a realistic project schedule and then staffing the project with enough people to accomplish the effort.

Although I have yet to actually see such a development effort, my guess is that agile really works when correctly implemented. Several other commenters say they have been part of successful agile development efforts. I've just never actually seen it done.

Cheers,
Dave

Makes sense to me

[gweihir]

While initially, Agile may actually deliver a working prototype faster if you are are lucky, this prototype will be all you get, because the system will be unmaintainable and non-scalable. It will also be unreliable and insecure. If that fits your needs, fine. If not, there is no replacement for a classical approach and, more important, for competent, motivated and experienced engineers to architect, design and implement it. Unfortunately, these competent engineers are quite scarce and quite expensive. But they cannot be replaced under any circumstances. Business people often try to compensate with processes, but while that may work in the area of business (I doubt it), it is unsuitable to any technological area requiring genuine understanding and skills.

My take is that basically Agile in practice is people trying to make do with incompetent developers instead of telling management that the people available do not cut it and that competing for talent and experience (which drives cost up massively) is the only way that will cut it. Somehow business people still fail to see the blatantly obvious: Good engineers are essential to any technological undertaking and these engineers are far more important than anybody from the business side.

The founders of the agile movement seem pretty blameless though. They already knew this. After all, "People over processes" (the "including agile processes is implied") is at the top of their list. And good people will plan, document, structure well, regardless of the processes they are working with. Bad people will always be bad people, regardless of processes, management, border conditions, etc.

 

Re:Makes sense to me

[foniksonik]

If you need secure modular code and that adds business value then it should be a story for the backlog. If it does not add business value then it should not be on the backlog. If you skip it and then realize it adds value then it goes on the backlog but in the next sprint.

It's really not that hard. Agile also means continuous improvement and that means the project is never done (though it may be put away for a few months). The backlog will keep growing with new refinements, enhancements, refactoring, bug fixes, etc. when you have enough work on the backlog (that isn't a blocking issue hotfox candidate) you begin planning a release, review the backlog, etc and start sprints.

If its a project with a hard stop eg a contracted project then these topics need to be assessed and decided upon early (do they add value to the deliverable). If not then that is the client's decision.

Re:Makes sense to me

[gweihir]

That sounds just like nonsense-babble to me. I know, it is agile-speak, but still...

I bet the business people, i.e. those without a clue how good software is created, do love it though.

Re:What is Agile?

[mwvdlee]

Since you have no clue what Agile is, let me be the first to explain, so you don't look foolish when a collegue want to discuss the topic.

Agile is a development methodoloy that radically changes the way software developers work. Instead of the typical role of "manager", "designer", "programmer" and "tester", these are split into "chief", "baker", "garbargeman", "clerk" and "monkey". You can probably imagine what each role is responsible for". Typically you work in subteams of three of these disciplines, unless ofcourse you have three "bakers", in which case a "chief" must be added to the subteam. These subteams are further divided in a "major" and "minor" roles, where the majors are responsible for all typing work and the minors documents progress. Every 2-3 hours these minors meet in a decentralized location and synchronize progress, so all subteams keep working at the same pace. At the end of the day all subteams commit their current state of development to a centralized repository and automated builds compile everything overnight. At the last day of the week, all these daily bugreports are filtered by the minors and relayed back to their majors for fixing. Iterate this for however long it takes to complete the project and you're done.

Hope this'll help you join in discussions on the topic!

I've got a mixed opinion of Agile

[NotSoHeavyD3]

Since we did that officially at one place we worked.(Agile/Scrum to be specific) So I've ranted before how I think the second dogma is just wrong. (You don't need to encourage developers to not document, they'll do that quite happily.) There are other issues however. So for one we had an issue where our "Scrum Master" basically just took over the group and started having us report to him, giving us tasks, etc. We did complain to management but they did the whole "You're doing Agile, you manage yourselves, work it out for yourselves." Then of course there's this whole agile thing that you have to produce software every day that shows visible changes. The problem that those of us in dev have with that are 2 fold. For one depending on what you're working on it might be weeks before you can shows anything that works at all. Also some bug fixes arn't really visible. (For example I fixed a race condition that in production only happened once every 6 months. It took QA and myself basically a week to write up a "test" to get this accepted since Agile is "Visiblity-Crazy") Actually more recently i was doing agile which would have been nice since the product manager could tell me how it's supposed to work. The problem? He didn't actually know how the product is supposed to work (I mean basic functionality) so I'd work on it and put some functionality and then we'd find out oh wait, nobody asked for that and nobody wanted it.(Which was annoying since I kind of mentioned I didn't think it'd be that useful.) Of course the big bad thing about agile is since you work daily with the product manager(who is simply my manager in this case) it ends up just being an excuse to micromanage me. (So that's twice I ended up getting micromanaged under Agile.)

This just in!

[SuperMog2002]

This just in! Agile works great for some people on some projects, and doesn't for other people on other projects! News at 11!

Took the words

[Giant Electronic Bra]

Right out of my mouth. You're NOT DOING AGILE if you have to integrate components at the end.

Also, the idea is not "we can just recode everything at the end", the idea is "only code now what you need right now", so yes, you will refactor, but that refactoring is an ongoing part of the process that is informed by 2 things, continuous integration and user acceptance testing.

IMHO one of the MAIN reasons why people will fail with Agile is that they ignore the requirement to have the customer/stake-holders right there in the process. If you actually PAY ATTENTION to the things that Agile is telling you to do (personally I find XP type process to be the most effective) then you can make it work. Everyone needs to understand the value of the parts, and as any Agile expert will tell you ALL the pieces are important. It is not at all interesting news for someone to tell me that if you fuck up and ignore half the pieces of the process that the other half don't magically just work.

No one development methodology is a panacea of course, but this report seems to be meaningless criticism based on not actually understanding how and why to use Agile.

Re:Took the words

[JonySuede]

Right out of my mouth. You're NOT DOING AGILE if you have to integrate components at the end.

Amen!

Developers need continuous integration everywhere so that not one of them will want anything to do with extreme, agile, small-pox, waterfall or whatever.

When nightlies are build nightly, when code is statically analyzed on commit, when the staging system is restaged when a release branches is patched, when deploying an application from staging to production requires only one command and a dev regularly meet with the client to ensure that the delta between what you are to building and what the client needs is not too big. The only methodology you will ever need is from Prog Mofo:

Programming, Motherfucker
Do you speak it?

Re:Took the words

[turbidostato]

"You're NOT DOING AGILE if you have to integrate components at the end [...] Also, the idea is not "we can just recode everything at the end", the idea is "only code now what you need right now"

OK. When did the customer asked you to add a jenkins deployment to the backlog? When, exactly, that jenkins was a must the customer accepted?

Re:Took the words

[dvice_null]

> I am paying for the product I have asked you to build.

Wouldn't you rather want to see what you are going to get and change it, before you get what you didn't want?

http://johngushue.typepad.com/.a/6a00d83451f25369e20120a513810c970b-pi

Re:Took the words

[greg1104]

So you think you're the one guy in the world who writes useful, accurate, and complete software specifications without writing the code itself first? It's cool that you're so awesome. I'm actually Batman, I just write comments under this account name. We should hang out.

Re:Took the words

[greg1104]

I don't think the report is even addressing whether Agile *can* be used effectively nor not. Its scope seems to be whether it *is* being effective or not for companies, and the answer they present is that it isn't. Whether or not there is a One True Agile that really does work isn't the point; that doesn't matter if people can't figure out how to adopt the approach for their own work (or with consulting help in implementing process, which is also being commented on). You can't prove a software development approach works by presenting examples of it working; the amount of variation among development teams means you could have just been working with a good one. The reason companies try to adopt methologies is to try and get useful work out of *any* development team. A really good software process should work as a filter, only letting things of good quality through as output.

Now, I would turn that conversation not toward Agile--it's no better or worse than the alternatives--and instead ask "is there any process that gets good software even from bad developers?" That's what managers want, and every new softtware development approach that comes along includes some people who claim such magic exists in the process that this will happen. The alternative--accepting there is no silver bullet and focusing on how to get good developers working productively instead--that idea is just fundamentally repugnant to many businesses.

Re:Took the words

[Giant Electronic Bra]

Why would a Jenkins deployment be in the backlog? If you don't have a CI system, or can't put one together as part of your tooling, what makes you think you're qualified to be doing software development on anything but the smallest scale? Would you hire a plumber if he put a line item on his project estimate "buy tool box"???

The point stands, you don't do Agile by doing big-bang integration at the end. Clearly on a daily check-in basis you can have integration problems, just routine. You should always be no more than a day ahead of the last time you ran a full set of integration tests. If you're not doing that you're wasting time and money. The poster who talked about his problems with integrating at the end was thus AFAICT not doing Agile and thus his complaints about Agile are irrelevant. If he doesn't have a CI tool he's not even a professional at any level where talking about engineering process is meaningful.

Re:Took the words

[_xeno_]

IMHO one of the MAIN reasons why people will fail with Agile is that they ignore the requirement to have the customer/stake-holders right there in the process.

That reminds me of an "Agile" project I was on. The top-level project leader declared we were going to do Agile.

He then refused to answer requests for clarification on design requirements and refused to allow any of the developers to talk to the actual users, insisting that all user communication go through him. (While refusing to actually pass on questions to users or, really, answer any question we asked.)

So we had a continuous integration system updating the demo system with every commit - a demo that no one ever used. But, hey, if anyone ever checked in a commit that failed to compile, we knew that at least.

In the end, the system didn't quite do whatever it was it was supposed to do. Imagine that.

Re:Took the words

[Giant Electronic Bra]

I think the thing is that really good crackerjack developers are hard to keep around. There's very high demand and high prices. Many businesses cannot or will not pay what they need to pay to get them, and in fact a lot of businesses really aren't doing something sexy enough that someone who could work on cutting edge stuff is going to stick with, at least not unless they're handled quite well.

So, yeah, most teams are going to be made up of some mix of good, bad, and ugly. I agree that there's no silver bullet, etc. The thing is lots of places just don't have the choice of "get good developers working productively" because they might have one or two good developers and ten bad/ugly ones. You need to bring those up to usable status. Frankly my answer is get in a good process consultant, but it is also pretty hard to find one of those... lol.

Frankly software and humans don't mix well. I think we'll have bad software until we invent some AI to write it for us (but that AI will be bad human-written software...). lol. Best you can do is if something is REALLY important, like flight control software (or for instance the self-destruct device for a large commercial booster, which I once wrote some of the firmware for) then you can get pretty decent quality, but it is hugely expensive. That box had about 6k lines of code in it and the software cost was well into the millions...

Re:Took the words

[turbidostato]

"Why would a Jenkins deployment be in the backlog?"

Because it takes effort and thus it should be priorized just like anything else.

"If you don't have a CI system, or can't put one together as part of your tooling, what makes you think you're qualified to be doing software development on anything but the smallest scale"

But still I've been already hired by the customer, or else there wouldn't be backlog at all.

"Would you hire a plumber if he put a line item on his project estimate "buy tool box"???"

You do it everyday: "hey, wait a second, I have to go to my office to bring tool X or replacement part Y".

"The point stands, you don't do Agile by doing big-bang integration at the end"

Neither Turing nor Von Neumann developed Jenkins (as an example for any other CI tool over there). You can do iterative integration as you go by hand, and in fact, that's been the case for the most part of the history of computing, it only takes time, which is money. You can install and configure a tool-base CI system, it only takes time, which is money. Your customer might not hire a group that doesn't have the proper tooling already in place, or they might do it. In the latter case, I should ask again "When did the customer asked you to add a jenkins deployment to the backlog?"

"If you're not doing that you're wasting time and money."

Wrong. On one hand, it is arguable that in any and all cases the trade off is positive. In the other hand and in any case, it is not "wasting time and money" but "wasting the customer's time and money" which he should be absolutely free to choose how and priorize in what he wastes it.

"If he doesn't have a CI tool he's not even a professional"

You know, that's not even something said in the developer's world, but you can hear it in any other professional field: "if you don't have/do X, then you are not a professional". They forget that being a professional is not about the tooling but about the knowledge and the commitment.

Re:Took the words

[Giant Electronic Bra]

I don't know what you're trying to get at. If someone wants me to come in and set up a development team for whatever reason, then establishing a CI process is part of that and thus I might bill someone for that. However, setting up a CI process is not part of a specific project, in general. I might bill this kind of thing under G&A of a project. It won't be in the backlog of the project. Neither will doing CI because that's just something you do in the normal course. You don't put "set up text editor" in your backlog either.

And yes, you might NOT use a CI tool, or at least your process might not be quite in those terms. For instance the process we use internally for product development uses our own custom build tool We do use it for CI, but it happens in a more organic way, there's no specific tool that is the CI tool. The build tool we use can accomplish the things that CI requires, and has other functions as well. I'd say this is typical, there's no one mapping of process to tool that is universal.

Knowledge and commitment are wonderful things, and without tools and process they mean nothing. Clearly at some point tools and process have to be established. I just don't see what point you are trying to make by asking where it shows up on a project plan. IMHO by the time you get to doing the project you better already have that stuff done.

Re:Took the words

[ameoba]

The irony is that the people who will read this report today, more than a decade after the rest of the community started discussing the ideas, are so organizationally mired in heavyweight processes & resistant to change that they are the very ones that would benefit the most from agile practices.

Re:Took the words

[thaig]

Good luck with that approach. You'd better be doing things that are very simple. It's quite common experience that people often don't know the details of what they want or that they want things that can't be done the way they expect and in such cases an inflexible contract will force you to be the loser. Agile methods will help the team meet your spec precisely (whether you like it or not) or decide to simply pay the penalty to get out and spend their time on something achievable. Either way, you're not in the buisiness of making money out of failed contracts so you lose.

Re:Took the words

[turgid]

Sounds like some PHB didn't like the sound of Agile and decided to prove that it "doesn't work" by setting up a project to fail.

Re:Took the words

[rioki]

I don't know where I read it, but I once read a great quote going something along the lines of:

Process is not for great developers. Great developers can create great software no matter what the process is. Process is there to get mediocre results from mediocre to bad developers.

Agile projects fail with the same reasons why waterfall projects failed. Bad developers, bad management and bad clients. We are seeing the same arguments like we saw with waterfall, they are all skirting the real issue: quality developers, quality management and helpful clients.

Re:Took the words

[Giant Electronic Bra]

Sure, so the question is what process generally gives the overall best results for the people that are actually out there needing to get stuff done. We can all wish for hot shot developers and dream clients, but we won't get them.

IMHO Agile projects fail less, fail less dramatically, and carry lower risk than waterfall projects. They also can, if used properly, foster good habits, learning, and development. You may not be able to hire the best developers all the time, but if you can make the bad ones acceptable and the decent ones 90% as good as the natural at what you need them to do, then you're ahead of the curve and you'll beat the competition.

Agile Manifesto

[rockmuelle]

In reading the comments, it's clear that many people don't know the roots of agile software development. In short, agile (note the lower case) development is basically a set of of principles laid out by a group of very talented developers in the late nineties in their agile manifesto:

http://agilemanifesto.org/

Note that the manifesto makes no mention of Extreme Programming, Scrum, or any of the other capital-A Agile methods. Instead, it focuses on observations about what made their software projects successful. Itpecifically doesn't prescribe any specific methodology, but rather encourages communication, iteration, and excellence in design and engineering. The last two points come from this section of the manifesto:

"Continuous attention to technical excellence
and good design enhances agility."

The manifesto very much allows for, and even encourages, design. It also assumes that the practitioners are already experienced developers who know how do design software and know how much design is needed before coding. Unfortunately, the most Agile methods traded experience for certified training and the 'technical excellence' portion was lost.

I've worked with many talented teams and have seen agile work time and again. Of course, all of those projects did have design, documentation, and tests. But, all those artifacts were developed using the same principles in the manifesto.

-Chris

Re:Agile Manifesto

[loneDreamer]

I think you nailed it. It is curious to look at a whole discussion over process and "Agile services including certification and training" when the idea is to keep in mind a set of guidelines promoting better adaptation, and, especially, "Individuals and interactions over processes and tools".

Re:Agile Manifesto

[shutdown -p now]

The reason why people rant at capital-A "Agile" methods is because that's what expensive consultants sell to managers, and that's what many developers end up encountering at work.

Re:Agile Manifesto

[Ensign Nemo]

Wow, that site is the granddaddy of buzzword bingo. Created for PHBs by PHBs.

Re:I love it when XP/scrum practictioners defend i

[Ryanrule]

Then you stay in design until they DO know what they want.

This finding does not match my experience

[jjohn]

Agile is not a product. It is a mindset. Each team needs to workout what that means for them. I have been in teams for two companies that used Agile methods heavily and it has worked out very well for business units (predictable deliveries), developers (predictable work hours) and customers (higher quality releases).

I am positive Agile is not a silver bullet for every project. Software engineering is still a hard problem to generalize.

No Panacea

[dark12222000]

There is no magical developmental panacea. That being said, Agile is pretty good - for some things. It's great when you aren't sure where you are heading, when you're doing a prototype run, or when you are just building data on how interested in something people are. It's also useful for when you just need to build a small product.

Agile isn't some amazing process which should replace everything. There is no one-size-fits-all development process. Everything has it's place, and Agile's place is in prototypes, rapid development, and exploratory designs.

Re:I love it when XP/scrum practictioners defend i

[Surt]

Indeed. People who are selling agile as the solution to your incompetent team are ruining agile's reputation for the rest of us.

You lucky bastard

[SmallFurryCreature]

I dream of such customers, usually when one is screaming "I NEEDED THAT YESTERDAY".

Re:I disagree ....

[Immerman]

Oh, I don't know - given N methodologies of approximately equal effectiveness, it seems to me the one that the workers find most enjoyable/rewarding is highly preferable as it will allow you attract better people and/or pay them less.

Re:What is Agile?

[Surt]

You're too far behind the times to hope to catch up. Agile was the buzzword about 5 before Cloud.

More seriously:
Agile is a particular process for getting things done, which became trendy in software development in particular about a decade ago. It's main tenet is to do work on short cycles, delivering the result to the customer, and then allowing the customer to define the next priority. The hope is that this continuous delivery model avoid the primary pitfall of longer software development cycles, which is spending months/years developing something, only to discover that the requirements were poorly defined at the start (and that the product therefore doesn't meet the real needs), or that market trends have rendered the result pointless.

Re:I love it when XP/scrum practictioners defend i

[h2oliu]

That is nice in theory, but I have found all to often in practice, when people see what they ask for, they realize that they didn't really want that. When you have a multi-year process, requirements change (heck I've seen it in multi-week!). Even ignoring the issues of human nature which induce this type of event, there are so many external forces that can drive a change that being able to re-evaluate is key.

My take on agile, and the "developer rebellion" is that developers got fed up with 18 different "Number 1" priorities, and wanted to force management to actually do their job and prioritize.

Pretty much agree, agile isn't.

[SmallFurryCreature]

The whole issue is that agile isn't. Isn't what? AGILE! That word causes customers/managers to think flexible meaning "I don't have to plan anymore, I can get what I want, when I want it".

In reality Agile is extremely rigid. There is nothing in the method to deal with issues that crop up NOW and have to be fixed YESTERDAY. Instead, the manager/customer now has to plan ahead for what he wants, get it approved for inclusion in a sprint and then wait for that sprint to be finished. That could take DAYS if not weeks!

Not that a sprint itself has to take that long but before YOUR new wish is included in the next sprint might mean you have to wait your turn.

Agile needs a lot of discipline and commitment across the entire production line, from customers to managers to developers. But if you got discipline and commitment, ANY methodology will work. And if you don't. None will.

Dysfunctional companies are dysfunctional regardless of the label they put on their method for screwing up.

Agile is particularly bad since it doesn't enforce any fixes. It is often introduced as the solution itself, go Agile and all the unrealistic planning and louse development and under staffing will just fix itself.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Bull!

[Murdoch5]

I hate seeing posts like this, Agile is not for lazy developers, in fact it's for developers who want to do what there name suggests, develop!. To the group who ran this study I would like to see the actual line out of the Agile guide that states "You can not plan", then show me "You can not write documentation". Some Agile developers will use Agile to skip doing documentation and planning but that's not the point of Agile. Agile is for the developer who can think on his feet and dance around in the ring, it's not for the developer who needs to sit down and draw out 50 pages of requirement before a key gets pressed.

There are pro's and con's to both development methods. Some people can work better in an Agile environment and some can't, calling Agile out as a lazy development method just means you don't understand it, you just wanted to pick up the name because it sounds cool and cutting edge. Agile developers in fact get much more work down but at the cost of harder work. At the end of an Agile project you should end up with the same results, just quicker and in most cases a better final product.

No where does Agile proclaim itself as the No Documentation king or the No Requirement king, it's lazy developers and lazy survey holders who give it that name, and in this case it's clear the surveyors had no idea what they were talking about.

Re:I love it when XP/scrum practictioners defend i

[pijokela]

They learn what they really want when they see the working system that does want the first asked for. If you make them sit in meeting rooms writing power points they will never learn what they really want.

WTF Is Agile?

[Osgeld]

Really? would it kill you to include a half sentence to give us an idea what your talking about?

Re:WTF Is Agile?

[Gimbal]

Wikipedia has a brief, general description.

One example of Agile approach is named Scrum. c.f Beginners Guide to Scrum - my referring t Scrum as an agile approach, considering that it's not, per se, a formal process model.

Another example, which has perhaps been around for longer, is named Extreme Programming c.f Extreme Programming, at the Cunningham & Cunningham, Inc. Wiki

The problem I see with Agile...

[OrangeTide]

Is it requires more discipline from people on the bottom (developers). But if they had discipline they would have been writing up detail plans and complete design documents up front, and delivering on time. The teams that are falling apart under waterfall are attracting the eye of managers that wish to experiment with Agile, but these same teams are usually the worse candidate for switching to Agile.

Yes and no

[elabs]

I'm a big fan of Agile, just not the flavor my company uses. - You can't plan R&D - You can't schedule the next big discovery - You can't hold one person accountable to the estamtes of another person - A developer should be accountable for delivering stories and quality, not tasks

Definition of Agile

[Anonymous Coward]

Agile is a software development methodology equivalent to declaring every mile of a marathon a "sprint", and instructing runners to attack each sprint with a pace typical of a 100 yard dash.

Re:I disagree ....

[The Mister Purple]

I agree. One of the reasons waterfall-type project management is hard to reconcile with software development is that waterfall is great for physical projects, where making radical design changes made when the object under construction is 75% done cause a massive (and, more importantly, obvious) waste of resources. For example: it's hard to revise the foundation of a building when there are 10 stories of ironwork already completed above it without tearing everything down. With software, the cost of revision, while it can be significant, is less of a factor. Thus, iterative development makes sense for software, because the physical limitations are lessened or eliminated.

Use waterfall methodology with a software product today, and you're releasing a product that might be a year or two behind the times, while your more agile competitors, who are only a quarter behind, have something more up to date.

Mind you, both products might suck.

Re:I disagree ....

[The Mister Purple]

Mind you, both products will probably suck.

FTFM

Find and replace works pretty well!

[sootman]

sed s/Agile/Analyst

'The Analyst movement is designed to sell services. ... Out of over 200 survey participants, we received only four detailed comments describing success with Analysts.' 'Survey participants report that developers use the guise of Analyst to avoid planning...'

Agile Is The Best Methodology To Date

[Anonymous Coward]

Now listen here, I've Project Managed enough projects and have extensive experience with the likes of Joomla, Hadoop in both Cowboyed and hourly code reviewed modes and Cloud Waterfalling to be able to tell you that Agile with Outsourced Multiplatform Development Methodologies will make your company more productive than it has ever been before. If you're en executive who is sick and tired of having no cred whatsoever, who feels the sting of the eyeball rolls from your firm's alabaster-pedestal engineering eggheads whenever you try to push them in new directions, and who hungers for the approval of the board, you need to hire yourself a hot personal Agile consultant right away. They're easy to find. He might tell you to do some crazy things like sell every other desktop PC, have the developers pair up, buy razor scooters for everyone, and get rid of all the chairs in the conference room, but just do as he says and the software will be filling up your 4GL Cloud 2.0 servers in no time. Do it, and nobody will even be thinking about your expense forms anymore.

Re:Not just SCRUM

[turbidostato]

"Extreme Programming is in itself a form of Agile development (cf wikipedia). SCRUM isn't the only thing people mean when they say Agile."

The problem here is that "agile"'s definition has shifted and, in this case, for very good and sensible reasons: XP is for developers and developers only. The customer has shit to say about programming in pairs, code review or the sursum corda because all a customer is (and should be) interested in is the output.

More mature definitions of "agile" understand this and add the customer as an integral and unavoidable part of the equation in that you can't have "agile" if all what your process can add is going fast and convincingly to a place nobody is interested in being at. Scrum belongs to that second wave that takes that into account.

Did RTA. It doesn't sound too dismissive

[Gimbal]

"[...] Agile, which may not be appropriate for all organizations or projects"

That's fair.

mod-up parent

[ansak]

especially "...if you can't hold a developer for five years, then you have a morale problem that will cause pain..."

never said a truer word. even difficult legacy code can be endured if the company has no systemic negative morale factors.

cheers...ank

Scam?

[matunos]

Because Carnegie Mellon licensing CMM and taking in buttloads of dollars in CMM certifications wasnt a scam. If you reach CMM 5, you're free of software thetans.

You don't need certification or outside training to practice Agile methods. There may be some helpful training services, but they should be about learning new ideas and figuring out how to apply them to your environment (and when not to), not reaching new levels of certification or decorating resumes.

At the end of the day, a company needs to find the process that works for its developers. No process, off the shelf or otherwise, is going to make up for mediocrity or poor morale. Some places will work well with Scrum practices, some with Kanban, others with XP, and some with traditional Waterfall.

If I had to pick a generic characteristic of a development team most likely to lead to success, it would be adaptability.

+1

[Giant Electronic Bra]

Ah, yes, well said.

Think about it this way

[Giant Electronic Bra]

Lets suppose you're a business and you want to build a manufacturing facility that will cost you say $500k. That's a pretty substantial investment. You're telling me you're just going to hand $500k to some GC and say "hey, build me an XYZ on this plot of land" and you expect to walk away and come back in 6 months and magically have something that exactly does what you want?

No, you're going to supervise, and inspect, and you're going to work with the GC and the architect, and the people installing the machinery, and the power company, and all those other people. You simply CANNOT expect a complex project to succeed without that level of constant interaction, cross checking, making sure that when the utility entrance can't be on the west side because the power company will only put the substation on the east side that things still work out. It just doesn't happen by magic.

If you think somehow that a software project isn't EVEN MORE this way than a conventional construction project then you're monumentally misinformed about how things work and frankly you should buy OTS software because anything beyond the most trivial projects WILL fail if you approach them this way. I've been doing this stuff for 30+ years, and I say this with the utmost certainty. In fact, since I have plenty of business from sensible customers, I wouldn't even do business with someone that demonstrated your attitude. You're not worth the trouble. You're a lawsuit or at least a broken project waiting to happen.

Here's what "agile" does that's useful

[gestalt_n_pepper]

You meet regularly to discuss the software features for the release. Everyone complains about the meeting time.
You track progress on those software features during each meeting. The Agile head honcho complains about the progress and adjustments are made.
You regularly change the feature based on feedback and the input of the designers, users and testers who complain about the lousy interface, performance or something else in the meetings.
You know when you're finished with a feature because everyone stopped complaining about that feature.
At some point, you know you've finished all the features because everyone has stopped complaining enough to bother you, and you're ready to release.

That's it. The rest is details. Now pay me $999 for my consulting advice.

Woah there cowboy

[EmperorOfCanada]

I have found that almost without exception the type of person who is huge on over-managing a project is usually a Type A control freak that suffers physical pain when others are allowed to make any decision without running it by them. By far the best companies in the world give many of their employees a huge amount of freedom which allows the employees to thrive and the company to keep top notch employees. Most companies are the opposite and survive despite themselves being larded down with waste products for employees.

Agile programming all comes down to costs and benefits. If you are building a billion dollar bridge much like the last billion dollar bridge with a tight timeline then plan plan plan as the few millions spent planning will probably reduce the number of billion dollar disasters. But if you are building an innovative million dollar software project which is basically bunch of smaller projects where fixing mistakes isn't costly then it is not only inefficient to over plan it but irrational as you can't actually plan research which is what most projects largely are.

What you do is set goals and repeatedly check to see if all hands are rowing toward the goal. It is very easy to watch to see if a lazy git is rowing the other way. If so you toss him overboard and keep rowing. Not that hard really.

Personally my favorite experience on an agile group project is when other programmers do something with such style and innovation that I am green with envy. This sort of behavior brings out the competitor in most people who try to meet the newly raised bar. This is an everyone wins scenario in that even the crap programmer will be encouraged to grow. Oh sorry this is an everyone wins except for the now redundant Project lead, project manager, lead architect, project manager, producer, or whatever the paper pushing position used to be called before he was let go. I am not saying that you have no management control over a project just not a more chiefs than indians situation with layer after layer of reporting structure. You basically have one or two programmers assigned to give fairly regular status reports to someone who is monitoring(not micromanaging) the project to make sure it doesn't go off course.

Never understood agile

[WaffleMonster]

I never understood the benefit of Agile or why anyone would want to go there. If your working on boring small projects which only take time and a lot of typing to complete I guess Agile works. I could see this working with shops dedicated to small scale custom projects.

For anything non-trivial you really need to invest in infustructure and design or you will end up with a patchwork of shit.

Agile seeks to exert pressure away from thinking and design rewarding instead the brainless zombie which makes shit up as they go along. It also encourages use of more modern and exotic language features to cover for the underlying system being a piece of shit.

A good development process will exert no artifical pressure detremental to the overall project lifecycle. Agile fails this test in a great number of domains.

Laziness is actually a virtue the entire point should be to reward those doing the least with least amount of effort to get the job done.

The catch is laziness must be evaluated in the context of the entire lifecycle of the system. Being lazy up front and having to work 10 times harder later as a result means you suck. Being lazy up front and having to hire more people just to support your POS when the complaints come filing in means you suck. Agile encourages people to suck in my not so particularly humble opinion.

biggest problem

[cornface]

Is that instead of encouraging increasing efficiency, agile encourages increasingly inflated estimates.

There are certain types of projects where it makes sense, but they are few and far between.

Agile Programming

[Anarchduke]

Personally, I dislike Agile Programming. Its sloppy. There is a place for it, such as if you need to rapidly develop an app that needs to work, but doesn't need to work well. Its programming in chaos. I prefer an ordered approach to application development.
You need a working utlity as soon as possible to analyze, detect, or whatever you want it to do? Fine, use an Agile appoach. Just accept that what you produce is going to be buggy, and probably with shoddy documentation. Sure Agile can be handled in an orderly fashion, but then it loses the flexibility that makes it worthwhile.
I prefer a slow and steady approach. Its not sexy, but I want my code done well, rather than quickly.

Re:Agile Programming

[ljw1001]

There's nothing in agile that makes the work inherently buggy. If anything, it should be less buggy; (documentation is another matter). Done right, agile minimizes schedule pressure so you should have the time to do the work you need.

Re:slow and cheap

[TaoPhoenix]

You're getting +Funnies, but it's a legit part of the equation.

A thundering famous example is cargo shipping stuff from China. China, as we all know, is the poster country for Non-Expensive, and just to amuse the /. crowd, I'll use the example where a businessman lost $100,000 because his shipment of Justin Bieber dolls took too long to arrive and then they had a haircut that was no longer good.

http://www.dailymail.co.uk/tvshowbiz/article-2046881/Justin-Bieber-haircut-cost-doll-company-100-000.html

The other more harmless example is US Mail's Bulk Rate shipping.

Re:Pilot/copilot anyone?

[mattpalmer1086]

Agile doesn't pamper developers, and it doesn't codify chaos. It's about getting a good quality product built in the face of uncertain requirements and change. In that sort of environment, treating change as an enemy to be resisted is a sure way to build something that no-one really wants or likes, but fulfils the letter of some requirements document agreed way back when. It's not a panacea, but it can work very well. You still need good people.

It makes partners of the stakeholders. It's very lightweight and done well helps to create a cooperative and respectful environment to work in. It's not appropriate for everything. It doesn't solve all development problems. It has very little to say about actual project management, or how to interface itself with project management. It doesn't really say much about how you get your requirements in the first place.

Re: FY2015 is not a promised date

[TaoPhoenix]

Oh, I know this one, this was how Microsoft used to do Vaporware Marketing!

I've heard the legends

[chicago_scott]

Some people say that Agile is awesome when fully implemented, but I've never seen that done. Or met anyone that seen that done. It's kind of like Big Foot.

use the right tool

[A Pressbutton]

This is the same sort of discussion you get with c++ vs php - the question is what is the job.
basically it should be clear to all that if you design,code,test,doc,release,stop - that is the most efficient approach. say this takes an effort size 1
the trouble is that what is released is probably not what is wanted.

under agile effectively you take a small part of the job and design,code,test,doc,release,stop let the customer loose and then repeat.
repeating this process n times for each 1/n th of the project takes more than effort size 1 as even if you never even look at any part of the code previously written, the tests you are adding and running will - and the whole point of agile is that you iterate toward the true requirement so you will be re-working.
the trouble is that what is released at the end will cost more.

please flame me for stating the obvious, but if you know what you are doing, and what is needed you should use something like waterfall and if you do not know what you are doing/is needed, use agile

Glaring Problems with the Study

[Slicker]

Like most with experience in older SDLC (Software Development Life cycle) and newer Agile, my first thought off the headline was "What kind of idiot? What questions did they ask?". As I read on, several glaring problems with the "analysis" stood out.

(1) I see no mention of comparisons with what other methodology? It's just a focused criticism of Agile, implying that other paradigms are far better. The truth is, the percentage of successful software development projects have always been terrible. It started out with something like 90% failure rates and has very slowly improved to this day. Furthermore, the metrics to measure success are apples and oranges. For SDLC, it's that requirements are met. For Agile, it's the same repeatedly until the product is acceptable. In practice, SDLC leads to marking off a checkbox for each requirement and test. Other problems to solve or improvement ideas to make are thrown by the wayside unless they were specified or contractually obligated. No software has ever been completed without the developers thinking, "We could have done it better like ..". Agile provides that opportunity. The quality is better not only in terms of more opportunity to make it better but also in that the customer flushes out all the issues that never would have come to mind otherwise, until it was too late. In other words, an SDLC "success" is a bunch of marked off features and test results on a usually crappy first generation but barely functional piece of work. In contrast, Agile "success" is a more thoroughly fleshed out understanding of the problem and a better fitted and all-round higher quality solution for what the customers wants/needs--not just his first inclination of what he imaged of the same.

(1) They are engineering / cherry-picking to create support for their conclusions. Examples follow:

(a) "Out of over 200 survey participants, we received only four detailed comments describing success with Agile." -- oh really? Just before that, they said 28% reported success with agile. For how many did they receive smiley faces at the end of detailed comments describing success with Agile? Zero?! Geez, then it was really a total flop!!
(b) "Sixty-four percent (64%) of survey participants found the transition to Agile confusing, hard, or slow. Twenty-eight percent (28%) report success with Agile." Also from my own experience, the transition to agile was extremely hard. In fact, it's hard to get people to convert from Christianity to Islam, too (or vice-versa). That in no way addresses the effectiveness of Agile over SDLC/waterfall or anything else, as they strongly imply. It suggests that people do not like moving out of their comfort zones.. people like doing things they way they always have. It's typical human nature... and consequently, they resist and prejudices arise.
(c) Ridiculous levels of outright subjective and judgmental prejudice to the exclusion of any proper measures.. and repeated in different examples of the same, rather than just tallying up the levels of negative personal feelings toward Agile.... I have to say, this sounds very much like a survey given only to managers--it's a typical manager point of view. These are just ignorant and arrogant personal insults. This is not professional at all. Examples follow:
- Survey participants report that developers use the guise of Agile to avoid planning and to avoid creating documentation required for future maintenance.
- We received some unprecedented scathing and shocking comments about the level of competence, professionalism, and attitudes of some members of the Agile movement.
- Be aware that the Agile movement might very well just be either a developer rebellion against unwanted tasks and schedules or just an opportunity to sell Agile services including certification and training.

Maybe

[Giant Electronic Bra]

I don't know all the details of the processes that are used in every place and claimed to be 'Agile', there's all types out there and some are idiots or shysters. At least when you interact with MY process there will be some meetings with the client. The exact details of the product of that can depend on the scope and degree of definition of the project. A client that has its own processes in place and has generated formal requirements is going to be easier to deal with. One that has an itch that has to be scratched and a general basic idea of what they need will require more interaction. Either way we're going to break things down into user stories, probably supplemented by additional material where complex requirements are involved. In ALL cases the customer is going to help decide what each iteration delivers. While many people may THINK they know exactly what they want, it is a surety that some details change, some things haven't been considered, and possibilities for improvements, simplifications, etc will come to light during the process.

I mean, I've put software into space, on mission critical safety of flight level equipment. Even when working with Martin, Boeing, NASA, etc where they have comprehensive SDDs and SRDs written in highly formal language things are never 100% perfectly sorted out. You can have a 1000 page spec that goes into vast detail and will be translated into 6k lines of code, and even then there is ambiguity and need for interaction with the client. There's simply no such thing as cut and dried, ever.

Re:What is Agile?

[foniksonik]

Ugh - Agile is over a decade old.

Re:Not just SCRUM

[julesh]

Err.. XP has had On-site Customer as part of its method from the very beginning. And the Whole Team practice, which means the customer should be involved in all decisions.

Re:Not just SCRUM

[turbidostato]

"XP has had On-site Customer as part of its method from the very beginning."

Then I stand corrected. Thanks, sir.

Old School Method

[sycodon]

The way I was taught is old school but has always served me much better that all these fancy new approaches...which are actually cherry picked and corrupted versions of parts of the old school...

1. Walk in their shoes. How can you hope to provide a solution for their needs unless you really understand their needs...hint, their needs are usually only part of what they tell you.

2. Know where they are going. You have to understand the direction the organization wants to go, because you have to build into your solution the flexibility to get there.

3.Know your self. Don't promise what you can't deliver. Ten years ago, someone might have said having a "Siri" interface is what they want. Some things are not timeline and budget feasible.

4.Live up to your title. Being an "Analyst" does not mean document what they are doing and automate it. Understand what they are doing and why (see #1) but then go the extra step and recognize ways to improve the business process, eliminate unnecessary steps, redirect resources to more productive goals.

5.Analysts are developers and developers are analysts. Good people can do both jobs and can do them at the same time. Monkeys are for writing novels. Every question you have about what needs to be done should be accompanied by "why" it needs to be done.

Half-Arsed Agile Manifesto

[TomsFingerKeys]

My own experiences with Agile have been promising but flawed, and were best summed up here: http://www.halfarsedagilemanifesto.org/

Transition to Agile

[Tony Isaac]

"Sixty-four percent (64%) of survey participants found the transition to Agile confusing, hard, or slow."

Yes, no doubt. Once you've been indoctrinated with the principles of Waterfall development methodology, it's really hard to shift gears into Agile. Remember the first time you saw C++, after years of programming in C? That object-oriented approach was pretty mystifying. But if you stuck with it, you eventually learned the incredible power of classes and objects.

Agile is just as different from Waterfall, just as hard to transition into, but just as rewarding for those who eventually get it.

Lazy? Yes. Devs? No.

[lemur666]

I adopted scrum in my org, but only in response to a product management org that refuse to do their job. We got features masquerading as requirements, we got endless tactical "the customer wants x" requests all while upper management basically was accusing the team of being lazy for not giving them everything they wanted (and more) right away.

So we adopted agile. This let upper mgmt see we were working as hard as we could and it forced PM to decide "what do you want next? What's the minimum viable set of features? Is this more important than that?"

Yes agile isn't a cure all, but it definitely helps dev remain productive in the face of laziness and stupidity elsewhere in the org.

I've also seen a ton of fake agile (we call it "Fragile") where people adopt the buzzwords of agile without considering that good agile takes a lot of work. Fragile is adopting all the bad parts of agile without any understanding of the discipline involved to do it right (track technical debt, and pay it off as you go. Sprints are no excuse to not do long-term planning / grooming of the backlog. Daily stand-ups, where you track impediments are crucial. etc,)

Success with agile only comes if you understand when it's useful (where there's a large amount of uncertainty/stupidity, somewhere in the org)

It helps mask underlying problems (the uncertainty) while still maintaining productivity. But I wouldn't fly in a plane that was designed with agile principles. Uncertainty in a "mission critical" engineering problem kills people.

Agile is a buzzword

[Eskarel]

What that means is that the vast majority of people who purport to use agile, both as developers and as clients don't understand what their responsibilities are, or what the technique is supposed to achieve. Lots of developers think that agile is about not planning and not having deadlines and clients think that agile is about being able to change their minds with no consequences. Neither of which is even remotely true.

The reason that waterfall fails is that people don't actually know what they want, not because it's a bad system, if you knew your requirements exactly up front as a client, and the developers understood what those requirements meant for them well enough to give decent estimates, waterfall would work perfectly. Unfortunately neither of those things are ever true. Agile when done well lets people plan on scales they can actually manage and allows change and unexpected issues to be caught as early as possible and priced in properly. You want your shiny new feature X and it's going to take 3 days to do, then you either have to extend your project out 3 days or you need cut three days worth of something else. You anticipated feature Y was going to take 3 days and it's now looking like 10, well you know that pretty quickly and the client can decide to go ahead or scrap feature Y.

In essence the fundamental idea of Agile is that when you hit your project deadline, you probably won't be finished anymore than you would have been in waterfall, but if everyone has done their job properly and the project deadline wasn't ridiculous to start with, you should have the most important features so that your client can walk away with something that meets their primary requirements.

It often fails because people don't do it well(clients don't prioritize well, developers don't stick to the priorities, or everyone's estimates and expectations are way out of whack), but in those circumstances your project will fail regardless of your methodology.

If you have a client who uses agile as a way to change requirements every sprint, then know your project is going to fail, if as a client your developers are using agile as an excuse to not stick to deadlines or plan anything then know your project is going to fail, if a consultant is promising that agile will fix all your problems, know they're a fraud.

The great big secret of Agile is the same as the great big secret of most of these methodologies, common sense. You run an agile project for someone else the way you'd run any project for yourself, you set priorities and stick to them, this gets better software out the door quicker the same way it does when you're working on something for yourself.

Flawed and commercialized, but powerful.

[ljw1001]

I've spent years thinking about Agile and development in general. I'm no apologist for the methodology: see my post from just this morning: http://deathrayresearch.tumblr.com/post/27257008711/when-agile-jumped-the-shark. Some aspects of Agile are better than others, but overall, the methodology is based on sound principles. Most notably, there are many short feedback loops (unit testing, continuous integration, short cycles, customers on the team) that decrease the opportunity for hidden problems. This is extremely powerful. That it's used to sell services is undeniable, and their are aspects that strike me as wrong, but this is a good methodology overall.

no documentation?!

[AcerbusNoir]

If you're not documenting your code and providing adequate documentation on your feature then you're a lazy programmer regardless of the process your team uses.

I've always said that with PMS Programming

[danparker276]

the Project Management Software is the most important thing, not reading a 200 page book or taking a class in agile programming. My PMS programming methodology demonstrates this.