Ask HN: Does Scrum work?
I’ve read the Michael O. Church article and quite a bit of other stuff about how bad Scrum and the like are, and I’m trying to find some counterpoint info. Unfortunately, most of what I find when searchig for information on the other side of the coin is from firms trying to sell scrum certifications and training. Are there any devs out there working in a scurm shop who think their team is actually successful because of scrum? Does this actually work from the Devs/Engineer’s perspective or is it as much of a scam/fad that it seems?
31 comments
[ 2.7 ms ] story [ 74.6 ms ] threadHaving a continuously working artifact that changes incrementally according to user feedback every couple weeks is probably a better idea than going from months of documents to months of code to months of tests to your first demo more than year later.
But within the basic paradigm, methodology is mostly a way of describing what you were going to do anyway.
If those guys are still in the mix, they basically want undying praise, accolades and adulation for every twiddle of their fingers. If they open /etc/hosts with vi, they have it in their mind that they just saved the company $15,000 and that a cut of that belongs in their pockets, and also that they’re handsome and clever too.
So, yes. But... you have other problems.
and so does every other methodology
and yes, it's b/c of scrum.
and yes, it's in spite of scrum.
and yes, it's a full on scam/fad, just like every other methodology.
my best guess on where things currently stand is that: 1) most shops use it 2) most shops use it very loosely, at best 3) most shops know to publicly despise waterfall but know that scrum and the rest are just watered-down waterfall and any shop doing near-actual scrum would kill to have a 'waterfall' dev model again -- that is, a realistic dev plan without requirements that change on the hour 4) until one of the new pseudo-methodologies (like design thinking) replaces it, Scrum/Agile will continue to reign supreme (b/c it ultimately exists b/c it is very management-friendly -- it's useful for controlling employees -- not for any other reason like 'productivity', etc.)
From my personal experience, Scrum does work but it requires a team that is competent already. A team of incompetent people will perform poorly in any scenario.
I think it is a fad, most of the people I know who are big fans of it are also fans of whatever other tech fad is going on at the moment i.e. blockchain, nosql, the latest frontend framework etc. I find it extremely unfortunate that SCRUM is so widely practiced in the software industry now, at one point it actually caused me to quit my job to move to a different IT career, though in the end I went back to development because I love coding and I've just had to realise that SCRUM is something I'll have to live with.
There has been plenty written on this subject, here is some more reading:
https://michaelochurch.wordpress.com/2015/06/06/why-agile-an...
http://okigiveup.net/not-big-fan-of-scrum/
Queue the "thats not scrum" responses..
The idea that any project manager can be all that is so dangerously optimistic. And yes, I realize there exists some PM somewhere who proves it is possible to be a good project manager. But the existence of an outlier does not move the bell curve, it's part of the bell curve. Most PMs need to be taught to rely on their devs and product owners so they stop screwing up projects themselves.
There is nothing so dangerous as a bad manager, especially a manager who thinks, "I've got this....". And there are so many bad managers. Scrum helps mitigate this by spreading the responsibility around to the people most likely to get it, not by tossing rules at a team.
Perhaps you are right that good project managers are not too common, however, I find it easier to reason with one single manager than to reason with an entire team who has defined themselves as a "SCRUM team". In my experience the dogmatic nature of SCRUM means that teams take on an almost religious attitude towards it. A team like that is far more difficult to reason with than a single bad manager and disagreemnts often end with the conclusion "Yes but we do SCRUM and SCRUM says to do this.".
SCRUM contains some good princeples which I agree with like iterative releases and attempting to break down stories into manageable chunks, but the reality is that SCRUM is more than just a set of princeples to take on board, otherwise it would not be a multi-million dollar industry for SCRUM consultants and such.
You are right though, SCRUM has its use in preventing bad managers and bad teams from doing bad things. However at the same time I think it hinders good managers and good teams from doing good work.
I think maybe we agree on something. Religious fanaticism can break any good process. I see Scrum as a place to practice flexibility. Example: I have a dev team that is only two devs, a husband and wife team. We don't do standups because they are together all the time and don't need that feedback and daily planning.
I'll be adding someone to that team soon and will need to add some formality so that feedback and daily planning are sufficient.
I have no room for fanaticism in my processes. It breaks stuff.
What really makes a team successful is good people. Good people can make anything work, even if it's a bad system. Bad people can take something reasonable and turn it into a dumpsterfire.
About 10 years ago, when I did my first scrum training, I could practically see the kool-aid being passed around. It is something that worked for someone, so we just needed to do it, because it would make everything better. What mattered more was the higher level managers always making arbitrary decisions against what the line devs knew to be true. While scrum was supposed to empower us, it really didn't, as we managed to have the managers always defining the stories and sprints, and basically used it as a stick to beat us with every 2 weeks. Organizations and people do as they want, and will do it in any framework people propose. A framework like scrum, or a tool like JIRA won't make a bad team a good team.
It seems like every consultant is trying to sell the story of how you can take a non-functioning team and make it a bunch of rockstars with their class. But it never works. You just need to be working with the best people, and that's what gets results.
- If you use Scrum[1] to turn everyone into a cog of a cookie-cutter system that you barely understand/control and that, for some form of deranged reverential respect, you apply mindlessly without questioning anything: No, may God have mercy on your soul.
In a more general sense, everything that is embraced aprioristically (methodologies, frameworks, languages, etc...) has the same damaging effects of a scam/fad.
The fact that most recent converts present Agile/Scrum as "the methodology that saved us from Waterfall!!" like if no one before ever did short iterative development cycles or tracked anything before, reminds me of those who drooled over nodejs for its nonblocking magic and its thaumaturgical webscale capabilities.
More reflecting, less bandwagoning.
[1] Replace with your favorite methodology.
Why do you think it's preferred in risk averse industries? Is the agile-partisan view of the relative risk incorrect? Missing something?
But what people seem to forget about is that waterfall is actually cheaper in those cases where you have a clear understanding of the needs, the end product, and actions and tasks you need to do. This is usually the case in banking - you usually have a box product you need to customize and integrate (the toughest part, and processes are pretty much set (also strongly determined by the regulatory requirements). Hence, most innovations are just automation of specific process steps.
Another thing to consider is that the people in the bank are used to work in this way, so it removes some traction and gets you up to speed faster.
Would you happen to have links to the text of regulation that specifies software development process? The only ones I can think of specify properties of the end result.
In the 'iterative waterfall' you usually split the work into several domains, with each iteration taking months up to a year. E.g. when implementing new core banking system, the first release could be 'move the customer masterhip into the new system'.
Sorry for misunderstanding, I meant that business processes are usually derived from the regulatory requirements, not IT processes. The following implementation is then affected by those regulations - again, in a way that limits potential differences between the desired outcome and implementation choices.
Things move faster now.
Every story is an iteration now.
https://blog.cleancoder.com/uncle-bob/2018/08/28/Craftsmansh...
- 'having a broad vision of a project & being able to anticipate', well, this seems unrelated to Scrum to me, Scrum might work, or not. The biggest error in Development management being 'estimates', which was partly solved in scrum by replacing hours/days/months with bananas/story points, but there is still some equivalence in people head. And estimates are WRONG. I've never been good at estimates, and I keep telling my employers that's not what they should be paying me for...
- cutting a project in small iterations so that budget can be adapted / stopped at any time, and developers kept in check (because management don't trust them) : this is maybe the most compelling use-case for scrum / Agile methodologies.
- having happy & productive developers: well this depends on what THEY like. Some people need structure to feel good, and Scrum can provide that. Others are more at ease with autonomy / being responsible for their work...
Most orgs I've done "Scrum" in have done "Scrumbut" instead: "It's Scrum, but..." and then screwed it all up.
Customization is part of the game for sure, but gutting the core principles to reduce Scrum to a fancy status tracking mechanism doesn't preserve the benefits very well. It's not the right kind of customization, it's neutering. That seems to be such a common antipattern I have to assume it's a gross flaw in the system itself:
The short term compromises are so startling to traditional management they won't wait to measure medium or long term gains, and instead tweak it to death.
This isn't super surprising given that half the process in Scrum (product owners, scrum masters, either finish as planned or scrap the sprint entirely, etc) is to keep management concerns from whipping back and forth by limiting the amount of influence management has mid-sprint. The other half is supposed to make them comfortable with the first half (estimates, feedback, status, burndowns), and predictably is the half most commonly preserved--as overhead without a tradeoff.
So yeah, think it could definitely work in a group that understands it well, and embraces both the flaws they were getting away from and the features they were getting away to. Unfortunately, I rarely see that level of cooperation in an org, so it usually doesn't work very well.
Read it, see if that resonates with you and your team. If you think it does, try it, tweak what you don't like. If it doesn't work, you'll know very quickly.
Regardless of whether it works for you, methodologies are important because they describe a mindset that you may need at some point, and that could help you think outside the box you're in.