Non Agile Technical Roles

[LondonManc]

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.

Agile is a mindset and if not everybody is in it, it will fail.
It also depends very much on the industry. I've just delivered something that had a nailed down spec from the start. I severely doubt that it would have benefited from an Agile approach, but can see how certain things can be delivered (having been part of an agile team many moons ago).

As you say, those using agile as an excuse not to document what they do will struggle. That said, I'd make sure all code is thoroughly commented so that no other documentation is needed. Declare a standard then you only need to document the non-standard

[ChrisFromGreece]

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".

You can't wake up one day and say "I am Agile"... it takes time, but you need a change in mindset.

Nobody said it's the silver bullet... but you need to be willing to try it and find out what it is.

I think a lot of people don't like it mainly due to the transparency bit I mentioned earlier. A traditional PM signs off the BRD and then provides RAG statuses, which when it goes Amber/Red overworks the team - have seen it on multiple occasions. A PO is involved till the completion signing off features at the end of every Sprint.

At the end of the day Agile and non-Agile approaches both deliver a product. The difference is how!

[ChrisFromGreece]

As you say, those using agile as an excuse not to document what they do will struggle. That said, I'd make sure all code is thoroughly commented so that no other documentation is needed. Declare a standard then you only need to document the non-standard

Who said that Agile means no documentation???

Btw, given I am quite a supporter of Clean Code, I wouldn't want the code littered in comments. Some may be beneficial, but thoroughly commenting the code is a no-no for me. That means that either code is not self-explanatory or the code needs refactoring (too complex design). TDD should be able to assist in simplifying the design

[TheGreenBastard]

You can't wake up one day and say "I am Agile"... it takes time, but you need a change in mindset.

Why? The Agile manifesto is simple - it shouldn't take long at all. It's turned into a monster. Marketers got their hands on it and turned it to tulip.

[Dark Black]

In my experience, "Agile" is waste of fecking time.. managers love it and devs hate it and never get any real work done.. I've seen projects months late because of all the time wasted "sprint planning".

Yet another example of modern software "techniques"

As has been said.. JFDI

[VectraMan]

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".

The point for me is common sense, and the Agile principles mostly make sense in a way Waterfall simply doesn't. But the point is it's meant to be "agile" not a rigid process that you must follow. People who like rigid inflexible processes see it as just another rigid inflexible process to force on everyone without considering what's actually best for the project and the team. "Right" is a successful project, not one where you followed a methodology exactly.

Winston Churchill might have said:

Many forms of software development have been tried, and will be tried in this world of sin and woe. No one pretends that Agile is perfect or all-wise. Indeed it has been said that Agile is the worst form of software development except for all those other forms that have been tried from time to time

[ChrisFromGreece]

Why? The Agile manifesto in simple - it shouldn't take long at all. It's turned into a monster. Marketers got their hands on it and turned it to tulip.

The Agile Manifesto is so simple that most of the people I have chatted to have misinterpreted it.

Prime example: “Working software over comprehensive documentation”

To many that means NO documentation.

The difficulty lies in the transformational complexity and not the actual implementation of it.

[LondonManc]

The Agile Manifesto is so simple that most of the people I have chatted to have misinterpreted it.

Prime example: “Working software over comprehensive documentation”

To many that means NO documentation.

The difficulty lies in the transformational complexity and not the actual implementation of it.

What does that actually mean, or have you just read it somewhere?

[DimPrawn]

Who said that Agile means no documentation???

Btw, given I am quite a supporter of Clean Code, I wouldn't want the code littered in comments. Some may be beneficial, but thoroughly commenting the code is a no-no for me. That means that either code is not self-explanatory or the code needs refactoring (too complex design). TDD should be able to assist in simplifying the design

My last contract, the code review would pull up anyone who commented their code. Part of the agile process was to not comment code, it was seen as a pointer to obscure code and a time waster.

[ChrisFromGreece]

What does that actually mean, or have you just read it somewhere?

That means that the effort to move from a Waterfall mindset and approach to an Agile one is massive compared to actually being Agile and operating as such (the implementation of it).

If you start a brand new project as an Agile project it will go a lot smoother than transitioning one mid-ways from Waterfall to Agile.