Put down the org chart, snowflake: Why largile's for management crybabies

There's a stink growing out there in agile land: a debate over how to scale up agile in large organisations. Should we put frameworks like SAFe or the most awesomely named DAD in place to scale it? How about LeSS? These "agile in the large" frameworks have been on the ascent in recent years. A 2015 Gartner survey found that …

[Anonymous Coward]

Externalities

I have the feeling that if you look for the best effects of agile, it will be found in projects that involve a limited number of users who want to do a specific thing in a non-agile environment.

and this is where the case studies are performed (funny that).

limitations of agile will be found when _every_thing_is_agile_ .

so every project is continually redefining its interfaces / scope.

In a big organisation, that might not work. In a small organisation, it might - in both cases it will be extra effort from the users (one externality) that really makes it work.

[kmac499]

Heretic Alert.

Heresy Staement 101

"Most Business systems are the same, they capture some data, hold it, process it a bit and spit out a report."

Yes they differ in scale with the amount and volume of data, the speed of processing of the data; but these scaling techniques should over time become a commodity off the shelf solution. Just as no one today would seriously re-create a networking protocol or a DBMS. Plenty of templates exist for the capturing and auditing of data either via terminals or web-pages.

The only real difference between systems is the "process it a bit" stage whetner we are processing Vehicles and People at the DVLA, Accounts and Money in Banks. Customers and Orders at Amazon or any other system you can think of; once the software application shell is in place, The addition of the data processing has always been succesfully implemented by very small teams working closely with the customer, sadly the marketeers got hold of it, named it agile, and are creaming in the money on seminars etc.

Non Business systems, specifically safety critical ones, may well follow a different set of rules. Any volunteers to fly in the first AirBus with an agile only developed flight control system?

.

Please just give me few moments to done the asbestos suit before you hit reply

[Steve Button]

Re: Heretic Alert.

"Just as no one today would seriously re-create a networking protocol..."

like HTTP/2 ?

".. or a DBMS"

Like Redis, Mongo, Hadoop...?

[Destroy All Monsters]

Re: Heretic Alert.

Hadoop is not a DBMS.

Neither is MongoDB for that matter.

[Steve Button]

Re: Heretic Alert.

"Hadoop is not a DBMS."

Is so. It's not an RDBMS. :-P

Anyway, you are missing the point completely.

[Aristotles slow and dimwitted horse]

Agile in a safety critical environment...

I have no problem with the AirBus FCS being developed in an Agile manner. However I do have a real problem with it being TESTED in an Agile manner.

Agile Smagile!!!! It's all a pile of old bollocks, and there is no right or wrong answer when you are actually out there at the coalface actually delivering stuff rather than sitting in a controlled environment such as a lecture theatre or a home office cracking out Agile whitepapers. The foundations required for delivering large successful projects haven't changed in over 20 - 30 years and most experienced managers will pick and choose which method suits the project best based on several learned criteria.

In summary - I find a mix of both Waterfall and Agile works best for larger projects and programmes. WAgile perhaps?

[Ken Hagan]

Re: Agile in a safety critical environment...

"I have no problem with the AirBus FCS being developed in an Agile manner. However I do have a real problem with it being TESTED in an Agile manner."

Agile looks like a plausible way of generating an "actual requirements spec". Its proponents seem very fond of telling stories about how several inches of "analyst requirements spec" ended up in the bin after the agile actually tried out a few use-cases with real end-users. Fair enough. I'm sure that most projects start out with *awful* requirements specs and unless that spec is judiciously ignored by the experienced staff (and not just the developers) the whole project is doomed.

It then probably makes sense to write down in some detail how you are going to prove that the software meets those requirements. If you can't do that, you need to fix the requirements or else you are just wasting your time implementing anything. If this sounds a lot like test-driven-design then you can call it that, but I'm not convinced it is exactly the same thing.

Then you need to actually implement it, but since you've done the Requirements first and then the Design and since the Acceptance Testing is easy (already planned, and quite possibly automatable), the only bit left to do is going to look a lot like a Waterfall process at this point.

[Long John Brass]

Re: Agile in a safety critical environment...

> Agile looks like a plausible way of generating an "actual requirements spec"

Back when I were a lad we called that an "Engineering Prototype"

[Anonymous Coward]

Re: Heretic Alert.

"Most Business systems are the same, they capture some data, hold it, process it a bit and spit out a report."

WRONG.

Inside most 'enterprise' scale business, you'll find complex chains of dependencies which data flows through, even when its been refined down to an optimum few 'golden sources'.

Unfortunately, some level of architectural management is required at that scale, because the level of collaboration required between technical teams across the organisation to coordinate changes is, I don't think, achievable and sustainable to a sufficient degree.

In these sort of companies, breaking the dependencies between systems causes bad things to happen for the business that the technical teams are supporting - quality, timeliness and availability of data is absolutely critical ... unlike the wild west of internet-land from where a lot of these methodologies and frameworks seem to originate.

While I'm certainly no fan of process and bureacracy, I do believe that its important to have a team maintain an architectural overview of the whole constantly changing environment.

[a_yank_lurker]

Re: Heretic Alert.

@kmac499 - I personally believe the key idea behind agile methods is to remove relatively useless analysts from the middle between the end users and the developers. As a corollary, the end users and developers actually talk to each other on a regular basis as the project goes forward to refine what is needed now and what might be nice in a later release. What is happening is too many are focusing on a precise set of rules and not on the key idea - end users and developers should be in regular contact and this contact should be encouraged not hampered. The rules tend to replace the worthless analysts and cause procedural delays.

[Anonymous Coward]

Re: Heretic Alert.

the end users and developers actually talk to each other on a regular basis

ROFL! Over 30+ years in IT, I've yet to work on any spftware development project where more than a few developers were actually capable of meaningful communication with business users! These (developers who could communicate) were the one's who were encouraged to skill up and become "relatively useless analysts" because they could communicate with both users and developers!

[AMBxx]

In 5 years?

In another 5 years, we'll all be tired of incomplete, faulty software and switch back to Waterfall.

Then 10 years after that ....

[Doctor Syntax]

Re: In 5 years?

"In another 5 years, we'll all be tired of incomplete, faulty software and switch back to Waterfall."

And then remember that it was invented as a straw man.

[gv]

Re: In 5 years?

Undoubtedly there will be a new set of buzzwords created each time.

[Champ]

Re: In 5 years?

Yeah, cos waterfall was renowned for producing complete, fault-free software, wasn't it...

[Matt Bryant]

Re: Champ Re: In 5 years?

"Yeah, cos <del>waterfall was</del> humans are renowned for producing complete, fault-free software...." There, fixed that snark for you. Whatever method/fad you choose will fail if you have either a bad team or bad stakeholders involved. I have worked on some very complex software and hardware projects using waterfall that succeeded because the people involved were simply better than the industry average.

[Anonymous Coward]

It looks most of the time now...

... is spent creating new acronyms nobody has ever heard before. Also, add as many as <word>-<word> highlights (goal-driven! people-oriented! pizza-delivery!) as needed.

All of which will magically solve the previous one issues, just you need to adopt a new one every six months. Of course, plenty of consultants to help you...

[Anonymous Coward]

Re: It looks most of the time now...

Is there a sprint defined to do that?

No?

Put it on the technical debt list, you know the one that never gets looked at again.

I wonder how many (fr)agile projects ever look at resolving their technical debt?

The one I'm working on at the moment won't ever get round to fixing all the stuff that was put to one side just so that something was delivered. Not that what was delivered worked but it looked pretty and impressed the end users.

[Doctor Syntax]

Can I be fist to say...

...BINGO

[gerdesj]

Re: Can I be fist to say...

"Can I be fist to say..."

*snigger*

[Khaptain]

Re: Can I be fist to say...

When you are "fisting" I believe that you have the right to say whatever you please....

[ecofeco]

Re: Can I be fist to say...

We just need to check your numbers first..

[Keen1]

Removing the need

"The hope of much of the container and cloud crew nowadays is that cloud automation removes a huge amount of infrastructure, networking and security functionality, removing the need to align on those glide paths"

Putting something in the cloud doesn't take care of security for you, and may not guarantee a common coding approach either.

As an information security practitioner it's good to know I'll have work for life!

:-)

[Anonymous Coward]

Re: Removing the need

I don't know what you've been smoking but the rest of us know with a certainty that using cloud and agile will solve all problems.

DevOps also gives the advantage that at the end of the project not only do the developers walk away but the operations people do too. In my experience the best way to do this is to scatter them across several new projects so it's hard to point the finger at any one person or team.

[Jellied Eel]

Re: Removing the need

Don't forget, the BA's are often the first to flee. Especially if they've found another contract to flee to.

But as a humble user and pugilist, rather than an agilist.. in amongst the foreign language, this bit jumped out- "They started the project with several hundred pages of requirements that business analysts had build up like a perfect cathedral." Usually developed by talking to process/business owners who've spent much of their career developing intricate flow charts that everyone else ignores. So development becomes a tad pointless when the real process is to wander into provisioning/ops and ask for favors, because the actual customer requirement doesn't fit the process.

No amount of agility helps, unless it means being able to kludge code into ever more convoluted messes which you can flee before you have to maintain it. Best example I saw was from a planned sales order->provisioning->ops supersystem and being dragged into a meeting to help with the customer routing table production and maintenance. Somehow, the BA and various other process owners figured it was better for pre-sales people to manually input that and maintain it rather than simply grabbing it off the routers.

That project was abandoned after sinking around $13m when management realised a) The process owners didn't understand their processes and b) it was about as agile as a sumo wrestler in a coma. Luckily I'd managed to flee that one before the axe fell.

[Aitor 1]

Re: Removing the need

Yep, that is the problem.

You have to talk with the user, for sure, but many times the problem is not the software, but the process itself.

[Valerion]

Agile is like sex

Everyone says they're doing load of it, but nobody really is.

[Chris King]

Re: Agile is like sex

Also: One slip, and you support it for life.

[tokyo-octopus]

The real money these days is on spring-sourced bubble-up underpinned by daily jump offs preceding goal-orientated yomps. In larger organisations a jump master is often needed as well as flares being being dropped around the target.

[Justicesays]

Just ignore the non-userland requirements...

"Once this team started deploying software weekly and studying how the user interacted with the software, they learned what was actually needed and changed the requirements appropriately. The team removed the need to "align" with others in their organisation. Sure, there were external systems to cope with, but removing the need to coordinate and take ongoing input from parts of the organisation that weren't close to the actual users speed up the schedule tremendously, delivering months ahead of time."

So, as the users know nothing about security and in the main it just gets in their way, that bit doesn't get implemented I guess? Along with any other "hard but not user visible" requirements.

Had a friend tell me about an application someone in his organization implemented to replace an older piece of infrastructure. It didn't work , and when asked why the development team said they had developed their side of the interface and taken it live, but the other side their team wasnt responsible for hadnt been implemented , so the data just went into a black hole... I guess they liked delivering fast as well...

[Anonymous Coward]

Today's omnishambles...

Take Agile(tm)(c), misplaced sports metaphors droned endlessly by fat middle managers (Sprint? Scrum? piss off, you can't even walk up a flight of stairs without looking like you've been through a car wash), add bullshit dead-eyed consultants, semi-comatose BAs, "disruption", junior developers who've been taught the buzzwords but not the concepts, offshoring, bring in project management based in a different country, disinterested customers who just don't care and don't want to care, crappy open source software bolted together by idiots, senior management trying to re-live their "at the coalface" youth and more cock waving meetings than you'd thought possible where the ratio of talkers to doers gets higher and higher each week, and finally... finish off with monthly PowerPoint presentations with so many spelling mistakes and odd fonts, where everything's sunny, always frickin' sunny.

This is what it it's like to develop in large organisation today.

[Anonymous Coward]

Re: Today's omnishambles...

wordmerchant,

You may take comfort in the fact that it was the same 5, 10, 15, 20 yrs ago.

The jargon may change but the end result is always the same.

There appears to be a critical size of organisation that once exceeded is too big for its own good.

The external consultants then get access and the ability to produce any working useful system is impossible. The ideas and timescales get larger while the deliverables get further and further away from being delivered in a usable state.

Don't worry though there is always another group of consultants who can dig you out of the last mess !!!

[Notice it is always the same 2 or 3 large Consultancies that the job gets passed around. 'A' fails so 'B' promises to fix it all and 'C' is ready to pick up the pieces after that ........ round and round and round we go.]

[Long John Brass]

Re: Today's omnishambles...

> You may take comfort in the fact that it was the same 5, 10, 15, 20 yrs ago. The jargon may change but the end result is always the same.

Preach it brother; Same recycled shit almost the same recycled bucket.

*sigh* I'm too old for this shit, but I have a mortgage & bills so .... back to the coal face :/

[Robert D Bank]

Re: Today's omnishambles...

Laughed so hard some wee came out after reading this! Thank you, time for a shower.

When management simply say 'you must embed agile into everything you do', add it to everyones objectives and suggest 'reading a few books on Agile', then you know they can't even be arsed to understand it, let alone make any effort at all to identify where it's appropriate or give you any priorities. And heaven forbid that they would change any of the 'processes' that prevent real agility and which could be done for free without a host of Vagile consultants hoovering out the company coffers.

[Matt Bryant]

The truth.

".....They started the project with several hundred pages of requirements that business analysts had build up like a perfect cathedral. After throwing this pile of paper to a unified, balanced "two-pizza team" who walked through the user problems and how to start the discovery cycle for solving them with weekly builds, most of the cathedral was dismantled and ignored....." LOL, my guess is either the BAs were crap or the coders ignored the majority of the stakeholders. That is why you need proper project management, regardless of whether it is agile, waterfall or back-of-an-envelope practice, because one of the key jobs of a project manager is validate the requirements!

I have been parachuted in to take over failing projects where exactly what you describe has happened - the agilistas set out to prove they knew more than the BAs and trashed the requirements. They regularly forgot the end users were not the people paying for the work, huddled up to a small subset of the actual stakeholders, and missed a big slew of what the project was contractually obliged to deliver because the end users in question did not know all the business's requirements. In one hilarious case, the end users (help desk staff) persuaded the coders that the requirement (from the help desk management) for a module to gather stats on their performance was not needed! You can probably guess how well that went down when the management sat down to do final acceptance testing.

It is a simple fact of human behavior that you like working with people that you are comfortable with, and coders are renowned for their inability to suck it up and deal with people that don't pat them on the head and say nice things, or just aren't "geeks", hence they often do not talk to the business stakeholders they see as "troublesome". Part of being a good project manager is being able to identify and deal with ALL the stakeholders, not just the ones that you can have fanboi conversations about the latest iPhone or Flash vs HTML5 flamewar.

The idea of trying to run a large program in an "agile" manner is - IMHO - laughable.

[AdamWill]

Re: The truth.

" In one hilarious case, the end users (help desk staff) persuaded the coders that the requirement (from the help desk management) for a module to gather stats on their performance was not needed! You can probably guess how well that went down when the management sat down to do final acceptance testing."

These people are heroes, and will live forever in the Call Centre Drone Hall of Fame.

They were also correct: all systems for 'gathering stats on their performance' are crap and ultimately counter-productive (as they invariably wind up inducing the drones to care more about getting people off the phone as quickly as possible than about solving their problems).

Good story, though :)

[Mellipop]

Flaneur, eh?

You'll be wanting anti-fragile development next.

I heard an anecdote in a Scrum webinar. A customer asked for a process that would scale for a project that needed 800 developers. The Scrum people's response was to ask how they knew the project needed 800 developers.

[ecofeco]

And asked quite smugly I'll bet.

[russsh]

Anti-fragile

Anti-fragile is a useful principle when defining development practices. For example, make sure each bug fix includes a unit test to prove it stays fixed.

[Macandrew]

Methods don't matter very much...

Alignment works well when it happens through circumstance and environmental factors, but not so much when it requires a management process.

With alignment, you also just need autonomy and independence, motivation, capability (skills and infrastructure), and a way of reducing risk and uncertainty - meanwhile striving for elegant simplicity.

For good software delivery, you need to continuously improve these conditions, and they are all linked together and need to be balanced. If you start with an Agile method it will get you some of the way there.

NOMAD - NO Method Agile Development - A method with absolutely no method to learn - book your training course today ...

[russsh]

Cargo Cult

The highly skilled teams have chosen to use Agile.

Those highly skilled teams have three times the productivity of our other teams.

Therefore we will convert everyone to Agile and our productivity will triple.

It's basically the cargo cult fallacy. Have fun building your straw aeroplanes.