If it works for you great. But this 'you are doing it wrong' is at the core of scrum. When scrum doesn't work, is because you are doing it wrong, and never a problem with scrum itself. No true Scotsman and all that.
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.
I feel like various Agile frameworks might be saying “You are doing it wrong” to people using Waterfall for software development. In that case, I would agree. 16 years ago I talked to a project manager who had done PM for a nuclear plant and Waterfall is ok for that, but not usually for software where you learn more from users about what should be done and tweaked as you go along. Perhaps you are just seeing Scrum in places where they are doing Scrum wrong, e.g. adding to it and making it heavy-handed and overbearing.
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.
> people using Waterfall for software development.
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.
"Hindrance to me" is the wrong attitude unless you run the company. Scrum is not for the team to work faster. It's for the teams work to be visible, understood and correctly allocated. I find a lot of devs who dislike scrum dislike being told they have to work on company priorities instead of giving open ended estimates and then doing whatever they want.
What a sad and nihilistic view. Experienced devs are smart people. If you communicate the company targets, priorities and deadlines clearly, they will naturally find a way to self-organize to achieve those goals. Devs think it's micromanagement when they feel like they are not trusted to execute the communicated plans, but are instead required to report every hour worked to some slavemaster who might at any moment "allocate" them to a different task.
Not in my experience. In my experience, if you give the devs leeway, they'll come up with some totally overengineered architecture with the latest tech in it (which is great for their CVs) and will spend a lot of the time bikesheding over nonsense (e.g. killing each other PRs because "too functional" or "not functional enough"). The developers don't care about the company goals, but they care about their CVs and personal preferences regarding languages, tooling etc.
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.
Well I suggest you stop working with colleagues you describe as psychopaths ASAP for the sake of your own mental health. I could never work with a developer who sacrifices the company's / team's business goals for a line in their own CV.
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?
The colleagues in question are all gone now - they got better jobs thanks to the mess they've created in my project...
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).
> 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
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.
> Not one large-sized Nordic bank by any chance? ;)
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...).
the problem exists too in the US due to large amounts of venture capital lying around. Ask yourself why many startups run on K8's yet they don't have the SRE requirements google has. Too much resume padding.
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.
> I find a lot of devs who dislike scrum dislike being told they have to work on company priorities instead of giving open ended estimates
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_.
In Scrum the PO state what value they would like to see in the next sprint. Then the team start to pull in issues supporting that value. If you know that feature Y is going to result in none working software any PO pulling his/her weight will listen to you. After all, working software is more important that a new feature.
Again and again I've gone into the details of people's criticisms of scrum, and again and again it's turned out that they were just not actually doing it. Actually doing scrum does work 100% of the time as far as I can tell.
And on the other hand, you have a lot of testimonies here that say the only places they saw scrum work was when it was adapted to the team, and the ones that followed it to the letter failed.
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?)
I don't think that's a fair assessment. There are definitions of scrum methodologies. I too have worked many places that did not have success with scrum -- all of them had one thing in common, they didn't actually follow one of them. All of them "compromised" with other business interests, and typically the compromise was on the "hard to follow" parts -- the core tenets of scrum! Some of them were 100% waterfall, but with scheduled meetings bearing titles that mimicked scrum processes. These aren't "people doing scrum wrong", these are people in a cargo cult.
I have only worked with a single team that fully followed a scrum methodology, but it was very eye opening and successful.
* 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.
> I too have worked many places that did not have success with scrum -- all of them had one thing in common, they didn't actually follow one of them
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.
Bear in mind I was speaking specifically about following scrum. While agile is flexible and open ended, scrum is a specific way to implement agile, and it has a process.
If, for instance, you’re not doing time-bounded sprints, you are objectively not doing scrum. Scrum has an implementation guide that outlines this.
> 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.
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.