At the same time, I have now done software engineering for over a decade, in many roles and teams, and I have never seen Agile or Scrum to lead to the development of a good piece of software. I guess we were using it wrong.
Their manager got an “agile PM” forced on them and it broke.
The problem is charlatans, dictators and career ticket shufflers that deliver little to no ROI and generally abject chaos.
The only time I've ever seen this not happen was when we had a 55 year old delivery manager who viewed his job as facilitating team meetings in a way that meant everyone got the chance to speak and that consensus formed. Didn't try to dictate process or anything, just made sure everyone got heard and that decisions got made. He was patient enough to wait and not force the issues, too.
I still don't understand the role of PMs when there are engineering managers, product owners and self-organizing teams involved.
If it’s not described, and only works via the “minds of a few engineers”, you get amateur treehouse-quality engineering like the 737 MAX.
I guess chance can make it work well like that “once” sporadically, but when you need to touch that code again to maintain it, we go back to the amateur treehouse.
Then the CTO left, and was never replaced, then the layoffs came and a competent PM was replaced with a junior. Entire design department replaced with a single junior as well. Engineering gutted. Ok, lay-offs happen but at least I still have a job.
Then came “we’re waterfall now”. You know what didn’t come with it? Actual planning, documentation or specs or anything typical of “waterfall”. Estimates are now guessed before anything is defined and turned into commitments. You know what we still had? “Daily stand ups”, “backlog grooming”, two week “sprints”, and no retrospectives. No opportunity or agency to try to make things better - just endlessly stuck in my own personal hell.
Now we have projects that are supposed to take 2 months now taking 6. We have last minute spec changes that require massive rewrites because UAT isn’t done until the end of the entire project. “PM is slow to write out requirements” so we’re basically expected to just guess what they are based on very small selection of unfinished design flows.
And of course, executive wonders “why does engineering take so long to deliver”.
I started calling this “scrumerfall” or even ”fragile”. It’s basically the worst of both with none of the positives.
I don’t know what point I’m actually trying to make…just get like ranting and this seemed like a good time lol
What I've seen the most is people putting up straw men in place of Agile, and proceed to attack the strawman in spite of being repeatedly pointed out they are pummelling a straw man.
Scrum fixed that by being as bad as it was precisely defined.
I can get what the originators of agile were getting at but they explained themselves super badly.
I think a lot of ppl forget that.
Just the typical "No True Scotsman" fallacy [1], happens all the time when there is no good defense of the position.
Sometimes the fakes simply do outnumber the real ones.
The Agile industrial complex can't really sell a message to their customers (i.e. managers) that the development teams should have the power and run themselves how they feel fit. This message amounts to "if this works, we can fire the managers". Not a popular message for managers.
So, instead of building on an agile foundation, companies just add some story points and funny sounding meetings on top of the old structure and nothing really changes. It is Agile cosplay.
A manager can start work on this kind of culture shift without even saying the word "agile". They need to give their teams more trust and room to govern themselves. i.e. managers need to get out of the way. When a team is open to the idea of Agile or scrum, then the manager could ask the team if they would like training or coaching. But the ground has to be made fertile first.
OKRs (Objectives and Key Results) have replaced KPIs (Key Performance Indicators) due to some kind of contrived negative connotation that became associated with KPIs over time
But they're the exact same thing.
Something else will replace OKR in a few years so that management can sound as if they're more in tune with the sensitivities of their employees and, yes, OKRs were a bit on the nose, so luckily we've got FCKs now, they're modern and progressive, like us!
How many FCKs do you give?
That can be fixed by defining something new, more precisely.
Asking software engineers to name things? Now you have two problems.
This has nothing in common with the values of the Agile Manifesto. In fact it's more like the opposite of them.
* I hate Jira. Jira is not the cause of the problem. People's desire for a tool like that is cause of Jira. Kill Jira, and it would soon be replaced with something much the same.
By which I mean the project planning committee has created a multi-hundred page document with precise BPM-style workflow charts (based on Jira, obviously), and non-technical managers have started being sent on multi-day training courses to learn how to follow them.
It’s going to be a shitshow!
A Waterfall of effluent, spilling from the end of the process pipe, branded "Agile!" (TM, sponsored by Atlassian).
What are you moving from ?
“We have don’t have assigned desks”.
Agile is Dead https://www.youtube.com/watch?v=a-BOSpxYJ9M
To oversimplify it, he says "agile" has become a noun when it was always meant to be an adjective. In other words, if you are "doing" agile, you aren't really being agile.
Irrespective of the chosen approach, it’s crucial to systematically elicit requirements, document specifications, and rigorously verify and validate everything. Implementation should ideally be supported by thorough unit tests, and, most importantly, all artifacts must be traceable across different abstraction layers and to the required level of detail.
I just don’t use the word Agile. Too many people like it for the wrong reasons, or hate it for the wrong reasons. Everyone has a different understanding of it. It’s just not useful.
If I say “let’s use Agile” it’s just going to lead to arguments and misunderstandings.
Id always rather be more specific about which Agile idea I think will be useful. E.g. “let’s build a prototype before we waste time planning too much detail” or “lets get something built and released so we can learn more about what our customers want” etc.
If this is happening here, this is a good example, as the front page of the Agile manifesto is laconically short, 10 lines of text ( https://agilemanifesto.org/ )
And includes the repeated formulation "x over y" - NB this is not "x, instead of y", not "x, not y" And then clarifies with "That is, while there is value in the items on the right, we value the items on the left more."
If people can read an absolute from that, then they can read it anywhere.
In my defense, I forgot about the fine print on the agile manifesto website.
Leaving aside the "agile is a philosophy, not a methodology" argument, there are well-defined agile methodologies other than Scrum. I've worked at a couple Kanban shops and, while our dev processes were far from perfect, most of the things people routinely hate about "agile" just didn't come up at all because they're actually Scrum features.
If the thing you don't like involves the words "sprint" or "standup," you are complaining about Scrum, not agile.
They keep saying that waterfall just doesn't work, yet almost all commercially successful (and unsuccessful) software is produced that way, whether they claim to use Agile or not. Would it be better if they used "real Agile"? Of course! But you only ever have to be just good enough.
- tell the client to get their shit together
- fire the client
- walk away
