10 years ago, I was a contractor for a small startup using SCRUM. We had literally 4 hours of meetings per/day. Every other week, we had an additional 1 hour planning meeting. I also had to laugh when she decided to add 'water cooler' meetings. We were developers from all over the globe forced to have awkward conversations.
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.
The agile manifesto is a nonfalsafiable commentary on what was the status quo decades ago. The only possible response to complaints about anything done under the guise of agile is that the practitioner did it wrong.
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.
One solution is to avoid using the word "scrum". Since nobody can really agree on exactly what it means the word is worse than meaningless. The word serves only as a conversation trap; many good conversations devolve into defining what "scrum" means--somehow we went from a meaningful conversation to endlessly arguing over the definition of a single word.
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".
> The agile manifesto is a nonfalsafiable [sic] commentary on what was the status quo decades ago.
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.
It's very easy to go against the golden rule. I don't want people to scream obscenities at me so I don't. If I scream obscenities at people and am upset when people respond in kind, it's clear I violated the golden rule
I am seeing a parallel to modern day socialists/communists. Despite hundreds of instances of real adherents to the philosophy really trying in earnest to achieve communism in a wide variety of cultures, geographies and situations, it never works. We know why it works and economists can tell you exactly why it doesn't work. Yet, every new case of communism's failure is chalked up to not being "real communism" or being "bastardized by dictators".
> economists can tell you exactly why it doesn't work
Can they now? It seems to me that the more "exact" an economist gets, the more they should be ignored. Economics is a fiendishly difficult discipline and anyone who claims exactitude should be setting off your B.S. meter.
There are parallels to Christianity or Islam too: if you don't 100% own the brand, it will be coopted by people who will redefine it and confuse everyone. Only the Catholic Church really controls its own brand and can actually define what it even is.
The big difference to communism is that the Agile Manifesto was written from personal experience of having working teams. The Communist Manifesto was wild speculation about how society could maybe work.
I have worked following the Agile Manifesto for soon 13 years and it works very well. No surprise really, as it's just treating everyone like adults.
> Individuals and interactions over processes and tools
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.
ymmv. i was in similar situation and developers moved tickets to "terminal" states without actually trying to address issues, won't write documentation, 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
> 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
Sounds like the VP of engineering needed to get his head out of his ass and listen to the people who actually knew a god damn thing about what was going on.
Did you have a discussion with those engineers as to why they thought it wasn’t needed? Presumably there was a reason, it’s not always (or usually) the case that VP of eng knows more than the ICs.
i had veery long discussions with them for few weeks or so. i was wearing multiple engineering hats. vp was technical and knew what and why was needed. vp was brought in for enforcement action when it started to become bottleneck for other teams. after VP performed "enforcement" they gave estimation of 3 people for 3 months of work. And they wanted to implement half of the requirements and not in a way that were specified.
I went to guy next room, his estimation was 1 week of coding and 1 week of unit/testing/integration/documentation. He ended up been the one who did it
the bottom line that they just didn't want to work. on different occasion same two developers during review of requirements literally said "but to implement this functionality we would have to write a code/work".
Just for a context, this was company where company had gifts for 20 and 25 years anniversary of employment. And this is company that makes software for living. (Not the blue company.)
PS. Just for a more complete picture, that company had "agile methodology department" that had developed internally sprint/ticket tracking system and wiki. those systems weren't linked so you couldn't cross reference things. Project that I was hired to do was given exception from many policies so I decided to get jira/confluence, which despite been universally despised here were light years ahead of what company had. In process I failed to get approvals from it, information security, agile and some other departments. At the end (after 3 months) general manger personally approved it and took personal responsibility for any breaches.
yet, 1 year later I got visit from internal audit who weren't happy that I spent money on system that duplicates functionality of existing system.
PPS. the really funny part, i interviewed with google and was asked to tell how i had organizational challenge or something and how I managed to overcome it. I told this story (about buying jira) and after doing it was asked if i could do something different. I answered that given organizational structure it was the only way to approach. Interviewers verdict was that I am not humble enough because I can't admit that something could be done differently. Hence i am not googley enough and therefor "strong no hire"
it wasn't possible to fire them. and i wasn't their manager.
also, how those devs could be correct if they asked for 9 man/month and the one in next room did it in 2 weeks
If you inflict all that process on any good engineers in your company because of the bad engineers, you'll probably chase them off and be left with only the bad engineers who need all that process to keep them in line.
And what is weird is that processes like those can get justified by the fact that they produce objective measures to terminate bad employees if the violate the process, but in reality its the bad ones that are going to hang around and put up with it passive aggressively.
"bad engineers" were like 75% of project. Fortunately good one were mature enough to understand why those processes happened and didn't complain about it.
also, given company structure it was very hard to terminate anybody. so we were stuck with who we got. and we got for this project "the best and the brightest"
i personally was in company for 6 months. developers had 10-15 years seniority. those processes happened without any connection to scrum, but. this company had mandated scrum that was defined by agile methodology department which developed it's own scrum tracking tools (i made sibling comment about it).
scum-sprints were used in order to avoid making designs and chop things into tiny pieces that were taking entire spring to develop. sprint demoes were "faked" (same demo could be shown for months at a time or there will be no real functionality behind it).
i worked in different company where they hired senior vp of engineering whose resume on linkedin was full of "implemented scrum - improved delivery/quality/etc". so engineering went to do hard core agile, with sprints, demoes that were showing amazing progress and that we are on track for doing everything in time. day before release eng. manager went to him and let him know that nothing works and they need at least half an year to get to half of the defined scope (i warned him about it two months ahead, he told me that I crazy). story ends with C-level appearing on one of the all-hands, calling him aside for a chat. he was never seen again.
so yes, for me, mandated scrum is symptom of the company that I won't go to work for.
You describe valid problems that are reasonably frequent at many organizations, however, literally none of them get solved by a software tool being stricter at enforcing state transitions - all of them require the relevant managers to actually manage people.
it made a difference in preventing things from disappearing without trace. it's not a fun activity to dig through a bunch of closed/won't fix/not a bug tickets to figure out what is valid and what is not
no. but processes provided guard rails. i didn't enjoy it, but sometimes you have to work with what you have. you can't "reeducate" people in their 30s or 40s to be more responsible towards the work that they do.
interesting point though, it's the way that this company works it's that there is core r&d group that builds "framework products". those things never go to clients directly. they go through delivery groups that customize/extend them according to client needs. and fix bugs.
project that we build was the only one that was direct to client and many people simply couldn't grasp that they are now directly responsible for what client gets.
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.
Ok, but can you please make your substantive points more thoughtfully? You broke several of the HN guidelines with this post.
"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."
Is AI being used to moderate comments now on HN? I ask because I don’t find this comment to be particularly moderation-worthy according to most modern standards of flamebait.
Yeah it wasn't my finest moment but I didn't think it was very out of place. I think moderation here is 'flag based' - ie if enough people flag something moderators step in.
I think Scrum might be defensible when used for rare, genuine emergency situations. If a make-or-break the company project with a tight deadline comes along, you might want to change it up with something like Scrum for a short time period to manage that as a reasonable, defensible choice.
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.
> like "Scrum Master" who (IMO) feel pressured to create as much process as possible to justify their position
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.
For the sake of argument, let's assume that you and your Scrum Master peers were all top of the class and genuine in your understanding of development and desire to help facilitate project success and never acted in a self-interested way. That's a fairly big assumption, but let's roll with that.
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.
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.
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.