I personally wouldn't work at a place that didn't do it. Scrum ceremonies are there to get alignment. If you don't do them, you end up working on the wrong things. If these meetings take up more than 1-2 hours a week, then you're doing it wrong.
I have been a professional developer for close to 20 years, 10 more if you count my hobby/learning path as well. All teams I worked that implemented scrum were a hindrance to me and not a benefit. It may work for others and that is fine, but it isn't a silver bullet solution for 100% of the cases.
If you’re on a team of more than a couple people and you have stakeholders feeding requirements to the project, what do you do that’s so different from the simple process of Scrum? It’s just set up to say, hey, we’re going to work on these items for the next week or two, and please don’t constantly come interrupt me in the middle to ask me to fit in a bunch more things than what we agreed to work on in this short time period. Then we’ll show you how it’s working and you can decide what we do next.
Is anyone really doing Waterfall now? Maybe earlier some industries used a Waterfall like process. But actual descriptions of Waterfall seem to go back 50 years to Royce's paper, Managing the Development of Large Software Systems. That model was explicitly described as bad. I don't fully agree with that paper, but his suggested improvements are more iterative. Personally it seems like now Waterfall is mostly used as a strawman.
> but not usually for software where you learn more from users about what should be done and tweaked as you go along
I agree with that. I wonder if Agile is highly influenced by it's leaders being closely involved with consulting.
I have only worked with a single team that fully followed a scrum methodology, but it was very eye opening and successful.
How many of your bad experiences with scrum bent more than a couple of these rules? How many were always followed? : https://en.wikipedia.org/wiki/Scrum_%28software_development%...
Some big things I've learned are:
* Sprint planning has to be mutual. Management cannot plan a sprint on their own, they do not have enough information to accurately plan for order or operations or effort required. Furthermore, participants need to understand the direction and priorities of the project in order to do their job properly.
* You cannot change a sprint that is in progress. Mitigating switching costs are a huge part of the benefit scrum provides. Compromising on this defeats the point of the process. It's hard to tell management "no", but you have to do it. If fire-drills are unavoidable, then you must to account for this time when you plan a sprint.
* All stakeholders must attend backlog groomings and sprint reviews. If the inputs to the process are guesses, then the outputs will be guesses. This is just as important when prioritizing work items as it is when giving feedback on completed items. It must be first-hand. Documentation and/or status updates simply do not even come even 10% close to the power that a live demo does.
To me that approach goes against the original principles for agile, especially "Individuals and Interactions over Processes and Tools". I'm not a huge fan of highly structured Agile and scrum processes. But I think the best agile implementations come when teams have ownership over their own agile processes.
And if the team truly has ownership they are responsible for their success or failure. Sure, their process may be objectively bad, but that doesn't mean a better process should be imposed from outside of the team. The team should have some level of trust to fix it.
I also disagree with your three points being hard requirements. They may be really good suggestions for teams doing scrum, especially in lower trust environments. All three are specifically for scrum, for instance they lose meaning if you aren't doing sprints. But that's just arguing semantics. Fixing compromised scrum isn't strictly necessary if the team can be successful by dropping scrum.
If, for instance, you’re not doing time-bounded sprints, you are objectively not doing scrum. Scrum has an implementation guide that outlines this.
https://scrumguides.org/scrum-guide.html
> While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
Many people borrow ideas from scrum for use in their homegrown agile solution, and that’s ok. But it’s not scrum.
Also, if they team does not deliver, at the end of the day it's their manager who gets the blame, not them - so why should they care? Basically, smart devs are repaying the psychopathy of the typical company owners with a 100% selfish behavior of their own. That's the what I've seen in the wild, not the positive scenario you're describing. Perhaps it's "late stage capitalism" in the flesh.
But it's indeed first and foremost the managers failing not recognizing these attributes in their team members, and not working to fix their attitude (which clearly is the underlying problem here). Imposing more process will not fix the team not caring about the product / business.
If you are not up to changing jobs, I'd suggest you try openly bringing up your concerns in a retro. Unless, you actually don't care about the product yourself either?
Psychopaty is perhaps too strong a word - they're just taking care of their interests. Perhaps in the olden times they were aligned with the interest of the employer, but currently they're clearly not (my employer has just announced that they'll lay off a couple hundred of IT people are replace them with an Indian outsourcing company, purely to cut costs...).
I don't care about the project either, but as a tech lead, I'm actually paid very well by the company to take care of its interests - incl. killing off any wild ideas that the devs might have. This (staying on old and boring tech that works well, but is not what will help me get the next well-paid job) will hurt my career in the long run, but my plan is to actually go FIRE within the current job, so it's not a problem. Most people don't have such plans though and hence they don't benefit from toiling for an ok wage with boring tech that gets the job done.
The underlying systemic problem is of course the fact that the whole industry (at least here in Europe) is crazy about following the latest tech trends for trends sake, and thus running along on the tech treadmill is the best way to get highest compensation. In the US I believe it's different, because there joining a FAANG gets you the most money, and they mostly use custom tech anyway, so they don't care about the latest open source hits (of course, you have to leetcode instead, so it comes with its own set of problems).
Not one large-sized Nordic bank by any chance? ;)
The flipside of using latest tech is you should have easier time hiring new people to replace the ones who left. But I am certainly not denying that hiring devs who are willing to commit to the business is a really hard problem. Companies should maybe focus this more in their hiring practices over just the technical skill profile. Good developers will learn the tech stack in the job, if they care.
Also, people retention / satisfaction is pivotal in keeping the commited people on board. Doing massive outsourcings to India is certainly not a good signal to send to those who feel their skills and commitment could be appreciated elsewhere as well.
I will say no more ;)
> The flipside of using latest tech is you should have easier time hiring new people to replace the ones who left.
I've heard this argument before and it's basically a non sequitur for me. For example, there are fewer people who know the latest and greatest Scala libraries than those who know for example Java 8. The people who have learned Java 8 have not died or retired yet - they are still in industry, in large numbers, and hence it's easier and cheaper to hire them. Whereas you have to fight for the bleeding edge guys - usually by offering them high-paying contracts (which are the reason half of these guys are following the bleeding edge trends in the first place...).
Good luck, if you're a engineer trying to make things work without too much ceremony. everything is about chasing the latest and the greatest, whether it makes sense for the problem at hand or not.
No, what I dislike is being told to go work on feature X, when I know that we’re going to run into issues with feature Y in a matter of weeks, and then having to spend nights and weekends fixing it when it eventually does break, because nobody trusted me to know what was good for the product.
Scrum gives people who have no clue what they’re doing the illusion that they do. The process is literally their only handhold to avoid feeling swept away. Like, I’m doing nothing else right, but at least we are following _the process_.
It can't be both things at the same time. (out of curiosity, you say 100% of the time, how many companies you worked for that did scrum perfectly and had 100% good results?)
Ownership and vision are kind of the point of midlevel and senior roles. If you'd fall off the track in a matter of weeks, something is seriously wrong.
What do you call it if everyone is doing it wrong?