It was strange as a developer to be paid to be in meetings more than actually coding. Especially in a company with 10 employees.
Eventually, the owner started having fits because we weren't getting anything done on time and she eventually let me go. At this point, I had already started a new business and was almost making enough to cover my basic expenses.
In the call when she let me go, she told me that she could hire 3 people in India to do my job, so that's what she was doing.
---
To quote men far better than I:
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
---
If your process delivers on the above. It is agile. If not. It isn't.
And personally: I prefer agile as stated above, but I have yet to find a SCRUM team I'd work on.
In a status quo where everyone is trying (or at least claiming) it as a guiding principle, any actionable advice is only the interpretation various people bring to their reading of the scriptures.
In these cases, the utility of the manifesto is nil.
If you all agree on the manifesto.. at least you can ask questions, and then see how it all fits together.
IMHO: If the question "why" is outlawed, I'll find another place to work.
The polite way to say this is something like "people have many ideas about what scrum is, can you explain what you mean without using the word scrum, it would help my understanding".
It's not a commentary. So.. you kinda failed already on that point. It's also not pretending to be a scientific hypothesis in the first place so "unfalsifiable" is a weird attack as it's just missing the point.. again.
Last year I joined a company as a VP of Engineering and the first thing I did was to look at all of the meticulously crafted Jira workflows for tickets moving from New to Done, and all of the state transitions in between. There was an amazing level of thought and craft put into those workflows.
I then completely obliterated them and just defined states and let any issue be moved into any state. There was much rejoicing and nothing lost from the process, since the teams regulated themselves to make sure things were documented, code reviewed, etc.
so state transitions had to be added and gates put in place.
it's always joy to work with teams of adults who can self-regulate. but when it's not what you have...
as small example: i had 2 developers telling to vp of engineering that they not going to implement some functionality because they don't see the need in it. For record, this functionality was needed
PS. i described in more details below
It is a tale as old as, well, at least as software management.
We used to make software. Sometimes it went alright, sometimes not. Then someone wrote down a rough idea of different approaches to software projects and gave a simple example of a naive process on the first page. The managers went with that, because iterative stuff looked complicated.
Then, after years of pain, some people wrote the agile manifesto, because it was clear that we were not on the right path. Then some marketing/sales/manager types saw it and figured 'how can we make money of this, without understanding it? Oh, and how can we get those pesky developers out of the room, they are always correcting me when I lying, eh, selling to the customer!'.. And thus we got scrum, it's process and tools over EVERYTHING, but in the color of agile.
Not much different then the blackboard paradox I think. Can find it, but it goes like: A uni uses blackboard. Users rebel, adminstration caves and buys the new, user friendly blackboard alternative. Users settle down, the software get developed further, the company that makes it grows and starts to implement checkmark features for the admins that decide on purchasing. And thus the software becomes blackboard too.
"Welcome changing requirements, even late in development." after a decade in this industry words cannot express how foolish this is.
"Please don't fulminate."
"When disagreeing, please reply to the argument instead of calling names. 'That is idiotic; 1 + 1 is 2, not 3' can be shortened to '1 + 1 is 2, not 3."
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
But I think it's devastating to developer happiness and overall productivity if you're just running as a Scrum forever and have people with literal job-titles like "Scrum Master" who (IMO) feel pressured to create as much process as possible to justify their position. The ceremonies and process are going to grate on developers long-term. IMO, the managers will have a bad long-term sense of the effort and difficulties and progress of each sprint if you're perpetually doing that.
Having been trained and acted as a scrum master for a large tech corporation, this doesn't track with my experience at all. I, and the other "scrum masters" (which is an incredibly cringe term) I knew tried to minimize process as much as possible, and weren't concerned with finding busywork to "justify out position" -- especially because our positions were primarily devs. Being a scrum master was extra work on top of our daily duties.
In my opinion, the problems with Scrum are because of how Scrum works and what management wants to use scrum for. Being a scrum master was what convinced me that Scrum in particular is extremely problematic and that if you must use an Agile methodology, it should be one of the other ones, not Scrum.
And maybe, a really solid big-tech company with great people who "get it" can largely make Scrum work "well enough". I'm sure you oversaw a lot of products shipping successfully.
Was that because of Scrum, or in spite of it and you might have been even more successful doing something else?
Overall though, I think you recognize how Scrum might devolve in many typical situation, right?
PS: To make it clear, no disparagement is intended in anything I said or say even though the consequences of that might seem like an attack on your profession.
Wait till you hear about Agile Coaches™
I was the Team Lead of a team, and I told my management: "SCRUM will not work for our workload. We have too many shifts in priority to plan for 4 weeks at a time."
I was told I could choose any process I needed to get the job done, but we needed a "Scrum Master" to interface with the other teams. I played Scrum Master. I also had the team running on Kanban, which while imperfect, it beat the alternatives for a team that had to shift targets rapidly.
<insert argument how described scrum is not real scrum>
