Agile... is the bubble bursting?

[TwoWolves]

Most of the time it just makes software development run to a sweatshop mentality with throwaway code. Fine for simple projects but complex developments requiring high quality it's dreadful.

People need to understand that there will always be some waterfall activities.

[NickFitz]

"Enterprise Agile" != Agile.

For example, there is nothing "agile" about this, which I first saw used in all seriousness as part of a presentation at a ClientCorp that was "transitioning to Agile" three or four years ago:

Remember, the original Agile Manifesto speaks of valuing:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Hands up anybody who can demonstrate how the above diagram depicts an organisation that embraces these values. Nobody? OK then.

However, "Enterprise Agile" usually turns out to allow many layers of middle management that desperately need to be swept away if any meaningful improvement is to occur, to instead entrench their positions: they are represented in the above diagram by various arrows, icons, and piles of obvious bulltulip.

So I suspect any cull of older managers that results from "transitioning to Agile" is just a consequence of corporate politics as slightly younger management, who have no useful skills beyond a strong line in buzzwords, manoeuvre to eliminate those blocking their progression into the higher levels of the corporate hierarchy. This would have happened anyway; the garbage that "Agile coaches" provide is merely a useful source of jargon to obfuscate their self-serving manoeuvres.

[cojak]

I used to punt myself out as an Agile coach but found it too stressful.

In my experience almost everyone is doing Scrumbut.

As in "We've implemented Scrum, but...."

+1 with DevOps :

You get rid of Change Management because you’ve moved quality to the left - this means embedded quality to the extent that Change Management is a duplication of effort and can be removed.

Not simply remove Change Management and still pump the same old crap out faster.

[original PM]

Most of the time it just makes software development run to a sweatshop mentality with throwaway code. Fine for simple projects but complex developments requiring high quality it's dreadful.

Indeed - in fact a PM friend of mine loves Agile because -

1) When they do their sizing sessions he gets a chance to challenge what is said and ensure effectively he tells the developers how long they should take - he has never written a line of code in his life.

2) He can use the daily scrum/stand up sessions to quiz developers on why these ill defined hazy requirements have not been fully delivered yet - and ask if things can be done quicker.

Both of these are so completely against the Agile manifesto and yet he thinks this is exactly what Agile is.

People need to understand that there will always be some waterfall activities.

Yup if you are going completely into the unknown rapid iterative development is a benefit - if you know what you want and are looking at a commodity piece of software then Waterfall can work perfectly well.

The funny thing we find with our Agile teams is how they laugh at the constraints of water fall - and then insist they have to do a release every 2 weeks - because that is how Agile works.

They seem to be unable to see the irony of the fact they are just following a framework - like waterfall and also - not every useful function can be built in 2 weeks....

(in this case our Agile team simply refuses to build them because then they would not have anything to show at Show n Tell time)

[vetran]

So his premise is Agile is ageist because IBM is sacking expensive(older) workers.

hmmm IBM have been sacking older workers for decades.

Cutting ‘Old Heads’ at IBM


I prefer a mix of both. Phases of the project with proper documentation & sign off, then agile for the tasks. stand ups etc are quite handy.

Sorry I don't believe that quality can be built in by developers when the requirements for success come from the stakeholders. They have to take some responsibility and do the tests.

[NickFitz]

Sorry I don't believe that quality can be built in by developers when the requirements for success come from the stakeholders. They have to take some responsibility and do the tests.

This is precisely why a true Agile team incorporates a "customer representative" (the "Customer collaboration over contract negotiation" bit) - the term "stakeholder" wasn't really part of the vernacular at the time the principles were being formulated, or it would probably have been used instead of "customer".

The expanded version is that the agile team should incorporate a full time representative of the people who will ultimately use the software, and the developers must turn to them both to ensure what they are planning to build is really what is required, and to confirm what they have built truly satisfies those requirements. This is perhaps the most important component of agile development, and is honoured in the observance approximately never

[Zigenare]

I had a client with a "Lean & Agile" mantra for IT, but it really just meant "Quick & Crufty".

I prefer HAYSIMTATMAJLMGOWI methodology: "How about you stop inviting me to all these meetings and just let me get on with it"

Get on with what?

How long is it going to take?

Can we forego some of the functionality for an earlier release?

What the **** is this, this isn't what we wanted, it's what you think we wanted!

[vetran]

This is precisely why a true Agile team incorporates a "customer representative" (the "Customer collaboration over contract negotiation" bit) - the term "stakeholder" wasn't really part of the vernacular at the time the principles were being formulated, or it would probably have been used instead of "customer".

The expanded version is that the agile team should incorporate a full time representative of the people who will ultimately use the software, and the developers must turn to them both to ensure what they are planning to build is really what is required, and to confirm what they have built truly satisfies those requirements. This is perhaps the most important component of agile development, and is honoured in the observance approximately never

Ta, interesting.

Many a project I have been on has stakeholders that turn up for meetings & eat the biscuits, then try to slope off when we deliver, wait for it to be success/failure and react accordingly.

Where we had any "full" time reps they either went native and were hung out to dry by their manager or avoided committing themselves. I liked the former because we delivered good stuff but you couldn't use them again.

I like to nail the jelly to the wall and have specifications, UAT sign offs etc, call me old fashioned.

Agile is great for continuous or single development tasks in a team you can trust.

[jamesbrown]

"Enterprise Agile" != Agile.

Excellent post, I agree wholeheartedly.

[original PM]

We had an SME for the first ten weeks of the 'project' then their manager tried to get them back - saying that we should know everything after having them for ten weeks.

Took quite a bit for him to understand that the SME is there through out the whole process as the person who says what need to happen and then signs off that it does.

This was 2 years ago and she is still there.

Mind you now we are having to spend an absolute fortune (approx 100k per month) having to re factor the whole thing to make it multi tenanted - as when the original was built this was not on the horizon - and chucking code to gather to get usable screens does often leave a bit of tech debt.