Non Agile Technical Roles

[Cirrus]

Never quite git my head round why regulation heavy industries insist on using it as they can't really change things mid project.

That's not entirely true.

I was working on a super-big programme at a super-big bank which was entirely regulatory and extremely large amounts of money were at stake.

I said "What are the acceptance criteria the Regulator has specified?". The answer was "They won't say. We have to come up with something which is good enough". What's reasonable in that kind of situation depends upon what you discover about the nature and complexity of the various dimensions of the problems as you proceed.

Agile is based on - amongst other things - the fact you cannot know what you want when you start, let alone what you want by the time you go live. This emerges as you do analysis and design. I've worked for many big companies and they rarely know what they're doing. Quite a lot of - although by no means all - people know what they individually are doing but nobody really knows how that all adds up without a special exercise to integrate it.

Probably agile is more relevant in big companies simply because they are so unfathomable most of the time.

[DimPrawn]

And the most important point of them all, regarding Agile/Scrum.

If it isn't plastered all over your CV now, you ain't ever going to get another contract.

[LondonManc]

And the most important point of them all, regarding Agile/Scrum.

If it isn't plastered all over your CV now, you ain't ever going to get another contract.

I wonder if JFDI ever comes up as a methodology?

[stek]

And the most important point of them all, regarding Agile/Scrum.

If it isn't plastered all over your CV now, you ain't ever going to get another contract.

It's not on mine and nor will it ever be!

[The Plantswoman]

And the most important point of them all, regarding Agile/Scrum.

If it isn't plastered all over your CV now, you ain't ever going to get another contract.

You don't have to KNOW agile but the client will want to know that you are familiar with metaphorically playing an endless game of musical chairs.

[LondonManc]

You don't have to KNOW agile but the client will want to know that you are familiar with metaphorically playing an endless game of musical chairs.

Indeed. If they're agile evangelists, you could even make the point that you've worked on supposed agile projects, but they had project managers and no paired-programming. They'll be dying to take you on and show you how it's done properly. #WaysToSkinACat

[ChrisFromGreece]

It's not on mine and nor will it ever be!

Out of curiosity... what's your lead release time?

So by the time you are given a requirement, how long does it take you to release it in production?

[LondonManc]

Out of curiosity... what's your lead release time?

So by the time you are given a requirement, how long does it take you to release it in production?

Surely that depends on the requirement Chris?

How long to deliver a new data warehouse versus how long to deliver a new report from an existing data warehouse for example.

[ChrisFromGreece]

Surely that depends on the requirement Chris?

How long to deliver a new data warehouse versus how long to deliver a new report from an existing data warehouse for example.

If I were to say a feature then I may have been misunderstood... but you are right given how I phrased it.

My point is that even for small changes to be released in production, it might take months under a Waterfall approach. I can see that in my current company where the main platform that we plan to decom follows a Waterfall approach with 4-6 weeks of UAT cycles. One the other hand the new strategic platform, where everything is migrated, follows (we are constantly improving with automated test, full DevOps pipeline, etc) an Agile approach and we release things in production every 2 weeks.

To me the biggest issue with Agile not working is not the Agile methodologies per se, rather than the frozen middle... "you dev teams be Agile and we managers will be Command and Control".

If you are gaming it and you pretend of doing Agile (rather than doing it properly), it will of course fail... I don't see that as Agile not working... I just see it as people not wanting to change.

Bear in mind Agile is all about transparency, something that 99% of the Managers are not keen on given that they are happy giving a weekly RAG status after they have signed off a 500-page BRD.

[TheGreenBastard]

Agile is like communism, in a perfect system, void of human touch, it might work. Sadly from my experience it's invariably a tulip show. Normally I just gauge how "into it" the devs at a client are and just smile along and invoice.

The fanatics are the main pain point for me; they believe it's infallible, any critique is met with "you must be doing Agile wrong then" - which might be the case, but I've yet to see anyone do it "right".