Playing Politics With Agile Projects (cio.com)

A harsh perspective on agile software development, shared by Slashdot reader itwbennett: Politicians would be utter failures as agile project managers, writes David Taber, and for all the reasons you might imagine, but mainly because they wantonly make promises they have no hope or thought of keeping. But then he gets into the political attributes successful project managers need. And that's where things get interesting because, while he points out that agile was 'conceived of as a way of bypassing bureaucracy and internal politics,' the attributes he says are required for success are pretty much the worst of the political behavior we've all witnessed in our organizations.

For example, "A key success factor for agile projects is the ability for every team member to talk expectations down at every possible juncture. Agile should inherently involve frequent 1:1 contact with users: use that time to lower expectations! Without this habit, the inevitable scope creep and the impulse to believe "of course the system will do X for me" will get you."
His submission ends with this question. "Is it any wonder why users hate agile?"

Comments

FrAgile

[Anonymous Coward]

I am a software dev of many years and now a software dev manager on top of that (still do dev work). Agile has got to go. Developers think that because they're programmers, they're special and deadlines don't apply to them.

The prototypical case against waterfall is BS, by the way. Short, incremental waterfall, with requirements defined by product owners and sales, with set timeframes based on developer consensus and prior work, works extremely well.

Also, and this is THE KEY reason that I'll never accept agile: if your requirements change that often, while there are some businesses where they do, YOU HAVE NO PRODUCT VISION OR PLAN. YOU DON'T JUST RUN A BUSINESS SUCCESSFULLY BY THROWING SHIT AT THE WALL AND SEEING WHAT STICKS. Sometimes that works, but it's less often than not.

Re:FrAgile

[BradMajors]

Different development methodologies are appropriate for different projects. One size does not fit all.

Re:FrAgile

[Anonymous Coward]

I think you mostly think of cases where software, and sale of a "finished" product is what you are working on.
A lot of people work more in areas where software is a support role, where what your software needs to do changes with the problem the main business is facing just now etc. (and there is no sales involved anywhere, and your users are sitting in the office down the hallway).
In one case, you produce a reasonable product and your users and who exactly buys your product will adjust as long as you produce something reasonable.
In the other case, anything that isn't useful for your (only) user (group), is useless. There is no point in following a plan once it's clear that plan will no longer result in value. Obviously you should have a more long-term plan of making your software less prone to this and you will have a significant number of tasks that you can plan without agile just fine, but sometimes you should just go and do what needs to be done RIGHT NOW even if it was the opposite a few days back.
And at least for some that is what agile is about: you do what makes sense, and don't follow the plan just because it's a plan even if it leads you over the cliff.

Re:FrAgile

[Anonymous Coward]

That's sort of true. There are two possibilities (and of course shades of grey between them.. but that can be decomposed into separate bits with these characteristics)

a) you are doing something that has been done before

b) you are doing something new

In case a) then what you are doing is really IT. You will find that waterfall may well work okay as long as you can stick in this region. Unsurprisingly, lots of IT projects go horribly wrong because they fall over into b) for some small part of the project which in the end turns out to be bigger than all the rest added together, e.g. the small part of scaling from 1000 to 100000 users so the whole company can use it. Often though, you can download some libraries from the internet, remake the same software as someone else made before and it will all come out okay and fit your waterfall model more or less.

b) You are developing something honestly new. You have no clue what you will find as you develop it. In this case waterfall will never work because researching unknown stuff takes orders of magnitude more time than reading documentation.

Generally, if you find waterfall is working for you that's either because you are adding yet another set of reporting screens to a pre-existing business information system or because your project should never have needed to be done in the first place and you should just have downloaded the standard package for the job instead of thinking that your company needs it's own special-snowflake package doing the same as every other company already does.

Re:FrAgile

[Todd Knarr]

The problem is that in waterfall both the requirements and the timeframes are set by product owners and sales, with developer estimates of the time needed being ignored. Which is what results in developers getting fed up and deciding that "I'm willing to be accountable for meeting my estimates, meeting your estimates is your problem".

As far as having no product vision or plan, reality is that you can have a very solid product vision and plan and it'll still turn out part-way through that your customers simply don't want what you envisioned and planned on and you're going to have to change your vision and plan. That's what usually causes requirements changes, and the business has to react to that because there's no future for a business selling something the customer doesn't want to buy.

Re:FrAgile

[HornWumpus]

Waterfall doesn't have analysis and planning phases?

You're just wrong, waterfall handles 'honestly new' just fine. Virtually every piece of software used was built with waterfall.

What it doesn't handle is 'constantly shifting demands', but agile doesn't handle that at all well either, nothing does. If the customer doesn't understand the problem, you have an analysis problem, no methodology will solve it.

If the problem changes faster than you can release, the best move is not to automate that part until it settles down.

Agile is just waterfall with all the roles and phases renamed and with a fixed, very rapid, iteration cycle.

Re:FrAgile

[Hognoxious]

Agile is just waterfall with all the roles and phases renamed and with a fixed, very rapid, iteration cycle.

I thought that, and then I thought "surely there's more to it, or why is everyone talking about it?"

And then I figured technology is as prone to hemline oscillation and varying tie widths as the clothing industry.

Re:FrAgile

[Anonymous Coward]

"Short, incremental waterfall, with requirements defined by product owners and sales, with set timeframes based on developer consensus and prior work"

Thank you for identifying your preferred work style as Agile, or more particularly Scrum, where each of your "short waterfalls" is a Sprint, Product Owners and Sales are Chickens and your developer estimates are applied to all work based on both consensus and prior work (they give away those decks of cards for a reason)

You are either a magnificent troll or clueless, either way I salute you AC

Re:FrAgile

[HornWumpus]

That's not waterfall. That's 'off the cliff'.

Re:FrAgile

[ohnocitizen]

I am a software dev of many years too. "Deadlines don't apply". The problem is - over and over - business assumes code is instant. So requirements slip through the cracks. And deadlines remain in place. Would you rather ship a broken product on time, or delay so the developers have what they need? Don't call it agile if you don't want to - but to ignore the reality of software development is bone headed.

Re:FrAgile

[phantomfive]

Fred Brooks famously pointed out that, "If you have a small team of competent developers, any development methodology can work." 'Competent' here means largely soft skills: things like being able to plan, and reach your plan on time (or recognize when the plan will be behind schedule as soon as possible). Agile is fine, but not-agile is ok too.

Actually I've been reading through a lot of Agile consultant training lately (had to go to the training myself, too), and I see a clear divide. Some of them are focused on process.....they say, "here follow these steps and everything will turn out well." Those are garbage. The other one is focused on improving the skills of the developers, basically teaching them soft skills (here's one example). Those work better.

Re:FrAgile

[Anonymous Coward]

Short, incremental waterfall, with requirements defined by product owners and sales, with set timeframes based on developer consensus and prior work, works extremely well.

You realize you pretty much just defined what agile recommends... right?

So you're agreed: agile works very well. Why would you then state "Agile has got to go"?

Re:FrAgile

[drolli]

As somebody who worked in agile projects:

The good side:
* If the customer had no f*****n idea what they wanted, at least they could not act like they had and the failure was due to the dev team.

The bad side:
* Instead of taking complicated issues seriously, settling to a well-defined and engineered solution, writing hundred times a variant of "hello world" was the preferred way of presenting user stories to the customer because then "we have something to show in the end of the sprint". This was going so far that the developers had to hide work on the underlying code infrastructure from the product owner.

Re:FrAgile

[sjames]

It's all iteration. Waterfall is a special case where the iteration count is one. Agile is a special case where the iterations are arbitrarily short. In some of the most successful projects, the length of an iteration is determined informally in the planning phase based on logical stopping points. The rest is largely window dressing based on the principle that all teams and all programmers are exactly alike.

Managers (especially the MBAs that have never programmed) tend to like waterfall and Agile because it lets them stick to hard fast rules. Managers that came up through the ranks and kept current will be more open to variable iteration.

Re:FrAgile

[sjames]

Typically the planning phase comes before a contract signing or something

That's the giant failure right there. Essentially that work is done speculatively and for free. This means it's goal is to get the contract signed even though it is supposed to be get the software designed. Anything not directly contributing to getting the contract signed will be half-assed at best. Then once the contract is signed, since the analysis and design is "done", everyone jumps into coding to a woefully inadequate design and it devolves to cowboy coding.

Re:FrAgile

[0100010001010011]

YOU DON'T JUST RUN A BUSINESS SUCCESSFULLY BY THROWING SHIT AT THE WALL AND SEEING WHAT STICKS

How do you think the rest of companies operate? Large companies like Ford, GM, VW, etc do that all the time. New engine emissions requirements? Run 5 programs in parallel until one of them works. (Or in VW's case, fake it and try to make it)

Re:FrAgile

[HornWumpus]

Except that's not how it works. Nobody, not even beltway bandits, can afford to do the analysis for free. If they don't know what exactly their problem is, the contract is time and materials. With milestones around completing the design.

Re:FrAgile

[PaulRivers10]

As a developer I disagree with your language and tone but feel exactly the same way about needing a different solution. In my experience agile makes managers inneffective little tyrants. Managers with big ego's thinking they're a special little snowflake trying to pretend programming is a place where you can come up with a simple 6-8 hour chunk of work every single day that gets accomplished with no bugs and no unpredictable behavior day after day week after week. LOL. As an experienced developer, I know that of 10 tasks, 7 will go well, 2 will take extra time or cause bugs, and 1 will be a total clusterf!@#. But with a longer cycle, I can do a decent job of time estimates to have the extra time in there where I know things will go wrong. I don't have any idea which task it will be beforehand - I just know if will be one of them. With Agile the manager once again has a big ego freakout when task #4 ends up taking 4 times longer than the other tasks. Well boo-hoo - we've been doing this for years, and it happens every time. You just don't know which task it will be that causes the web page to stop working for no good reason, or triggers a compatibility issue on the server because they setup the jvm wrong, or works fine in Firefox but doesn't work in IE because of an IE bug - etc. Just because your manager's huge ego means that he thinks that if we just say some inspirational sayings every morning and tell him everything is going great, that that's suddenly going to make all of our tasks easy and predictable and will magically remove that bug that pops up because John's calendar library uses getById, but Tom's page puts a name on the firm, then Thales updated the html header type, and the page doesn't work when I add a calendar to it in IE10. The managers ego is sooooo offended by that - why isn't your task done in my neat little timeframe? The manager is a special snowflake, that's supposed to make these things never happen any more. At least with waterfall I can somewhat plan out that most tasks will go well, but 1 or 2 will be a nightmare and average them out in the schedule.

Re:FrAgile

[HornWumpus]

One further thing.

In waterfall (as practiced), when a design flaw is identified the process goes back one or two steps to design/analysis before dropping back to coding. You aren't forced to code to release before updating design (just as you constantly go back to coding from testing). In a working group, those 'formal steps' are just within the team, but do generate updated design documents.

Re:FrAgile

[Anonymous Coward]

You don't sit there 'imagining software'. You sit with the client staff, examining their current process and sort 'essential' things from 'things they've always done that way'. More often than not you have to learn a bunch of stuff about the industry. Then you have to understand what about the process is currently broken and how a computer will fix that .

Or in other words you "imagine" software and how it will fix their problems. You certainly, from what you have described, don't create it and test it. More or less the only difference between that and agile is that in agile you try to actually deliver a simplified version of that software quickly and see if it actually does help solve the problem as expected. This is similar to, but different in important ways, the old idea of delivering a prototype version of the software.

Have you ever worked on a commercial software project?

The agile manifesto is a pretty useless collection of platitudes. To deliver working software in the real world, you have to follow old fashioned waterfall steps like 'testing'.

If you are doing "testing" as a separate step you are stuck in the past. You have to automate it completely and integrate it with your build process.

Agile as practiced, isn't. It's an excuse for PHBs to feature creep and never, ever plan anything. PHBs will use agile as an excuse for giving out partial specs when they know better (so the coders will build them a simple system first, not knowing the model is broken).

This I find hard to disagree with. Almost any bullshit is named "agile" and PHBs and developers go around making a terrible mess. As a simple, easy to spot criteria, if you have gone more than two months without an attempt to deliver real software to real users then you are not doing agile according to the agile manifesto. This does mean that there are projects which simply cannot be run in a purely agile way. It also means that I probably wouldn't qualify most of the projects you are describing as agile.

Back to your question, "Have you ever worked on a commercial software project?" - yes. A number which really matched your description and a few which really matched the "Agile" way of doing things. Maybe the manifesto should be platitudes, however having watched the difference between the two, all of the bad projects failed to follow some of those platitudes. The most obvious being "people over processes". Sometimes things seem obvious until you see people ignoring them and realise that they aren't obvious to other people.

The first part of the Agile manifesto referred to 'motivated enthusiastic individuals' (para from memory)...those people are well paid. If a company pays 'industry average' it _cannot_ be agile (per the manifesto).

Again, hard to disagree with. There can be exceptions - young programmers might be enthusiastic but underpaid - and sometimes in a startup they could be doing something like agile. Generally, however, most of the industry is obviously not doing agile if you just read the Agile Manifesto clearly. I'm not even talking about the "no true Scotsman" definition of not doing agile. I'm talking about in your face obvious opposition to the basics of the Manifesto and every development methodology that ever claimed to be agile.

Re:FrAgile

[Anonymous Coward]

The "agile development methodology" is nothing but a farce and a cover-my-ass strategy for incompetent software and engineering practices. Throughout my career in information technology I has always used a test-driven approach coupled with proper analysis and design beforehand. If any manager or coworker ever told me Agile must be used for a project I would ignore them and get back to productive work.

Test Driven Development is part of XP - Extreme Programming which is the archetypal agile methodology. It sounds like you are being told to use Scrum, but with the person telling you not knowing the difference between Scrum and Agile. Scrum was actually developed before and separately from Agile. XP was the first Agile methodology. Only later did people start to confuse Scrum with Agile (since the Scrum people wanted to get on the Agile bandwagon).

Re:FrAgile

[golodh]

Waterfall works really well when you have a big coherent system to maintain with all kinds of long-distance couplings in e.g. the software architecture (what should the software do and what not, which part does what, which parts provide services to other parts), data-structures (field definitions, encoding schemes, tracking id's, etc.), database engines, database consistence rules, timing requirements, etc.

You really really don't want some SCRUM team messing around with those.

And yes, Agile is superior to Waterfall when it comes to adapting software to en-user requirements that can be accommodated within the constraints imposed by architecture and application-server and application-application interfaces and have only "local" implications.

It absolutely helps if coders can talk to their users directly instead of through a layer of architects, analysts and designers. But you have to constrain what they can talk about.

Re:FrAgile

[HornWumpus]

I know a dude who makes really good money by breaking consumer products. He's just really good at 'being an idiot' and finding ways that consumers could break prototypes.

UI testing just can't be automated, (just the 'correct' tab order for controls is tricky). Testing for conditions not in the test cases can't be automated until they are found. Test datasets grow with time due to human intervention.

It's always the tricky, poorly thought out edge case that blows your schedule. They are mostly found by human testers. If you rely entirely on automated testing, your users are your only human testers.

Re:FrAgile

[Aighearach]

YOU HAVE NO PRODUCT VISION OR PLAN. YOU DON'T JUST RUN A BUSINESS SUCCESSFULLY BY THROWING SHIT AT THE WALL AND SEEING WHAT STICKS.

You miss the point of Agile. The point is, the developer is a contractor. The client companies are all run by Pointy-Haired Bosses. They have no product vision or plan . Agile is a system for the contractor to prevent that from getting in the way of the contracting. They can throw whatever at the wall they want, they're paying for it.

As a longtime software developer, this is why I am not a contractor anymore. Real products that are part of a vision... need the same "modified waterfall" that was being used successfully by companies with products all along. But indeed, it does a poor job when providing consulting services to PHBs.

Re:FrAgile

[Aighearach]

Waterfall is a special case where the iteration count is one.

That isn't actually true, it is just an assertion by the anti-waterfall people that usually goes unchallenged.

Even the canonical waterfall project, engineering a structural bridge, contains multiple planning iterations before getting to the implementation. The iteration of the whole project is one, but that is true for agile too; if you ever accidentally implement all the requirements, you've finished. The only "iteration count" that is "one" is one in both situations; there is one overall project that somebody somewhere probably actually wants to be finished eventually.

The only difference on iteration count is that in Agile, even after you've been through the planning and started to build the things you planned, you go back and change the requirements which means you have to throw away a bunch of what was already implemented. That is good, because... weekly billing cycles. There is no real argument made that changing your mind about the details at that stage is good; the claim is that Agile is good at billing when that's what the decision makers want. ;)

Re:FrAgile

[Aighearach]

When I was a consultant, I always set the estimates of the time it would require. That was part of the bid. There is no client time requirement, the client requires an estimate as part of the bid and they will select a bid. In waterfall, the bid is likely to include multiple planning steps and be a full-price realistic bid, and it may even quote a total project cost. In Agile, the price is per week, and there are simply no promises or "quotes" allowed to be made about an overall project. Planning is also by the week. One baby step at a time. One step per week. However many weeks it takes to get somewhere. So, it is very very different. The only situation where the "product owner" sets a schedule is when they hire employees. And they don't need to listen to estimates, they need to measure and predict based on those measurements.

The part that I find funny is that people without a good plan manage to hire consultants without having agreed to a plan. If the plan sucks, that should be addressed in the bid; they almost certainly passed up bids from people explaining what their problems were, and giving a bid on fixing those problems and building a quality product. Instead they choose the bid that says, "anything you want, for however long you want, pay us by the week." It could be 10 years later with no product and they would never have actually failed at anything specific.

If a client wants a bid on a magic pony, and I want to submit a bid, it is going to be for a game or an animated short, I'm not going to bid on, "magic pony by the week, however long it takes."

Re:FrAgile

[Aighearach]

According to this classic, you just need to make estimates, and measure results, and then you can normalize the values and make good predictions of actual time.

http://www.joelonsoftware.com/...

Re:FrAgile

[phantomfive]

Yes, and that is really frustrating to me, personally. I always do my best estimate, and then add some time for padding. When I finish right on my estimate, my boss is happy, but I secretly know that I've gone over my true estimate!

Re:FrAgile

[cwsumner]

Yes, and that is really frustrating to me, personally. I always do my best estimate, and then add some time for padding. When I finish right on my estimate, my boss is happy, but I secretly know that I've gone over my true estimate!

You make estimates that turn out to be off by a predictable amount. You add a "fudge factor" to the estimates to correct for the error, even though the reason for the error is not yet known. The estimates end up within tolerance. 8-)

Sounds like Engineering to me. The better you get, the smaller the "fudge factor" needs to be. Eventually, some scientist will figure out the reason for the error, if you haven't done it first.

"Keep truck'in!"

Re:FrAgile

[david_thornley]

When well done, Scrum can be Agile. You do have to take the process less seriously than I've seen in some places.

Re:FrAgile

[phantomfive]

The estimates end up within tolerance.

Worse than that, I finish at exactly the end of the given tolerance!

Re:FrAgile

[minstrelmike]

The main reason I like Agile-style development is sometimes the programmers have a chance to finish the task before the users change their minds.

better idea

[Gravis Zero]

how about managers stop playing games and start treating their teams as people rather than "assets".

Re:better idea

[Anonymous Coward]

"Our office employs only the most beautiful programmers with plentiful assets. Your interaction with our programmers will be a highly enjoyable experience." --ISV marketing after the software industry specific AI singularity.

What is needed: kill competing projects

[Anonymous Coward]

Observation from an orginization that "moved to the cloud"
Developers and managers flock to solve the easy problems
There are far too many projects attempting to deliver the same outcome
Despite having processes to document and discover projects mangers and developers do not use them
Leaders of groups duplicating work claim "are effort is just different" (actually it isn't)

Agile What Now?

[Trails]

If you're doing "Agile Projects" or have "Agile Project Managers" you're not doing agile. Agile is a set of PRODUCT methodologies. If you assemble a project, identify scope, get seed funding, kick off, and then decide to delivery you're project "Agile", you've missed the key point of agile: adjust priorities in response to change.

I get why people hate "agile", it's because most people haven't done the real thing. https://www.youtube.com/watch?...

Re:Agile What Now?

[Anonymous Coward]

I get why people hate "agile", it's because most people haven't done the real thing.

Many years ago I was talking to a person who was going on about communism and how the U.S. should embrace communism as being superior. And I said to that person "Look at China and the Soviet Union. How can you say that communism is desirable?"

And their response was "Oh, that's not *REAL* communism"

Such is the case with Agile. People don't like Agile because they have lived under Agile and they know what it's really like.

Re:Agile What Now?

[HornWumpus]

In the real world Agile is more often an excuse than a methodology.

Re:Agile What Now?

[scamper_22]

This impacts much more than Agile.
The modern day is amazed at the success at 'science'.

If only we had:
-evidence based policy
-agile projects
-no politics
-transit systems based on reports ...

And 'ideally' it is true most of these are great if you're dealing with competent, well meaning people, honest, cooperative people all operating within that system, you'd get amazing results.

But of course, that is the whole question of humanity isn't it?
If we all operated by those traits, we'd have utopia regardless of Agile or not.

And we don't operate inside that system in isolation.
Business, QA, Product, accounting, portfolio management, sales, architecture, security, finance... are all there. Like it or not, most of that is still project based; much more suited to waterfall and heavy upfront design.

Agile, like evidence based policy or the rest above... cannot and should not be used to escape humanity. You cannot escape politics.You cannot escape 'the public'. You cannot escape You cannot escape the struggles for money and power.

Since developers, like scientists are pretty bad when it comes to games of power/politics (as I am), the result is predictable when you throw in a game of Agile that is essentially, putting you directly in the ring.

You have to have some strong leaders that have created a company of Agile for it to work. Most often this from the company founders building in that way or a really really really strong company wide initiative. If you don't have that, you're going to end up worse than Waterfall. You're going to end up in a mess.

Re:Agile What Now?

[Hognoxious]

Well so is communism.

Hey, roman_mir, GTFO of my account!

Re:Agile What Now?

[phantomfive]

-evidence based policy

That doesn't always work fwiw

Re:Agile What Now?

[david_thornley]

There's a difference, though. There are successful Agile shops. There are no Communist countries that have turned out well. If I could point to China and the USSR and say "that's bad Communism" and point to another few countries and say "that's good Communism, because these countries are free, democratic, and have thriving economies", I'd be more in favor of Communism. Given the lack of such countries, I'm sticking to my belief that Communism can work for a very few thousand people, for a generation or two, given a charismatic leader and a certain amount of isolation, and is bad if it's imposed on any larger scale.

The problem with agile is "proof it works."

[gestalt_n_pepper]

I don't think it's bad, exactly. I've worked in a shop that has been using agile for about 5 years now. Before agile, we had good releases and bad releases. After agile, we have had good releases and bad releases. I certainly *like* aspects of it, like daily meetings, limited goals, being two weeks from something shippable, etc. But my *liking* it is different from being able to prove, quantitatively, that it's much better or worse than any other software development method.

Re:The problem with agile is "proof it works."

[Snotnose]

If you have daily meetings your manager is a moron who doesn't know how to manage.

Re:The problem with agile is "proof it works."

[Pseudonym]

My problem with agile is the daily meeting crap.

Meetings are a necessary evil. The fact is, you're working with and for other people, and as such, you need to know what's what.

If it's a choice between daily short meetings or weekly long meetings, I'll take the short meetings any time.

Re:The problem with agile is "proof it works."

[Lotana]

I got into computers because I don't want to be around people.

This used to be true, but no more. The age of solitary developer working in isolation is long gone (If it ever existed at all). Developers need to understand the business requirements, communicate with wide variety of stakeholders from all business levels and work together as a team. Politics, clear verbal and written communication skills, and people-skills are all mandatory requirements for anyone in this industry.

You may find the environment you seek doing open-source development or perhaps (Rarely) some entry-level positions.

Re:The problem with agile is "proof it works."

[Ash-Fox]

If you have daily meetings your manager is a moron who doesn't know how to manage.

You're a moron that isn't familiar with Agile methodologies. From his description, it sounds like his team are using a variant of scrum Agile and I should point out that in the case of scrum, the team manages it self, the manager is out of the way or plays the role of product owner, which has a very limited influence on meetings.

Re:The problem with agile is "proof it works."

[Ash-Fox]

Agile was thought up by lonely insane managers who finally thought up a way to force people to talk to them.

In my experience, most managers seem to want to avoid the daily stand ups, even though they're supposed to be just 15 minutes at most.

MAKE UP YOUR MINDS

[PopeRatzo]

Can someone tell me how "agile" went from being an adjective to a noun? I accept that I am behind the curve, but why didn't I get the memo?

Is "agile" a management approach, an IDE or simply a word that's made the evolutionary leap from adjective to noun all on its own, like "chubby"? I feel so lost when a term is used without any explanation in the summary. Remember, not all nerds are corporate software developers, thank god.

Re:MAKE UP YOUR MINDS

[david.emery]

"Agile" is -whatever you want it to be-, and that's part of my problem with it. There's no real normative definition that can be used to distinguish 'agile' from 'not-agile.' And whenever you push back at 'agile' asserting it is not meeting its promises, you get told "you're doing it wrong."

So at the end of the day, "agile" means not having to do anything you don't want to do (see 'technical debt')
 

Re:MAKE UP YOUR MINDS

[Anonymous Coward]

Where I work, Agile means 50 people sit around a conference table for an hour (at least) watching the project manager fill out a spreadsheet.

I myself keep my brain from dying during this by writing limericks and praying to ancient gods for a merciful death.

Re:MAKE UP YOUR MINDS

[PopeRatzo]

"Agile" is -whatever you want it to be-,

So basically, like every other corporate management fad since WWII. Got it.

I'm still old enough to remember when managers were reading ancient Chinese texts like the Art of War or Tao te ching (or rather, were reading books written by hucksters who claimed to have read the Art of War or the Tao te ching) and brought their newly-minted Oriental WisdomTM to their workplaces.

God, it sucks to have to work at a corporation for a living.

Re:MAKE UP YOUR MINDS

[Anonymous Coward]

Can someone tell me how "agile" went from being an adjective to a noun?

A bunch of guys found that their software development was going quite well and wrote the agile manefesto to explain and gave it a name "Agile Sotware Development". After that lots of people wanted to pretend that what they were doing already was the same thing. They all claimed that "Scrum is an agile methodology" and that "this is agile". Needless to say they deeply perverted the main aims of agile.

Re:MAKE UP YOUR MINDS

[fustakrakich]

God, it sucks to have to work at a corporation for a living.

Just take the money and run...

Re:MAKE UP YOUR MINDS

[Cpt_Kirks]

Which is why the good Lord made laptops.

Hackaday is not going to read itself, and I have beer serving devices and homemade vacuum tubes to construct.

Plus, webcomics.

Re:MAKE UP YOUR MINDS

[trjonescp]

"Agile" is -whatever you want it to be-, and that's part of my problem with it.

My favorite definition doesn't prescribe any rigid methodology rules at all, but rather a set of values[1]. In fact, one could even follow a waterfall methodology and just make some adaptations in the spirit of some of the Agile Manifesto values.

[1] http://www.agilemanifesto.org/

Don't blame Agile...

[QuietLagoon]

...For example, "A key success factor for agile projects is the ability for every team member to talk expectations down at every possible juncture. Agile should inherently involve frequent 1:1 contact with users: use that time to lower expectations! Without this habit, the inevitable scope creep and the impulse to believe "of course the system will do X for me" will get you."...

I am not a fan of Agile, but the excerpt I quote is blaming Agile for what should be a routine conversation among users and developers. Of course, users have high hopes and expectations, they don't have to write the software, they only have to come up with ideas for new features.

.
It is then the responsibility of the developers, in conjunction with the users, to prioritize those expectations within the constraints of the current business. This process is not limited to Agile, it is a part of every development process.

Re:Don't blame Agile...

[tomhath]

writes David Taber..A key success factor for agile projects is the ability for every team member to talk expectations down at every possible juncture.

That's really dumb. The proper response isn't to lower expectations, the proper response is to give the user insight into the trade-offs of a new or changing requirement. Increase the budget? Reduce scope somewhere else? Extend the schedule? If the new requirement is more important that something else, let the user make that call.

The eternal meetings...

[Anonymous Coward]

My problem with Agile is the stand up meetings. I have been at places where they go for 2-3 hours a day, with people doing little each day, and using "Wah, I'm blocked" as a way to blamestorm and shift responsibilities to other parties. I could be doing a -lot- more with my time than hearing some other person talk about their stuff, what they did today in detail, down to how many times the HANA developer shook her weewee in the restroom, what their aspirations are tomorrow, and "what have you done tomorrow" questioning.

With 0 productivity getting done during a stand up meeting, at least 25-35% of the the day is shot to hell in the finger pointing session.

Re:The eternal meetings...

[Pembers]

I have been at places where they go for 2-3 hours a day, with people doing little each day, and using "Wah, I'm blocked" as a way to blamestorm and shift responsibilities to other parties.

Then you're doing it wrong. Our company is officially agile (though really it's more like waterfall with daily status meetings), and the meetings rarely last more than 15 minutes. If person A says they're blocked waiting for person or team B to do something, we can normally trust them to sort it out themselves. Sometimes the scrum master will set up a meeting of just A and B (plus himself, to keep them honest), and then report the outcome of that to the rest of the team at the next stand-up meeting.

To be fair, I have been on agile teams where the stand-up meeting would last 30 to 45 minutes and tended to turn into a design meeting, with two or three people doing most of the talking. This was either because we hadn't understood the requirements well enough at the start, or had just got lazy and not done enough of the design upfront. The scrum master should've set up a separate meeting for the design work, or just told the rest of us we could leave once the design discussion started. I suspect the reason he didn't was because he was partly responsible for the design, so it was convenient for him to have just the one daily meeting. (Or he was coming up to retirement and had stopped caring about not wasting other people's time...)

Now, if someone is constantly using "I'm blocked" as an excuse to not do any work, that's a matter for their manager, not the team or the scrum master.

Re:The eternal meetings...

[Dutch Gun]

You used past tense, so I hope you're no longer at such a place. Even so...

Holy crap... hours? Did they realize the entire point of making the meeting "stand up" is to encourage people to keep the meetings extremely brief? Did they actually *stand* through those entire meetings? I hate the kindergarten mentality behind it, but I'm all for keeping meetings as short as possible. If a team can't even get that right, then no methodology is going to help. It's critical to keep the number of participants down to reasonable levels and keep the information *very* succinct, which some people admittedly have a hard time with.

If anyone listening is involved with such hellish meetings, you need to start holding your meetings standing on one leg, or perhaps in some awkward posture that can only be held for about 10 or 15 minutes. And bring a two minute timer. No individual report should take longer than that.

I'm pretty sure I'd just walk out of a meeting like that after 20 minute or so, or else bring along a laptop so I could get some actual work done. I suspect I might not last long in such an environment. Fortunately, I haven't had to.

Re:The eternal meetings...

[Hognoxious]

I've been in meetings where it started going that way, and the boss suggested (i.e. told us, but nicely) to sort it out later among ourselves.

"Shall we report back?"

"To me when you're done, short summary to the group next week."

And then we finished the rest of the agenda and went to the pub.

Re:The eternal meetings...

[Pembers]

True. Fortunately we haven't found it necessary to limit an individual's speaking time - we just accept that some will be terse and some will be verbose, and it usually averages out. I sometimes deputise for our scrum master, and when I send him a report of the meeting, it's very rare that anyone gets more than one line, no matter how much they said.

Re:The eternal meetings...

[Aighearach]

That's what always saves Agile. If you have problems, it means you're not doing True Agile.

It can easily leave onlookers thinking that Agile isn't very agile. Maybe it is just too hard to be practicable?

Re:The eternal meetings...

[Pembers]

You could say that about a lot of things, but yes, Agile does seem to have more than its share of "you're doing it wrong."

The notion that if you have a fixed release date, you should sacrifice features for quality, seems counterintuitive to many. It's much easier for a sales or marketing person to say, "Our next release will be on this date and have these features," (and leave unsaid, "But we have no idea how good any of them will be.") than it is to say, "Our next release will be on this date, and we don't know yet what features it will have, but we promise they'll all be really good!"

Re:The eternal meetings...

[david_thornley]

I'm going to suggest that more people get Agile wrong than get a lot of other things wrong. One thing that hurts Agile is that it's fully buzzword-compliant nowadays, which means that it's a lot more tempting to have some sort-of ill-defined process and call it Agile than to call it Waterfall. Moreover, the Agile Manifesto doesn't translate well into typical management-speak, and the whole concept is not really well-defined.

Re:The eternal meetings...

[Pembers]

Good points. It sounds, then, as though the majority of people who are doing Agile wrong will only stop doing it wrong when the next shiny buzzword-compliant methodology comes along, leaving the ones who were doing it right still doing it.

But does it really work?

[l0n3s0m3phr34k]

If the process works better than others, should the users hurt feelings be a reason to abandon it? Unless you just handing users some beautifully finished product and don't ever have to "bother" them, their going to "hate" anything that involves any additional work. End-users originally hated the Start/Taskbar. Users hate changing passwords. Users hate IT in general. Mac users "Hate" windows. But if a process actually works better, is more efficient and delivers better than others, screw 'em. At least that's what my inner BOFH says lol.

Management

[mycroft16]

We use Agile in our office and for the dev team it works pretty well. Our problem comes from the management not actually having a clue about software development, despite our best efforts to educate them. We still deal with insane feature creep from above and delivery promises before we've even been informed of the new feature.

Re:Management

[PPH]

I've fund that it helps to think of management as an implementation of UBI. Paying someone regardless of whether or not they do any constructive work.

Playing down expectations on video games...

[__aaclcg7560]

As a lead video game tester for three years, I had to talk down the expectations on the delivery schedule. The original schedule is based on what it would take for the developers to get every milestone bonus on time without any inevitable delays taking place. I usually add a month to the original schedule and a +/- two week window for code release, and my schedule have proven accurate nine out of ten projects. (The sole developer who submitted a 256-page design doc — most design docs are promises on napkins — got their video game done on time.) The developers always get pissed off when I remind them that I don't get bonuses and I'm not obligated to care about their bonuses. Most of the inevitable delays come from them trying to get their bonuses instead of fixing the problems in their code.

Re:Playing down expectations on video games...

[phantomfive]

(The sole developer who submitted a 256-page design doc — most design docs are promises on napkins — got their video game done on time.)

That's an example of BDUF.....Joel would be so happy.

Re:Playing down expectations on video games...

[Hognoxious]

I believe that is called a perverse incentive. One of my favourite mannijmunt konsepts.

Re:Playing down expectations on video games...

[Ash-Fox]

As a lead video game tester for three years, I had to talk down the expectations on the delivery schedule.

I used to e-mail this picture to some people when I got fedup of trying to manage expectations.

Most of the inevitable delays come from them trying to get their bonuses instead of fixing the problems in their code.

Heh, I'm used to seeing people treated like shit in consultancy and nobody has an expectation of bonuses.

Re:Playing down expectations on video games...

[NormalVisual]

The developers always get pissed off when I remind them that I don't get bonuses and I'm not obligated to care about their bonuses. Most of the inevitable delays come from them trying to get their bonuses instead of fixing the problems in their code.

Maybe the bonuses should be tied to code quality instead of schedule, or some combination of the two.

Half agree

[raymorris]

I absolutely agree that the Agile theory that you don't find out the requirements before you begin work is stupid. Over the medium to long term, without a plan you end up either doing work and then throwing it out three months later, or constantly working around earlier decisions, ending up with a system full of duct tape hacks. That creates unreliable systems that are difficult and expensive to maintain.

Artificial deadlines are just as problematic, however. Properly designing and building a system with certain requirements requires a certain amount of time. That can't be changed by management fiat. Regularly attempting to complete projects in less than the required time can only result in one of these three results:

A) Projects are frequently not completed on time.

B) Shortcuts are used regularly, duct tape that makes the next project take longer, while compromising reliability and security.

C) Workers are frequently asked to work long hours, resulting in turnover as well as the same problematic shortcuts as b).

Once in a while, there is an externally imposed deadline - taxes have to be filed by April 15. In such cases, you can either limit the scope and only do as much as you have time
to do, or choose from the three failure modes above.

Pretending otherwise may appear to work for a while - the product is delivered. However, by shorting time, the work was necesarily shorted - testing wasn't done, code was copy-pasted from Stackoverflow without understanding what it actually did, or perhaps to make deadline the programmers used code you have no license to use. These things will come back to bite you.

The way to quality software, reliable software that can be maintained with reasonable manpower, is to recognize that it takes as long as it takes. You can rush it no more than you can rush the growing of crops. Is this inconvenient for management? Absolutely! And the job of management is to figure out how to get the best possible results from real world, non-optimal conditions.

  In fact, software development management requires talent because not only can you not dictate how long it will take to achieve a predetermined set of requirements, you can't even reliably predict it! Development is a process in which most of the work moves along at a steady pace, but the trouble spots can take unpredictable amounts of time. Yeah, that makes it hard for management. That's why management is paid five times as much as production - because they have the skills to deal with uncertainty on a significant scale.

Re:Half agree

[Anonymous Coward]

I absolutely agree that the Agile theory that you don't find out the requirements before you begin work is stupid.

So I'm going to AC this one... at work we're doing a project where 2.5 years out of 3 has been dicking around with the spec. Or rather creating lots of wordy documents, fancy presentations, flowcharts and magic boxes that supposedly solve problems. No developers were involved, because we were not in the development phase. The first month of the "development" project I spent ripping the spec apart saying we need design choices, not vague descriptions of many ways to accomplish the same thing like data acquisition, push vs pull, replication vs xml messages, nothing was decided. Just a magic box that would get the data from them to us, to take one example.

We're supposedly "agilish" but the first four sprints have already been planned by our project manager and only the last one delivers a product, it's not agile. It's just really, really bad waterfall. I can assure you that if we 2+ years ago just got permission to start doing anything, we'd within a few months have prototyped up a few more solutions and made way more decisions based on facts and feasibility instead of now when the whole thing is based on conjecture - by people who won't be doing the coding. Best part? On Monday I'm going to announce my bits on the first sprint will be delayed, the ones still refining the spec doesn't have the list of fields we'll so there's no message format so I can't finish the receiving code. Which means we won't receive data as expected so the whole plan will fall apart.

I'm not saying Agile would solve all our problems, because there's no much dysfunction here... but a waterfall project can deliver fuck all in 3 years and that's okay. If an Agile project doesn't deliver anything that can be considered Done, even on a tiny fraction of the functionality in 3 months, I'd call it a failure. And then we could at least fail early, before all the architects and visionaries and early project managers have moved on to create the next disaster leaving us with the clean-up on isle we're-so-screwed. And my project manager is of course trying to make shit roll downhill by pushing us to make something of this mess because we're going to fail, the only question is how badly.

Re:Half agree

[Dutch Gun]

You talk about throwing work away as though it's a bad thing. My experience tells me that the first version of any complex piece of software or software component you try to create is going to be garbage anyhow. Maybe it would be better to count on calling your first try a prototype, learn the hard lessons about what doesn't work and why, and then scrap as much of it as you need and write version two with the lessons you gleaned from the prototype.

The problem with detailed planning is that there's simply too much you don't know until you get into the meat of a problem and run into unexpected design or technology issues. You just can't plan in your initial design for those because those are unknowns. Only your second iteration can possibly account for those previously unknown factors. It's hard as hell to throw work away, but it's far more painful in the long run to work around fundamental problems that you wish could have been solved earlier in the design phase.

Beyond that, though, it sound like you've got experience with a work environment that has a lot of issues beyond any methodology problems. Long work hours, poor quality control, lack of reasonable management... no magic formula is going to fix such an environment besides a fairly radical shakeup of the company culture.

Re:Half agree

[Lotana]

You talk about throwing work away as though it's a bad thing. My experience tells me that the first version of any complex piece of software or software component you try to create is going to be garbage anyhow. Maybe it would be better to count on calling your first try a prototype, learn the hard lessons about what doesn't work and why, and then scrap as much of it as you need and write version two with the lessons you gleaned from the prototype.

In my experience, this never goes down well with management. The expensive development team has spent the last four weeks doing something that now will be thrown out and redone. All in the name of "quality" that the client will never appreciate (or indeed know about) in the short term. Not to mention the deadlines on which the upper management signed off on to the client. Really, the management will rather ship mostly working "garbage" now and meet the deadline, rather than spend the time to throw out the prototype and write it properly.

I hope like hell that my experience is the exception and not the rule.

 

Re:Half agree

[Dog-Cow]

Or, if you know you don't owe anything, you can file whenever the hell you want, because there is no penalty. (The fine for late filing is a percentage of the taxes owed.)

Re:Half agree

[Aighearach]

All in the name of "quality" that the client will never appreciate (or indeed know about)

This is the difference between having a client, and being a professional. It is easy for consultants to become sleazy, because the incentives are often misaligned due to the pricing structure.

This is why it is better to have employees writing software. They won't save money by writing something that sucks, they'll just have to fix it. They'll plan to throw the first idea away, and they'll talk about it as a prototype from the start. It will be part of the original plan do testing and additional planning before writing the actual software. Consultants can do the same thing, they're just gone by the time it matters and so they don't "have" to care.

Re:Half agree

[Hognoxious]

Silly question - why don't they stagger them through the year, by something like birth/founding date?

Re:Half agree

[david_thornley]

On the largest agile project I've been involved with, we started by refactoring some pretty basic elements of the system. ("We have A, B, and C, which we're special-casing in the main code. Now you want to add D. We're going to pull a lot of that stuff out, make a class that knows this sort of things, and we'll have subclasses for A, B, C, and D.") It worked great, and had management approval.

I like working here.

(We kept adding on E, F, and G, and split A and B into two. If we hadn't done the refactor then, we would have had considerably more trouble later.)

Re:What we really need is bigger butts

[umghhh]

This is just about the only thing that can help - big butt.

Re:You're doing agile wrong!

[Lije Baley]

-1 Offtopic for mentioning Scrum. This is a discussion about agile methods, not one about a religious cult.

Meanwhile back in the real world...

[Hognoxious]

the proper response is to give the user insight into the trade-offs of a new or changing requirement.

They don't want insight into ... ummm ... whatever it was you just said. They don't understand whatever it is you said, and they couldn't if they tried, because they can't be bothered.

They want a pony. You're just a goddam secretary (why don't you just type faster) and they'll go crying to your boss if they don't get it by this afternoon.

Re:Meanwhile back in the real world...

[tomhath]

Yes, they want a pony. Which is why you tell them they can have the pony, but they have to trade the puppy to get it. Everyone understands budgets and schedules. If you just tell them you're too incompetent to develop what they want they'll believe you and offshore the work.

Re:Meanwhile back in the real world...

[Hognoxious]

Everyone understands budgets and schedules.

No they don't.

If you just tell them you're too incompetent to develop what they want they'll believe you and offshore the work.

You equate not being able to do the impossible by yesterday with being incompetent? I take it you're a user. The kind one who acts like a child if he can't have a pony *and* a puppy.

I award you zero points, etc.

Agile was just terribly named

[NotSoHeavyD3]

I mean I think I get where the agile dogma was trying to go but they decided to make something they could sell to business higher-ups and by doing so gave management just enough room to completely fuck it up. From what I can see what I consider agile is really 4 principles

Talking - Yes, both sides (the person that wants the work and the one doing the work) really need to talk to each other regularly so we don't have somebody going off for 6 months and coming up with something nobody wants. (That also means the one that wants can't be silent either

Trust - Both sides have to believe that the other knows what they're doing because if they don't everyone is screwed. (That means no micromanagement. I'm always surprised how often people doing agile fuck this one up.)

Respect - Don't waste either sides time or resources. This is in opposition to talking but the point is if you want your developers to do their work don't waste their time with tech support. Builders also shouldn't waste the owners time with stupid question about minutia.

Reflect - every so often go over what did and didn't work and what could be done to improve and you really need to act on those things. (For example I've worked at places that didn't automate releases and didn't really want to check if this was a problem even when we brought it up.

Anyway in most cases what's called Agile is really cargo cult agile. (It looks like agile but things are done for the wrong reasons.)

The primary purpose of agile

[Anonymous Coward]

Is to sell books and consulting about how to implement agile.

Nobody has found a silver bullet for software development yet. The endless hype cycles around different methodologies like agile spring from the desire of non-technical management to systemize programming so that low-skill, low-paid labor can be organized in a repeatable way to produce consistent results.

That's why agile in particular is so focused on short-term planning and incremental results. When you constantly roll over your programming workforce to the next group of fresh-faced college grads, nobody is capable of long-term planning or real design.

Building roof before foundation

[nerdyalien]

I worked in an Agile house for 4 years.... and went to local Agile meetups regularly. Overall, my opinion about Agile is bit.. hmmm.. Fragile!

Firstly, Agile is good at getting half-baked products out of the door. Two (2) week cadences, where features to be build, demo and shipped is quite narrow... and you get time to barely test it. Yes, you can demo it is working, but it is the tip of the ice berg. How the feature interact with other features or infrastructure is the iceberg what's below the water surface.

Secondly, Agile is good at sweeping hard work under the carpet. For an example, because there is no centralised architectural thinking or planning, every developer goes wild and build their own architectures... half of them are duplicates doing similar functions (and not to forget, poorly tested). Things like database or API designs generally takes lot of planning and thought process. By design, Agile doesn't allow such lengthy ventures.

Thirdly, Agile not scalable. Agile works best for smaller website projects.. say 5-6 page dynamic websites. If you are to do a huge mission critical project involving 100+ templates, 20+ devs so on... Agile will fail half way point, and you will have to downgrade to Waterfall, and pretend you are doing Agile to your client... which method I christened as "ScrumFall" (after James Bond movie).

Overall, I promote "prototype, maturity and ship" model (I don't know there is an actual name for this). Basically, try out prototypes first.. if it works, then promote to regular development, and finally production. I see JavaScript & C++ language committees adopting a similar work cycle. Overall, they are doing pretty well IMO, with regular releases and good quality.

Re: Building roof before foundation

[Anonymous Coward]

I beg to differ ... A year or two ago, we delivered a large server project on time and with the best quality in my company's history - 12 agile teams worldwide. You can do it if you do it for real, not just window dressing

Re:Building roof before foundation

[Cpt_Kirks]

We sent to three week sprints, to allow extra time for QA.

Which means we cram even MORE CODE onto QA the last few days...

Re:Building roof before foundation

[Ash-Fox]

For an example, because there is no centralised architectural thinking or planning, every developer goes wild and build their own architectures...

Doesn't like something you could do in SCRUM or Lean Agile unless you weren't following them properly.

Thirdly, Agile not scalable. Agile works best for smaller website projects.. say 5-6 page dynamic websites. If you are to do a huge mission critical project involving 100+ templates, 20+ devs so on... Agile will fail half way point, and you will have to downgrade to Waterfall, and pretend you are doing Agile to your client... which method I christened as "ScrumFall" (after James Bond movie).

I've successfully used it on massive teams with fewer issues than waterfall, V model etc. in my consultancy life. I think your experience of Agile has not been wholesome based on your descriptions.

Also, yes, I have seen Agile done poorly a lot. But, I see Waterfall, Prince2, V-model, Extreme Programming etc. done poorly as well.

Re:Building roof before foundation

[Ash-Fox]

We sent to three week sprints, to allow extra time for QA.

Decouple manual testing from your development sprint (make sure you a proper CI with test automation in place and strict TDD/BDD policy. Failing TDD/BDD implementation fails that functionality).

Have your QA team manually testing the solution delivered one sprint behind to deal with issues like pesticide paradox through the use of session based testing. This also means the QA team will likely be able to perform more extensive testing.

Which means we cram even MORE CODE onto QA the last few days...

Yeah, that won't be an issue on my advised testing approach.

Two approaches to learning requirements

[raymorris]

> it is impossible to find out the full requirements before you have tried putting out some code.
>... emphasis on the word "full"

You may never fully understand all of the users' needs and desires. There are three approaches to handling that:

A) Ask the user's manager what the requirements are.
B) Walk over to the user's desk and watch them work for 30 minutes, asking questions.
C) Guess, then build the minimum thing that might address some of the requirements.

It's well known that option (a) doesn't work. It's frequently tried, and rarelt effective.

With option (b), I might get 90% of the requirements up front, and have those in mind from the very first moments that I start thinking about a design. I'll also get a rough idea of what categories of additional functions or requirements may come up in the future. Often, I see how the requirements could be simplified by removing a redundant or unnecessary part of the existing process. The point is, I get 90% of the requirements up front.

With option (c), you design and build something that meets 10% of the requirements. When you try to deploy it, you learn about another 10%. So you scrap it and build something that meets 20%. You try to deploy that and learn about another 20%, so you shove twice as much functionallity in wherever it will fit, creating a bit of a mess. You deploy that and find out about another missing 20%, so you pile that 20% on top. Then you learn that the 40% that's still missing is the important part, so you rip out the guts, keeping the gui, and shoehorn the new guts into the old gui. Now you meet 80% of the need - still less than the 90% you could get the first time by sitting down and watching users work before you design anything. And your 80% code is an unholy mess from shoehorning new stuff in at each stage.

Agile = Lazy

[Cpt_Kirks]

Agile was conceived as a method for managers to get more work out of developers for less money.

However, as most manglement techniques are, Agile has been turned on it's head, and is now a method for lazy developers to do LESS work, while completing more BS "tasks", then blame the "Team" when shit doesn't get done.

Purpose of Business Software

[theshowmecanuck]

The purpose of business software is to support the business. Not vice versa. Businesses requirements have scope and deadlines. Software developers are responsible for telling the business how long it will take to achieve the scope, and work with the business to set the expectations and deliver on time and budget. Business needs almost always involve far more than just the development shop: advertising (which means customer expectations... which can kill a company when it doesn't deliver) and regulatory complianc are two big ones that come to mind. The original AT&T failed miserably to deliver software the FCC said was required to provide cell phone number portability which caused huge fines to be levied against them, backlash from customers, and their stock to drop so that Southwest Bell could buy them out and become the "New AT&T". Development supports the business and agile doesn't support hard set/business due dates.

Agile is the same as always

[rickb928]

I've figured out that the design /production team has these mandates ;

Executive management wants reduced costs.

Product owners want product that is on par with the competition.

Dev team managers (yay, plural) want achievable goals.

I work on a servicing team. I want either functional product or what to tell customers when it isn't.

Agile has changed the time frame of failure from months/years to weeks. Can I define that as success?

The right answer to expectations and timelines

[melted]

The right answer to expectations and timelines: fuck off, it will be done when it's done, but we'll do our best. At Google this is handled by setting quarterly goals, and then watching them whoosh by when the quarter ends. Or not, in this regime things often do go faster than expected. The key mechanism that makes it work is the reward structure: Google rewards launches and basically nothing else. Want a bigger bonus? Launch something. Want a promo? Launch something. And so on. And I can personally confirm: you get the behavior you reward, for better or worse. All this daily meeting bullshit would just get in the way of adults doing their work.

Re:What we really need is bigger butts

[Aighearach]

Netslaves never have a nice day?

You should be trying to advance to higher caste in the New Media World Order or whatever they call it now