Scrum is a cancer
twitter.com
twitter.com
However, the management insisted that we adopt Scrum and get a Scrum Master to help us.
I objected to this and listed all of the problems I could see if Scrum was introduced: losing dev creativity and incentive, tickets taking exactly one sprint to complete instead of doing them at leisurely pace, the mistranslation coming from having one extra layer of communication (Scrum Master handling the client now).
The management response was: "that is not real Scrum, you had bad experiences because you weren't doing it right previously".
After three months, the progress slowed to a crawl, star dev abandoned ship, and customers started complaining for the first time.
Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :)
> Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :)
Oh wait till management finds engineers to scapegoat for their own decisions. If there is one truth about management, it is that they cannot accept "I told you so" from their reports.
In my experience, the only time a company does well with structures is when there are fewer levels in the org chart and when the C-Suite penalizes management before ICs.
Doesn't happen very often though.
So to exaggerate a little bit, not accepting "I told you so" from their reports is directly required to keep paying their mortgage and feeding their children. It's not weird that they get upset when you endanger their livelihood. OP has got the right idea and is just being zen about it IMO.
Perhaps we need to reduce the number of levels, replace managers with technical leaders whose incentives are aligned with the needs of the business. Offload all grunt paper work to an executive assistant.
No need for EM1, EM2, EM3, Director, Sr Director, VP, SVP, SSVP nonsense.
Indeed. I've been thinking about shifting back into management after a couple years as an individual contributor (playing an instrument is fun, but so is conducting a well functioning orchestra). In this space, aligning with stereotypes has become very important in the past decade or so.
Their goal was never increased productivity and developer hapiness. It was literally what they said "introducing scrum and bringing in a scrum master". Their purpose is to add and manage processes (bureucratic layers) and increase their dependants.
Middle managers will always increase headcount so that they eventually can become directors. Oldest game in business.
"The process failed because you didn't have enough project managers on board"
No the process failed because it was fucking shit and everyone went somewhere else.
The only good thing heavy processes are for are propping up employment statistics.
The amount of dancing required for the sake of management in this industry is just insane.
If you don't want to have to talk to customers, which only one developer who I've ever worked with has actually wanted to do, you need a way to equip someone else to do so.
Same thing if you want to keep your investors happy, your counterparts in other departments informed of when they need to have the hardware to pair up with your software ready, etc.
There's definitely such a thing as too much overhead, but developers who just do the things they are interested in without considering that they are part of a larger business are the other side of the coin that you're describing.
1. If other departments need metrics/insights/visibility, why don't they go collect it? As a PM, go collect that information yourself and deliver it to stakeholders? Why does everything need to be done by engineers?
2. When engineers get measured, evaluated and pitted against each other using these activities, it breaks camaraderie. We don't enjoy these activities because we see through the management practices of rating people based on the number of proverbial TPS reports or the quality of the cover sheet or the number of story points completed - none of which are actually important to the success of business but very important to the manager who will just recycle them upwards. Do you really think people are motivated to do this meaningless work?
I love the movie, but damn it hits close to home and I never know if I should laugh or cry.
Most of us are not.
But yes, a team of people that understand the business, and can prioritize well without needing someone to do it all for them, scrum just slows the team down. I've seen it happen multiple times in my career, and sometimes succeeded at either undoing the change, or making the jira-based work basically fictional.
So .... the one you were dealing with was just an average bullshitter pretending to do scrum.
Either way, it was awful, and it was looked down upon to try and find some peace and quiet to actually get things done.
I get that this often doesn't work because individuals don't really grasp their function properly and don't defend or don't prioritise and then that part of the scheme cannot work. Sometimes the company structure makes the POs too scared to standup. IMO that would be a problem without scrum.
Regarding why your team failed - i've been in a similiar scenario like you as a team lead. The answer is simple - no one in your team was open to adopting scrum so it failed. That's fine but it's not the fault of scrum rather than the company management.
> Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :)
If you go into something with the intention of 'this sucks' and then do not even want to make it work would it not reason that it probably will fail?
Scrum usually fails because people become enamored with the process instead of thinking about what that process is for. Layering on more and more of it because something is not working. Until you are busy with 40% of your time just managing scrum. Something in scrum not working throw it out. Do not double down and add more.
we can rephrase this as "the serum didn't work because you didn't have faith in it."
But the GP point is valid. not every iteration can be blamed on "scrum" anymore than anything bad that happens in life can be blamed on Satan. If people want it to fail, they can make it fail.
But that said, to slightly counter my own point: I think that demonstrates a weakness with Scrum. If people following the system (even malicous compliance) can make it fail, then the system is flawed. It obviously sucks for those people or they wouldn't have a bad attitude about it. For example, Scrum likes to pretend that all engineers are fungible, but this is clearly wrong and a big problem with the system.
People are stuck in their ways and don't actually want to try anything new. That's why management always fails- you can't manage people.
Those damn people. Business would go so much better if you didn't have to hire them /s
How do you know no one was open to trying it? I specifically mentioned that I personally objected to scrum, but wrote nothing about other people.
What happened in fact was that people initially really tried their best ti cooperate, but it simply didn't work very well and crippled the team.
Well, if there was a distinct Product Owner and they delegated this to the Scrum Master, it may have been by-the-Guide Scrum, but just extraordinarily poor judgement.
But it sounds like you had a dev team that wasn’t using Scrum, got a Scrum Master and no P.O., and gave the Scrum Master some or all of the P.O. duties. Even as weakly prescriptive as the current Scrum Guide is, that's still not real Scrum.
(Moreover, most places that purport to do Scrum also purport to do Agile, and having a bottleneck between the team and client is even more explicitly not Agile than it is not Scrum.)
Which is not to say your scenario isn’t a valid illustration of problems with Scrum (or Agile) in terms of the (largely cargo-cult) common behavior going under the name.
Its just that in terms of clarity of discussion of what practices should be adopted, its worth noting that the problems being identified are with practices which the Scrum Guide (at the organizational level) and Agile Manifesto (and the broad practice level) are pretty explicitly directed against. Not just in terms of the communication bottleneck but also things like:
> tickets taking exactly one sprint to complete
This seems to be confusing increments or Sprint Backlog items (for which the dev team is responaible for making from Product Backlog items) with Product Backlog items that the P.O. is responsible for (and also Product Backlog items with client tickets, though the Scrum Guide doesn't explicitly discuss client tickets at all — in fact, it mentions customers only once — and so doesn’t explicitly distinguish them from Product Backlog items. The P.O. is free to, and responsible for, structure Product Backlog items optimally based on achieving customer goals, which is almost never realistically going to be 1:1 with tickets.)
EDIT: I want to make extra clear that I am neither disagreeing with the criticism of “Scrum as the thing that I am likely to have imposed on me if my workplace says they are doing Scrum” nor arguing that the Scrum Guide (or Agile Manifesto and principals) are anything like perfect edicts that can only be failed but never fail.
I am just saying it is important to recognize the difference between “this failure is caused by a set of practices a workplace adopted under the label ‘Scrum’” and “this failure is caused by adopting the practices described in the Scrum Guide”, eepecially if you are interested in what good practices might be.
In the same way, I don't particularly care if Scrum fails because people consistently fail to implement it "right" or if it fails because it's a flawed concept at its heart. Either way, odds are that my team will suffer if we introduce Scrum: if Scrum isn't fundamentally flawed, it's still hubris to assume that we'll be the team that finally gets it right.
[0]
> “Listen, if tomorrow we pulled into Biren and someone told you there were shamble-men in the woods, would you believe them?” My father shook his head.
> “What if two people told you?” Another shake.
> Ben leaned forward on his stump. “What if a dozen people told you, with perfect earnestness, that shamble-men were out in the fields, eating—”
> “Of course I wouldn’t believe them,” my father said, irritated. “It’s ridiculous.”
> “Of course it is,” Ben agreed, raising a finger. “But the real question is this: Would you go into the woods?”
“Steer clear of things called Scrum” is a very limited guide to how to develop software, actually figuring out what the methodological pitfalls are and addressing them is something that is, I would submit, worth pursuing in more detail, especially for people who have some influence over substantive development methodology choices, rather than only having a choice of whether or not to avoid some place that is imposing a thing that they call “Scrum”. (And, really, you should probably steer clear of any place where being in the dev team gives you no input on substantive methodological decisions irrespective of whether what is imposed is called “Scrum”.)
I am suggesting that calling it Scrum will increase your risk of failure, and you'll likely be better off choosing a completely different methodology that has more consistency in implementation and a higher success rate.
By all means let's dig into what specific details of the implemented methodologies work well and which don't! But taking the output of that process and calling it "Real Scrum™" will just lead to further confusion.
I’m not saying “Real Scrum™” should be the name of the output. I’m saying that diagnosing the problem is obscured by not distinguishing between “what is in the Scrum Guide” and “what someone is doing and calling Scrum”, especially as the latter can be a diversity of mutually incompatible approaches.
Much less TLDRish, but zooming out to take a broader perspective:
There seems to be an intense agreement with both of the following statements:
1. The practices in the industry that the people imposing them call “Scrum” are often quite bad, and
2. The practices in the industry that the people imposing them call “Scrum” often bear very little relationship to the methodology laid out in any version of the Scrum Guide.
Apparently because consensus is a bad thing and there aren’t enough real issues to argue about, some people who agree on points #1 and #2 seem to have squared off into a weird tribal battle over whether “Scrum” is bad due to #1 specifically that mostly turns on whether or not the One True Meaning of “Scrum”” is the thing they agree is very often bad in #1 or the thing they agree that thing differ differs from in #2. My position is that this is mostly silly, especially since there are very few contexts where both of those things are meaningful to consider: the first is so inconsistent in terms of actual practices that it is useless describe as a single thing in the context of concrete development practice, though it may be interesting to discuss as an industry cultural phenomenon, whereas particular practices or combinations of practices within its ambit can be discussed more productively when the focus is on concrete development practice; the second is specific enough to be useful to discuss in the context of concrete development practices, but not much else, except maybe in terms of its historical role in relation to the cultural phenomenon. With a little care to being clear what they are talking about and the what it is people are looking for from a discussion, the whole semantic side-debate can be avoided.
I appreciate you being willing to articulate an unpopular opinion :-)
did they revert back to the old method, did it deteriorate so fast there was no way to stop it, was the team not very important
what happened ?
i'm obviously turning this into a hypothetical
Rule number 1: management is never wrong. The progress did not slow down.
They said that we didn't measure the work before, so they had no visibility into how much the team does. But after introducing scrum, they were very happy to see that the team usually delivered around 20 story points per sprint, while the other teams in the company did around 10.
In my view, if we estimated tickets in old process as we did after introducing scrum, we would have been delivering around 60 points in two weeks through old process.
If scrum isn't working for you and you're productive, do more of that.
If what you have isn't working, and scrum might help. Do that.
That's the point. Don't break something just because others are doing it.
And that was your big mistake. Those are real concerns, but those things are abstract and non-quantifiable. The proper way to fight scrum is to measure the time it takes to perform the scrum 'ceremonies'. It's rarely less than 30% of the total work time in a sprint. 50% seems to be very common.
In my experience even the dumbest and thick-headed management can understand that. I've always imagined if it didn't I could ask to hire more people to compensate for the time lost, but I never had to resort to that.
Granted, you still end up with a mutilated scrum at the end. But if you mutilate it right, you can fit your pre-scrum work process into the terminology of a mutilated scrum.
I do not understand how this is possible.
* Sprint planning: 2 hours
* Sprint review: 1 hour
* Sprint retro: 1 hour
* Daily stand-up: 15min / day
On a 2 week sprint, 80 hours, that's 5.5 hours spent on ceremonies. That's ~7%.
What are you doing that it could ever take _half_ of total work time and how will you convince management that you aren't completely fucking up scrum?
Yes, we weren't doing "scrum" right, but like communism, no one does it right.
[1] The silliness didn't start until new management took over.
[2] The term "team lead" meant "manager". I didn't get the memo.
[3] I was regularly talking to him at least once a week. He didn't want me to leave the company and to give him time.
* pre-planning - 30m
* planning - 30m
* refinement - 90m
* ultra refinement - 90m
* retro - 60m
It's laughable.
Week 1: One whole day for demo, retro, planning, commitment. But because the scrum master had to "build" a sprint and couldn't do that without knowing the size of tickets, there were two morning meetings every week to "analyse" tickets. So two mornings for "analysis" to produce point estimates for tickets.
Week 2: Also two mornings for "analysis".
So 3 days out of the 10 day sprint, so 30% time spent on Scrum.
Plus standups, they were at 10am so 9am-10am nobody did anything (as judged by the number of PRs and comments and Slack activity) so that's an hour plus the time for standup every single day, so I guess the work day started 10:30am on those days which weren't scrum days or scrum mornings.
Plus the scrum "analysis" meetings were in the morning as it was generally accepted everyone was too tired in the afternoon to to those meetings. So what that actually meant imho was that programming was a low-importance activity that could be done when tired, after the actual work of Scrum had been completed.
Maybe that's insanity, I mean I certainly thought so, but these things do happen.
But, what little progress there was, was easily measured. That seems to be the important part.
Lunatics run this asylum.
In reality we don't have good software development because people at some level or another don't want to do the things that make it possible. They're always going to pretend they care but do what suits them.
It can be from the most basic thing: the customer doesn't want to pay what it really costs to get something good but can be made to pay for something that's going to turn out to be crap in the end.
If you're confessing that it's contrary to human nature and/or the engineering thought process, then I humbly accept your concession in this debate.
Then that is what scrum is.
I know how it worked and why every team I've been on since has not been able to make it work and it all boils down to: 1) internal sabotage - an influential developer does everything they can to shit on it. 2) Management interference - developers could not change the things we needed to change to make it fit our circumstances.
Oh, that's very easy. So much so, I wonder exactly how you managed to perform everything required for a planning or review in the time you give. Business meetings can take more than expected in the best of cases, and the various dysfunctions inherent in scrum only add to that.
Here's a fairly obvious example - scrum encourages you to have a lot of management. At minimum a team needs a product owner, a team lead and a scrum master (and if you merge those positions you aren't "doing scrum properly"). Because there are so many managers, each is under pressure to prove they add value. How do they prove that? By providing valuable input in the various ceremonies scrum requires. Hours of it.
And sometimes they add so much value it can't be contained in the normal flow of scrum meetings (or rather, the meetings can't be contained in the course of a work day), so more meetings have to be created.
The 13% takes into account the time tax of context switching. 18% if we consider only (at best) 6 hours per day and meetings are taking away from that high productivity time (which is to say a greater proportion of time is spent around the coffee maker and not coding)
To go into detail, there is a tax to every meeting. With 13 scrum meetings this adds up fast. For me, as a remote worker, I stop everything 5 minutes before or else (for example) 1:57 is going to suddenly turn into 2:03 and then I'm late. Recovering from a meeting takes me about 10 minutes (plenty of resources state it takes 25 minutes to get back into a flow state once interrupted).
Thus, for me, the meeting tax of scrum meetings alone is 13*15 = 195 minutes. Further, there is a conflict as projects have their own required meetings (if the scrum meetings are the only meetings, then seemingly the team is just talking once a day and then not again - that sounds bad! So yeah, there are other meetings too).
Further, not all 80 hours are equal. Software development is a highly creative field, it's not an assembly line with interchangeable parts. If you have your developers in office for 90 hours instead of 80 you're not going to get 10% more on your story point velocity. Similar for 70 hours vs 80, eventually there is a point of diminishing returns.
By measures of how long I can pair program with someone, 5 hours is a pretty upper limit on how long I can stay in a high productivity state for one day. Time spent in meetings can take away from that high productivity.
Let's say a person can generously be in a high productivity state for 6 hours per day and that meetings take away from that time, then we are very reasonably at 10.75/60 => ~18%*
*I'll emphasizes we are talking scrum meetings only, and still not even taking into account prep time for the scrum meetings
[1] https://resources.scrumalliance.org/Article/scrum-events
"The general rule of thumb is to allow two hours of sprint planning for every one week of sprint length. That means teams should timebox sprint planning to four hours for a two-week sprint and eight hours for a one-month sprint."
It is a bit sad, but that is my experience as well. I had one good manager in my 12 years experience. I had to work around the rest.
Nobody usually wants this.
For developers scrum is actually quite nice. The main success metric is predictability, i.e. the team is held accountable for delivering the sprint successfully. Which means you're supposed to be left alone while the sprint is ongoing.
Some bug? Pfft, if not critical, will maybe take it next sprint.
Finance needs a new report, pronto? Sure, let's talk about business value for priorization. And earliest next sprint anyway.
CEO has a crazy idea that he wants somebody to pull off? Sure, but please talk to Product.
What do you mean, you need more story points delivered per sprint?
The main issue is there are actually people that thrive in this kind of bureaucrazy. I've seen a number of 20-something POs burning themselves over these shitty processes.
In situations like this, one strategy I have used (not for Scrum, but for people who want to tinker with shit for the sake of tinkering) is to say: "Great, we welcome experimentation, this is really cool. What will we measure to decide whether this change is improving our process, and how long will the initial round of experiments last?"
Because: this frames it as something we are trying together rather than something they are dictating, but also something that is not necessarily permanent, which can be changed in the future (including changed back to the way it was), and which is oriented around measurable improvement rather than arbitrary whims. Almost nobody is willing to be the guy who says "we'll do it my way because I said so, even if it makes everything worse", and if they are, that in itself gives you some valuable information about your manager or leadership team.
I thank you for this perspective kind stranger, truly.
I used to have the view that Scrum is a useless batch of meetings, that sucks the life and productivity out of the dev process.
Now, after seeing it from an adjacent (but not subjugated under it) perspective, I think it is a life-sucking batch of meetings that are good for one thing: taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them.
Most of us here are not in that category. I’d wager a majority of HN readers can’t help but to seek out understanding of the business, where this piece fits, what it interacts with. For us, specifying everything upfront is useless. Estimating stuff is irritating because we need the flexibility to make smart decisions during dev. Retro meetings are lies because we can’t say “stop with all this and let me work”.
But if you’re trying to make a process than can take junior devs (not junior in tenure, but junior in the qualities above) and produce an output that scales almost-kinda linearly with dev count, it sort of works.
I’d argue that you’re way better off hiring 6 devs that can go from business problem -> technical solution in their head, without all the ceremony, instead of 40 devs who can’t and 6 PMs to wrangle them.
But I can also see how a company ends up there - go through a tough hiring year, or even just make a few poor hiring decisions, and now you have people on the team who need handholding and supervision. That’s what scrum is; it feels like micromanagement because it is. It forces junior-performing devs into a productive state - maybe 5% of what you’d get out of a senior-performing dev without scrum, but it’s something non-negative.
Leave.
That sounds like it's someone's problem, but it doesn't need to be yours.
The problem is that finding those 6 experienced devs is _HARD_. And they're usually very expensive and know their value.
You can easily find 40 mid to low level coders and a half-dozen people who know how to run a scrum team. Maybe even some of the coders know how to do that for extra savings.
Also in the latter way you can easily have a turnover in the team without any major hassles, you can always find mid-tier coders.
But if one of the 6 highly experienced ones leaves, good luck finding a new one quickly.
A shitty car analogy: You can get a more efficient and faster car if it's 100% custom made. But if something breaks you need to manufacture the parts. Or you could make do with a less efficient and slower car, built out of highly standardised off the shelf parts.
Then I had a very personal conversation with hardcore project manager from non-tech side. He told me that, I got the idea of management of all wrong.
Project manager is an operator where the engineers are nothing more than machine. Your standard engineer is not interested or even care about business goals. They are doing a job, they like to be told what is expected from them, they like to be told what deliverable is. Senior engineers can give an estimate of delivery date, but most don't. They are essentially cogs in the machine and managers are expected to birth products from them.
About those experienced devs: In an manufacturing plant there are things that just works and you don't fiddle with them. Or else, they break and you have to get a brand new thing. Most of these senior engineer with business focus are difficult to manage and they have an expiry date on them. You are lucky to get one, but you have to count the days until they leave for better pay. Moreover, you don't want programmers interested in business side as they get passionate about things that don't concern them which is obviously business side things. So, you need engineers to work but not get ideas.
---
He told a bunch of those stories, but it seems these stories are like if you are in the business, you probably know already type things. He really doesn't buy the idea that "software engineers" are special type of engineers, he said, management hasn't change in centuries, people just use different rhetoric that's all.
The high demand, high pay and low general understanding of computer architecture all fuel this race to the bottom and we all pay for it in low quality, overtly complicated and vulnerable software and all ancillary industries that spring around it. Coding "bootcamps", "Cybersecurity", Agile/SCRUM, Wordpress and clones, AWS and clones etc etc.
Yes I think you got to the crux here - managers want to be indispensable and make everyone else "a machine" so he told you a bunch of self-serving bs. I'm sure if you turn this around on him then project manager will not be a machine but more like a wizard or an artist whose needs must be carefully tended =)
> Moreover, you don't want programmers interested in business side as they get passionate about things that don't concern them which is obviously business side things.
Right and who is better to help here than someone who can take business requirements and hand them to the engineers? You know, someone who got people skills!
One may ask, from where does the tech industry come from? From where tech startups come from? Why is there such a thing as the "tech" industry at all? Don't all companies use tech? We don't talk about the "science industry", do we? If you try and find a definition of tech firm that captures what people mean when they say this, you'll conclude they're basically either computer companies or ordinary firms doing ordinary things, who use computers more effectively than normal. And in the latter case what makes a firm a tech firm is basically unarticulated, people know it when they see it but it's not like there's a set of rules to classify, say, Netflix as a tech firm and Disney as not a tech firm.
So what is it that people see? Mostly it's the distinctive culture that appears when you have (ex-)programmers at the very top of the company, as in CEO and/or board level. This causes companies to differ in all sorts of ways, but one way in which tech firms differ, for example, is that in tech firms you don't get terms like "the business" and "IT". You don't get non-technical project managers. The distinction between the two sides simply doesn't exist.
Non-tech firms live in fear of tech firms and startups. It took me a while to notice this, but go to enough conferences, talk to enough people and you'll see it. The average firm is far more scared of Google or Apple encroaching on their space than they are of an established competitor. This is because tech firm culture is more effective than their own. Such firms have a long history of coming from nowhere to utterly dominate entire industries very fast, and they don't know how to respond to it.
The cultural problems can be seen in the stories you were told. Programmers who understand the business are too expensive. They get ideas. They get passionate, and that's a problem. In a tech firm, experienced devs who understand business end up at director level or higher and firms compete to pay them the best. In non tech firms, they are a problem and get pushed out. This is because the business people are scared of such devs because senior developers end up understanding the business better than the business people do. After all, they implemented the business logic so every rule, regulation and detail is in their mind. And they're used to the rigor demands of programming, so tend to say awkward things in meetings like "that won't work" or "that contradicts the other thing you just said". Tech firms don't mind this because that guy's boss is himself a former developer, and is used to such discussions (from e.g. code or design reviews). "Business people" on the other hand aren't used to this at all, yet feel like their value is their business understanding. They need their devs to be bored and uncaring drones because otherwise what's their own value? You don't want to be competing for a promotion against someone whose understanding of the business is better than yours and who can actually execute change projects effectively!
Underlying all this of course is the uncomfortable fact that programming is much harder than most office jobs. Programmers can and will learn programming and then go on to learn the fine details of finance, accounting or shipping without breaking a sweat, but the reverse is generally not true. It was maybe to some extent in the Visual Basic era but the move to web apps put a stop to gifted amateurs cobbling together business apps and nothing really replaced it (maybe Oracle APEX but it's not as widely used).
Not sure it's a great analogy though since software is still basically the design part - the duplication part is trivial.
The key observation is that they successfully made the "design" of software they "mass duplication" part. The cost of designing and creating crappy custom software has never been so low and it continues to fall.
Multiple steps actually.
(And in some cases the alternative to the "sweat shop" is the same amount of hours outside in the fields with fluctuating income based on what happens with the crop that year)
And turnover you will have! =)
Note that you just ballooned the cost probably 3-4x compared to keeping the team small and strong. And that is how we got to this zombiecorn land we see today.
Also consider this - hiring a large team of bozos is a one-way street. You will likely never be able to hire and retain strong talent ever again. While you can always turn to hiring "mid-tier coders" when the product matures.
> Most companies and teams have to go the structured approach with whatever local mediocrity they can hire.
Yes most companies fail
When you hire people straight off school or "mid tier" people, you can help them grow to be better and reap the benefits.
If everyone will just hire the "top tier talent", their prices will inflate and the pool of top tier people will never grow.
or something like that.
The only way to figure it out is to hire the ones that seem good and see who blossoms.
Yes, there are some people who shape up for 6 months and then start slacking, but they're definitely not the norm. You should be able to evaluate a person in that time and see if their personality fits the team and whether they are a net positive for the productivity.
> The problem is that finding those 6 experienced devs is _HARD_. And they're usually very expensive and know their value.
It's harder than finding uncaring juniors, sure.
But if you need 40+6 people, or 6 experienced people, that's nearly 8x salary.
In silicon valley money, you'll need to pay those uncaring juniors about 150K.
I guarantee you that you can very easily find those 6 experienced people in a few weeks if you're offering over $1M/yr to them. In a month you can staff all 6 positions.
If you're saying you want ~8x performance but not interested in paying ~8x salary.. then yes, it's harder to find the people.
I'm pretty sure that short of John Carmack or a legend of that caliber I can't justify paying 1M to _anyone_ to the people making the budget.
Of course you can grab a half dozen superstars if you pay them a million per head, but they'll also leave the second the job stops being 100% interesting.
That's not a sustainable way to build a company or a team.
There was a good video about this but the tl;dw is about this:
In Japan you're supposed to get hired straight out of school and then you'll stay with The Company until you retire.
The same tradition implies that The Company will _never_ fire people.
Japan faced some very hard times. Companies couldn't afford to hire new people because they couldn't fire the older people.
A whole generation never really entered the workforce because they never got the experience. Now they're mostly doing odd jobs and for the same reason never got married and had children.
Oopsie.
That’s not the only cause with all due respect, I have worked with several C-level managers before, they WANT those mid-low level developers/engineers, they are cheaper and easy to find like you said, but most importantly, they can replace them on a whim with another one who will do the same work, with “super” engineers, it isn’t the case, the amount of knowledge and depth one of them has, you will need a whole team to understand what’s going on first and another to carry on the job, and C-levels being egoistic, they don’t like anyone to have any leverage by any means.
> Not everybody knows that, but Scrum was invented to manage a team of dysfunctional COBOL programmers at a bank, not for product-led tech companies, and certainly not for startups.
> If you're mostly hiring juniors, low-skilled, unpassionate, unable to work autonomously without constant handlholding, reactive instead of proactive people, then you'll certainly need some micromanaging SDLC like Scrum.
Story of my life! And I guess it is the case for most competent employees unfortunately.
Scrum was created to help good developers communicate with management. But the problem is that management has all the power and couldn’t give a shit. If the management was qualified to “get it” you probably wouldn’t need it.
So yeah, if you’re using Scrum, you’re probably going to fail: whatever the reason that you’re doing scrum? That’s why you’re gonna fail.
Scrum is a fantastic canary.
Every user story was the same - “As a business owner, I want users to be able to do x”. Defeats the entire purposes of user stories. But they were told they had to write stories. So they did.
We also had our work planned out 6-12 months in advance.
It was top-down waterfall disguised as agile, which would have been acceptable if we didn’t also waste 5+ hours a week in daily standups (aka status reports), sprint planning, retros, story breakdowns, all of which were scheduled at the most inconvenient of times to ensure they interrupted your flow.
I’ve had that “team of six motivated” come together twice organically during my career. But it never seems to last. People move on, the company gets wind of the success and either normalizes it out, or attempts to try and distribute and harvest. If I could figure out the recipe to reliably locate or create that sort of team, I think I’d be very well off.
And here’s Dave Thomas (one of the names under the Agile Manifesto) speaking of the Agile/Scrum Industrial Complex https://youtu.be/a-BOSpxYJ9M?si=pwROU4JU9V64A39O
Maybe in theory that's the point of it, but it practice it also (and mostly) has the opposite effect: it takes all agency away from capable developers and make them impossible to see the big picture, drastically plummeting developer productivity of otherwise very capable developers.
> Most of us here are not in that category. […] For us, […] is useless.
It's not just useless, it's actually harmful.
> But I can also see how a company ends up there - go through a tough hiring year, or even just make a few poor hiring decisions, and now you have people on the team who need handholding and supervision
But most of the time it's not how it happens: it's forced top-down by manager who have no idea of how software development work, and who are genuinely convinced that it is how projects should be run.
They don't realize that it's a workaround for terrible HR that reduces productivity for everyone, because if they did they'd probably think twice (“How is my HR so poor when I'm not trying to cut on costs there? Oh maybe it's not and I should not use scrum”), they just do it because everybody else does.
It is an assured loss for all.
Why not the opossite way? Trust people a bit above what they currently warrant, see who rises to the opportunity, and ease out the rest. This will over time elevate to a decent team.
That's a very charitable view... I think back over my career and it was always cargo-culting and micromanagement. I give you credit for analyzing and finding a way to make scrum work beneficially.
The thing is - if you have people who don't (want to) understand the relationship between their work and business value, you've fundamentally got a hiring / personnel problem. And I don't see how scrum (or any other methodology) ever solves that. What you've got at that point is to me the difference between "programmers" and "developers / engineers". People who are more enamored with the technology than with actually accomplishing work. The thing is, some of those people are really good so long as they can be pointed in the right direction. But that's a management thing, not really a methodology thing.
It is very easy to hire one bad player, and he takes the team down, and (in most jurisdictions) it is hard to lay them off.
The reason is, no one who knows what it is required, wants to do the hiring.
You always want to be able to sidestep your boss to your boss's boss of you need to. Or talk to end users and customers.
If I'm being onboarded at some project, I expect to be provided that description as early as possible. Compensating for broken communication by enforcing a life-sucking batch of meetings doesn't seem right.
1) As you said, when you have a lot of junior developers (which given developer demographics is a given), you need some structure. Scrum provides that. For better or worse, the structure is helpful to people that are still a bit uncertain about how stuff works. I hate stand-ups as much as any other developer. But as a product focused CTO, I love that it gets the day started and my developers out of bed, awake and cafienated and focused on the job. Scrum's other meetings are a necessary evil. You need a platform to get them aligned with business goals. They don't naturally do this by themselves. Most importantly, a lot of developers kind of expect to this structure at this point. Providing structure to a team is important. Scrum is as good as any other structure. Not ideal with remote teams as meetings get more tricky.
2) Most scrum roles are junior management roles. And as such you get typically not very experienced people filling these roles as part of their entry into the corporate rat race. So, you get corporate politics playing out at the micro level with lots of turf fights about stuff that generally is close to irrelevant. Ranging from the right way to run meetings, the best issue tracker, etc. It's this endless friction that is causing a lot of resentment with more senior developers. Particularly in larger organizations this can get ugly in a hurry.
My strategy for containing this madness:
1) Keep teams small. Small teams are efficient teams that should not need a lot of (micro) management. And they also don't need a lot of formal roles.
2) No scrum masters. It's a bullshit role that doesn't add a whole lot of value. Especially in smaller teams. Instead I prefer to have tech leads calling the shots on their team or topic and stepping up as a leader. Part of that responsibility is leading the team in a direction that makes sense from a technical and business point of view. And the rest is about coaching people around them. It's something that happens naturally even when you don't want it to. So, I mostly just let this happen and encourage it.
3) Product ownership splits into technical and business ownership. While these can be the same person, it's better to have two equally ranked people shooting for consensus covering both business and tech. That ensures the business and tech is actually aligned. Weed out unrealistic requirements and deadlines; make sure that the technically easy yet valuable work actually gets done; ensure that business value is delivered; ensure that work gets prioritized correctly and that POs don't revert back to waterfall.
4) Management by exception. I like giving people enough room to manage themselves. I step in when that doesn't work. And I use positive re-enforcement to encourage them to do more of the right things. I'm not actually a genius; so I need smart people to tell me what the right way is to do things. Especially when those are things I'm not that good at. People closest to the problems, usually are best positioned to come up with good solutions. So let them. Fix it when that isn't working.
5) Use sprints as a predictable, calendar based umbrella for people to structure their activities around. Short enough cycles that it doesn't turn into waterfall. Long enough that we don't drown in meetings. Day to day management is Kanban based. Just generally remove uncertainty about what needs doing, who is doing it, why we're doing it, what's coming next, etc. Using continuous deployment to release stuff means that guarding quality is a constant and not a once a sprint kind of thing. Sprints are not release deadlines. Using Kanban day to day means that any high priority issues jump to the top of the stack right away. Short feedback cycles are key to keeping quality and morale high.
6) Meetings can be synchronization blocks. Any engineer knows those are bad. Business people seem to never grasp the cost of meetings (as this is all they do). It translates 1 to 1 to how teams function as well. That's why day to day work should not be blocked on meetings. We have issue trackers, slack, and other communication tools to sort out any blocking issues. Also, just talking to a person can be surprisingly effective. Scrum meetings are neatly partitioned to be about things like status updates, prioritization, estimation, and reviews. None of those meetings should be on the critical path to delivering working software. The correct way to resolve issues is direct or asynchronous communication (as is convenient).
7) Try to keep the few meetings we have a bit positive, light and friendly. It's bad enough that we have to sit through those. Conflict is what makes scrum so controversial. The constant bickering about everything and anything is just a mental drain on everyone. I try to keep that out of meetings as much as I can. Having tech leads means that they get a first shot at a decision. So, no need to have a lot of meetings about that. I use one on ones to correct a lot of things when they go wrong in meetings. Meetings are for positive re-enforcement. Call out the things that go well, inspire people to do more of the good stuff, etc.
I don't think that's even the case. I've been brought onto teams of junior (in the sense that you talk about) developers to help fix broken, late projects. Those projects had always been managed under some sort of agile process, and they still ended up in trouble. I wouldn't even say the process "sort of" worked before then. I dunno, maybe it would have been even more of a disaster without the process, but I still don't think that lends much praise to the process.
I'm lucky that I can pick and choose what sort of projects I work on these days, and I will never work at or for a company where I'd be subject to any kind of agile garbage. Another toplevel commenter farther down mentioned a study that showed that projects managed under the "get to work and let me know when it's done" model outperformed all the others. I've always intuitively believed that model can work (though perhaps not in all situations with all types of developers), and it's nice to see some data to back that up.
I read 20+ books on management and leadership[1], and none of them mentioned anything like Scrum. I agree it's BS.
A good team that runs itself? Ofc it doesn't need Ten Scrum Masters to deliver value.
Now, the real question is why leadership tries to salvage failing teams with Scrum? Save the wasted money, use it to hire top talent instead... easy.
This problem exists at big tech and startup, in companies that spend fractional multipliers of the average salary on engineers as well as those who pay poorly.
In this environment, if your solution is "hire better people', you can't- there isn't any
Big tech or startup status are not correlated with top talent. I've seen the whole spectrum of low to high talent from both places.
> in companies that spend fractional multipliers of the average salary on engineers as well as those who pay poorly
Pay and top skill are only slightly correlated, unfortunately.
> Top talent does not exist.
It does exist. I've seen it, but most managers don't know how to find it, identify it, and retain it.
Also, please at least acknowledge that your numbers are completely made up and may have no basis in reality. It might be a $1000 team only if they deliver on time, but the overages might push that to $5000. Or whatever. See, I can completely make up numbers to support my point too.
You are 100% right that legacy management falls for the SCRUM sales pitch.
At one company I worked at the scrum salesman basically bullied the executive team by saying "You don't want to be the last company to adopt scrum do you?!!??!"
Have you _tried_ hiring good people?
Even better is top talent who can also interface directly with the client when necessary (not necessarily all the time) and doesn't need everything first filtered through a manager.
I've worked with teams like this in the past and it was always a pleasure. Most of them were fairly experienced devs and knew the value of email, phone calls, and water cooler talk (serendipitous discussions which led to valuable information being exchanged). Despite the lack of "modern" productivity tools like text messages, chat apps, and Slack, we were able to get stuff done efficiently.
We had weekly meetings which were productive and useful, and actually helped identify if anything was falling through the cracks. Nobody got bored because the meetings were actually helpful.
So it would have to be both: the devs are good and don't need hand-holding, and the manager is able to deal with the lack of transparency that "it'll be done when it's done" comes with.
Some people just have a very hard time letting go and trusting a team. Who they are managing just needs to follow.
My takeaway then was that Scrum fosters a modular team management style, which diminishes the dependence on highly skilled individuals.
This approach seemed to offer management a sense of oversight in the software development process, but I didn't stay long enough to determine whether this was actual control and predictability or merely an illusion of it.
The process is a performance within a performance, literally getting told NOT to do more work. This is what happens when you have chart-oriented-development (particularly jira's toxic charts).
You might think this is nice to have free time to sit around, but frankly it also drains a lot of the joy out of my work, takes away my sense of autonomy and pride in my work and leads to some resentment.
This is not part of scrum
At a place I worked the management decided that a "story" should always be completed within a sprint. So what did we do? We started using stories instead of tasks and epics instead of stories[0]. And voila, now magically stories complete within a sprint!
[0] Just writing that sentence makes my eye twitch
Practically, it means nothing of course.
- the product owner sets the backlog priority
- team estimates
- team commits to what it can deliver from the backlog
- any misses are analyzed for scope mistakes
Rinse/repeat
There’s no shaming part
Edit: format
Unless a person has no shame, failing a commitment I certainly believe is intrinsically shameful. Some cultures would commit seppuku if you don't deliver on a commitment.
The words, "you failed on your commitments" seems very much like shaming. Thus the move to "forecast" over "commitment"
[1] https://www.scrum.org/resources/commitment-vs-forecast
*edit (addendum): Invoking 'seppuku' might be a bit sensationalist, my apologies. The southerner in me is coming out - saying someone does not live up to their word is a very big deal.
Normally I just fix them within a separate commit.
It was painful. I constantly felt that I should be working, because I was being paid decent money. But there was nothing to do, and no-one wanted me to do anything. I couldn't focus on a side project because I felt so guilty about taking their money and not doing anything.
We adopted Mob Programming. Five senior engineers on one call writing one piece of code. Or rather, one of us teaching the manager some Golang while he spent 4 hours doing a ticket that should have taken 1 hour. No stakeholders present because none of them wanted to waste a day watching us work.
Such a waste of time and talent.
That’s what I hate about these wasted “pockets” of time.. you don’t have work to do, and you can’t focus on doing your side projects either, just a waste.
If you asked a marathon runner how to run a marathon, they're going to tell you things like run slower, make sure you conserve energy, and control your pace. They're not going to tell you to mentally break the marathon into small sections and sprint them all.
I know it seems minor (and it probably is), but it's always felt a bit telling that the recurring segment for work in scrum is named after something you cannot do repeatedly without completely burning yourself out.
“One aspect of agile, and of SCRUM in particular, is that the team is expected to 'forecast' which stories it will 'burn down' for a sprint. The phrase "forecast" is often replaced with "commit", and a manager-type will interpret this to mean he/she gets a fixed price deal with the team, yet without any quotation on behalf of the team for assessing risks/opportunities, as with a regular fixed price contract. As a freelancer, you can't let this happen, so it leads to unpleasant discussions.
I also take issue with the term 'sprint'. By definition, a sprint is a short-term sports activity to reach a goal in the shortest amount of time possible. But just as in sports, you can't expect to do one sprint after another without quickly burning out, and that's exactly what I've been seeing in agile projects. An engineering-heavy software project shouldn't be seen as a series of sprints at all, but more as an endurance run if anything.
I also hate the term 'agile' itself, which seems to be chosen to appease to a manager's idea of interchangeable, faceless staffing. Actually, "agile" makes me think of spermatozoa striving to fertilize ova.
I also despise the motivation propaganda that usually goes with agile, and the "scrum masters" non-coders interrupting any meaningful technical discussion they don't understand and suggest to take the discussion 'offline' or 'time-boxed'."--imhotap, https://www.reddit.com/r/programming/comments/6rsyrd/in_a_nu...
“My experience shows that proper testing and documentation is the first thing that management wants taken out of the story, often with the excuse "We can handle that in a later sprint." But since your life is a neverending series of sprints (note: that's actually an ultramarathon), and management gets to pick priorities, you may never return to the technical debt.”—klyrs, https://news.ycombinator.com/item?id=20017854#20021832
“I regularly ask ‘Why are we running a marathon in a thousand sprints?’.
Besides tech debt, a concern I have that I don't see brought up is burn out. With Scrum, every action you perform is micromanaged and with a push for ‘high velocity’. There is no proverbial breathing room in this where the pressure lets up. At least with waterfall (for how we did it before Scrum), the windows of high pressure times were shorter. During the beginning of our 6 month waterfall, in parallel to spec work we'd be taking care of tech debt or implementing our pet feature and it was a time of mental recovery.”—epage, https://news.ycombinator.com/item?id=20017854#20021832
Taking a 500km bicycle ride from one place to another, you surely will plan the thing as segments. I would plan days and see where I can reach milestones: a city, a place to stay, a sight-seeing place, a mountain top, a ferry, a destination...
A software development project of several months is not a Marathon.
I've run a Marathon in a few hours. But even in a Marathon I look at my starting preparations of the day, my 5km times, reach the half marathon, plan for the drinking stops, plan when my primary energy source is depleted, how to get over it, ... Few people run a Marathon from front to end with the same speed&energy, without a plan how to mentally split up the race.
It's like if you came to my house and asked for a towel and I went, "oh yeah, use my butt towel". Just because it's called a butt towel doesn't mean it's actually got anything to do with a butt, but you're probably going to be a bit uncomfortable until you understand why I'm calling it that.
But, that's besides the point. Scrum doesn't exist to make developer's lives easier. In my experience as a SWE in a scrum team, devs have basically always felt like our time is being wasted in meetings.
Scrum, imo, exists so that management and business stakeholders can have an understanding of how efforts are being allocated and give feedback on it. There's still plenty of ways this can go wrong, and I agree with others that the short sprint cycles of 1-2 weeks lead to the extra overhead of too many ceremonies, but I think for the average business stakeholder it probably gives a better result than waterfall.
I think that's key. My experience is that I have often told my managers that "I don't need this meeting personally, so unless somebody else needs me in this meeting, I am losing my time".
Do you know what the managers usually answered? "I disagree, I think this meeting is useful for you. We are having this meeting to help you developers".
No wonder I don't respect my managers then, and now I happily waste my time in their meetings.
* standups were limited to 15 min/day (all Scrum teams I'd been on took 30 min, minimum, to do standup)
* we actually had 1 hour retro, planning and refinement meetings (retro, the most useful meeting, was actually 1.5h, planning and refinement could take 2h)
* POs did not feel free to schedule arbitrary additional meetings to keep up with the increasing backlog. SAFe specifies a quarterly, multi-day, division-wide planning meeting to align disparate teams during which all the work you intended to do for the next six sprints was scheduled on a big board. Of course there was never enough time to point and schedule six sprints' worth of work, necessitating a pre-planning meeting, and sometimes a pre-pre-planning meeting. Hours each.
All 10 of the former?
Enlightenment came to me when I realized that companies only adopt Agile for reasons that benefit executives and management, not developers, to wit: fine-grained observability and direct control over the SDLC itself. It's really a game of Mornington Crescent: the team pretends to be playing one game when they're actually playing a different sort of game.
I agree that devs can often mistake this need for wasted time. That does _not_ mean that Scrum is the best way to not waste time. A good project manager can get that info without so many full team meetings.
I guess one way to put it is that scrum is a clear way to lead a project (which is what entices people) but its not a great way.
Story points and sprints are a *self-calibrating* tool that will give you an advance warning (nicely visualized in burn-down charts) if an estimate you might have given a middle manager will be missed.
You do not "decide" how many points fit in a sprint, you just work at a sustainable pace and *measure* how many points fit in a sprint.
Nearly every single point in that tweet just screams bad management and bad engineers without any agency.
I've always said that Scrum doesn't fix problems, but it makes them more evident so you can fix them.
Teams that don't realize this are going to be unhappy about Scrum, but in my opinion they wouldn't be happy without.
Often the problems are one of these:
- Focusing on estimates. In scrum, a team doesn't really need any estimates beyond planning what they will do in the next two weeks. Planning poker, story points, estimations are just a means to that end. If you don't like them, don't use them.
- Focusing on ceremonies without understanding how to use them (or when to drop them!). I haven't done stand ups in years. I use online tools like geek bot. Retrospectives are just as useful as the number of problems you actually solve after they are pointed out. Planning is only useful if it produces teamwork, if the engineers all work in 1-person silos, it becomes a joke.
- Not understanding that Agile > Scrum. If you think you can be more agile without some parts of scrum, drop the parts you don't need. Being able to change the rules of the game in-flight is part of agile (and of scrum).
bad management destroys agency
> You do not "decide" how many points fit in a sprint, you just work at a sustainable pace and measure how many points fit in a sprint.
I don't know how you can use both "sprint"[1] and "sustainable" in the same post with a straight face.
[1] A sprint, by definition, is an unsustainable burst of speed. The word "unsustainable" is literally in the definition.
User stories are not actual stories with a plots as well, but the idea makes sense
When you tell people the word "story", they know exactly what you mean, because the word story is used all the time for things without plots ("So, what's your story?" comes to mind).
We frequently use the word story to mean "your side of things"; in civil litigation for example.
// linear also calls them cycles, https://linear.app/features/plan#cycles , but linear is a bit meh
> Not everybody knows that, but Scrum was invented to manage a team of dysfunctional COBOL programmers at a bank, not for product-led tech companies, and certainly not for startups.
> If you're mostly hiring juniors, low-skilled, unpassionate, unable to work autonomously without constant handlholding, reactive instead of proactive people, then you'll certainly need some micromanaging SDLC like Scrum.
Of course in practice agile/scrum/whatever has turned into the same cargo-cult nonsense that the original promoters of the ideals were fighting against.
One thing I thought was interesting was:
> First, the most common jobs among the people who told me I was wrong were "Agile Coach" and "Scrum Master." They feel very strongly in favor of Scrum, but I'm not sure why.
It seems funny to critique people's job titles when the poster's Twitter profile reads:
> I teach Machine Learning and run http://ml.school
I mean loudly critiquing a mainstream practice in a flippant way is pretty much the textbook approach to bring attention to yourself and establish as an expert in... teaching people about these topics. It's content marketing 101.
My wish is for HN to ban all links from there. It would be better to HN anyways if the discussions got contained within the forum instead.
It would be nice if it became normal for HN users to flag and or at least refrain from upvoting twitter links, since my belief is that they are bound to influence HN negatively.
Failing that I suppose I'll have to mess around with an extension so that my browser removes them automatically instead.
I'll say this: I worked in XP (and then "agile") teams ~20 years ago a couple times with varying success, but the one good thing was it got people thinking and agitating against the delusions that went along with waterfall.
Then I got stuck at Google for 10 years, where "agile" isn't really a thing. (There are teams that are sorta doing scrum... ish stuff. And there's a wide diversity of how things are done there. But on the whole Google has effectively unlimited budgets and headcount so things sorta just ... broken down waterfall ... until they're "done" whenever). When I got out... Scrum or some variant had taken over.
And I don't recognize this as the "agile" I worked with before. It's just a mess of pointless routines and shiboleths without the meat of what made things "agile".
Agile was: developers do their own estimates. Short iterations. "Stories" are 2-3 days and tied directly to a customer's business request. Intense involvement with the "customer" letting them know the trade-offs for every decision. Ship the prototype. "You ain't gonna need it." Informal daily standup just for the purpose of making sure everyone is on the same page. At the end of the iteration, go over the "cards" and triage and discuss why some estimates were off.
What I see now is just going through the motions of some of these, but in the end it's either chaos, or waterfall in disguise and some PM with a hard-on for configuring JIRA in some convoluted fashion so they can pass on reports to their superiors and make people jump through hoops so it looks like progress.
I just wanna code, get things done, fix things and ship things. Agile was the recognition that (good) engineers want to get work done and the upfront design process was often just getting in the way of problem solving and the creative process. The ones who don't? Get them off your team.
Somewhere along the line that message was lost.
Something I've noticed in the last 3-5 years is that it's become more and more common for companies to quiz candidates on their scrum knowledge during interviews. They don't care what you think of scrum (though they may phase their questions like this) they simply want to know you know how to scrum because they scrum. And like in most places you can assume that although "scrum is flexible" it's also religiously followed in practise.
Anyway, this company wanted to know what I liked and disliked about scrum and my initial answer was kinda similar to this post – that I liked the idea of it but have never seen it work well in practise. Obviously this was a bad answer because it meant for the next 10 minutes of the interview they were asking me to expand and were trying to understand if I was a bad culture fit. Which to be fair I probably was.
But the truth is everywhere I've worked spirt ceremonies are universally hated and typically viewed as a waste of time (especially spirt reviews). Planning rarely adds much value and since estimates are often wrong you either need to be overly conservative with your estimation (rendering it useless), or you're forced to cut corners to deliver stuff on time. And even if you do estimation perfectly ACs always change and extra tickets are always brought into the spirt because "it's essential". Standup is never 15 minutes – it's 10 minutes per team member who likes to hear their own voice, and 30 seconds to those who don't and who just want to get on with their work. Don't even get me started on the team building games...
I have seen companies implement it better than others though. The place I work at the moment does it surprisingly well. We do standups which are mostly mandatory, but everything else is optional for the vast majority of the team.
I think that sums up why you got rejected. Over the years I've found anything negative said during an interview process works against you. I really noticed this when I had a job I hated and some of that kept creeping into my interviews with me saying something about it (varied from rant to a few comments) and I was interviewing for a few months... I noticed this and consciously edited it out and had 2 offers in the next couple weeks. I've noticed it more subtly after that and have sense tried to make sure I stay 100% positive in my interviews.
It shows experience with people and ability to read between the lines.
I was initially really interested in the company and made it clear early on that I really liked what they were doing and how I thought I could add value, but they started shooting me down assuring me the role I was applying for wasn't that interesting and that I'd mostly be a code monkey (obviously not in those exact words).
By the time they started asking about my agile experience and what I thought of scum I figured I didn't have much to lose being honest with them. It would have been in neither of our interest for me to pretend I might have been a good fit.
But yeah, generally I'll try to be mostly positive while finding something minor to be constructively critical about. I think that tends to strike the right balance between showing you can think for yourself without coming across as the type of person who will cause problems. Sounds like you've noticed the same thing.
Like with all self-help formulas, Kent will label his solution as magic bullet for all software development problems. He will advertise it as secret medicine that cures all ills. He will be at every conference, write articles after articles, publish books.
Also, like all magic self-help formulas, it wouldn’t quite work. So, Kent will invent something new. His next prescription was TDD and when I first saw it, I thought it was a joke. But people around me started drinking cool aid and if you didn’t join them then you weren’t one of them. Again, Kent and friends will go out on massive marketing spree advertising it as secret talisman. Like all overweight desperate people in need to lose weight, people will enthusiastically start new Kent Beck diet, lose few pounds and endorse the formula. But they will soon find that they had simply traded one problem for another more uglier one.
This went on for long time. For more than two decades, these group of people kept inventing these processes, selling it as magic pill and made millions upon millions in consulting gigs, books, training, certifications and so on. They came up with Agile and 17 people in that group created “agile manifesto”. Their most aggressively marketed prescription was scrum. Like their all previous prescription, world is finally coming off of night of drinking cool aid and feeling severe headache.
I think most of these people have now sort of retired after amassing massive fortunes and hopefully we will not see more of these magic processes pushed to dumb CTOs with promises of curing all ills.
The truth is Scrum was never a magic bullet and it is downright harmful for many projects. It is useful for highly predictable projects where research component is negligible, for example, CRUD websites AND where you are stuck with unmotivated tier-3 talent who failed to get job at insurance company. For everything else, it should never have been used. It is especially going to hurt creativity, originality and novelty if you are in business of making a differentiating unique novel product. It also is very very bad choice if you already had tier-1 highly motivated team.
So exercise caution!
I don't think Agile has prescribed this though. Scrum, in my view, is an intermediary 'solution' so non-technical 'bosses' can overlook and micromanage dev teams. I guess it all stems from 'unproductivity' really, those cases you mention, where you end up with sub-par devs trying to deliver complex software products.
Once you hire a scrum master to tell you how to do your work, you've sort of lost. They are rarely useful other than as sort of "priest" of the process, who ends up becoming another sort of management, but without management powers (usually).
The meetings etc. can be downright useful, in certain cases, but don't really make sense to follow religiously. I.e. if the devs themselves are running the meetings, for themselves, its a useful form of self-management, and you don't need much management skill to run it (any seasoned dev with any sort of communication capability can do it).
But if its imposed upon you, its just a cookie-cutter sort of management, which, doesn't fit all teams or scenarios.
If you already know _exactly_ what your code needs to do, you can "just implement it".
I find TDD to be very helpful in the cases where I do _not_ know everything in advance, because it lets me take small steps to explore things and I get very fast feedback if I "misstepped".
It seems like the new generation of software development silver bullets is "microservice", cloud "devops" etc... Managed kubernetes is not a bad thing. Configuration files, software defined infrastructure, etc, not bad things at all. But there is a definite market push in consulting for overtly complicated frameworks as The Way and people who are anxious about their complicated projects gobble it up.
First, Scrum is not XP. Huge difference.
Second, even XP is not a "magic bullet". Nothing is. It's work that works. (Scrum, on the other hand, is not a "magic bullet" but simply a "bullet". Use it to kill projects very effectively).
Third, at my first real job after uni, we did most of the XP-like practices, and it worked amazingly well. But we didn't know about "XP". Partly because it didn't exist yet, as this was around the same time the Kent Beck started at Chrysler Comprehensive. When the XP books came out it was fun to have a name for what we had been doing so successfully. And also to compare and contrast.
Fourth, I had a great side-by-side natural experiment during my tenure at the BBC. My team did XP-ish things, mostly the technical practices, so test first/TDD, YAGNI etc. Pairing when necessary, but we were co-located around a desk "island" (sort of the way journalist workspaces are organised). My team succeeded far beyond expectations [1]
The team next to us, larger, more important and with way more experienced developers did SCRUM, but not XP. That project had to be rebooted completely after 2 years.
[1] https://link.springer.com/chapter/10.1007/978-1-4614-9299-3_...
Nailed it.
You still don't really know when it will be ready, but you now have talking points with management about a) whats been done and b) how complex it is. This builds belief: Belief there will be a solution, and Belief you can find it.
Nothing not said better by others here, but I say this as a party who was dragged kicking and screaming into the process to be an agile product manager, hated it, and got out. I totally "get" why people want this. It's very rare to be a Bell Labs, or Xerox Parc, and have pretty much complete freedom to spend budget and deliver an outcome when it's ready.
I also have worked on large s/w projects which cost $16m to fail to work, and $60m in lawsuits out the other side. I know that the alternative (a massive proscriptive playbook of minute details of functions, UML, flowcharts, you-name-it) exists and works, or not (depending on your point of view).
Really? I think scrum was the wrong name. The process itself, is fine. Talking to your co-workers builds a sense of purpose and direction.
The tone on this thread has that jaded and defeatest "management sucks" attitude that I find most often in the least productive engineers regardless of how they work.
The people who are silent in the retros are probably jaded and cynical about the whole process. And if the manager knew their shit, they'd do something about that instead of accepting that some of their team are not engaged with the process.
Teams generally aren't allowed to stop doing sprints. In some places they aren't even allowed to pick start and end dates because management wants all teams on the same cadence.
If you use Jira - there's often all kinds of stupid imposed workflows. Mandatory fields depending on ticket types etc. If it's not useful to your team - tough shit, you don't have a choice.
Want to stop doing story points and use tshirt sizes? You can't, management monitors velocity as performance indicator.
Once you've had a few suggestions shot down because of top-down mandates, why even bother with retros?
Basically, scrum is very frequently a top-down management technique and teams aren't actually self-organizing because management can't deal with 10 teams each doing things their own way.
And then management (and their allies in the closely aligned “Software Craftsmanship” movement) blame the developers for the consequences of those tradeoffs and all the technical debt that typical entails.
I worked as an engineer, PM, and a manager, when I was an engineer and scrum was applied wrongly, I tried to communicate for that “continuous improvement”, but that only works with an actual leaderships that listen, 99% of your middle management are just power hungry folks that are kept in their positions to take the shit instead of senior managements, when I worked as a PM however and tried to customize those agile tools per project and per team personalities too, everyone was happy, projects got delivered and things worked as expected. In 90% those situations you can never blame the engineers, look at the work environment as a workshop, the guy working in that shop is the PM and the tools are your engineers, ultimately that guy is accountable for the success or failure to deliver that work, if you start blaming the tools you have in the workshop, then you are the incompetent one, simply put.
The remaining teams just needed Kanban.
Not sure what everybody else is doing here, but I have seen teams where before we started doing scrum+jira all tasks were coming on Skype and discord, and stakeholders were either micromanaging (programmers managed by non-programmers) or either would forget project for 1 month and would come back to find something delivered that completely missed expectations.
After moving to proper task tracking and clear planning and review rituals, the developer satisfaction went through the roof (before that people were borderline considering quiting)
1. Be pull based - someone only picks something new up when they have the capacity to do so. There's no "finish this set of tasks by the end of the sprint" because there are no sprints, just priorities
2. Manage work-in-process, either explicitly or implicitly. This prevents the team working on too many things at once, which leads to any given piece of work taking a long time to get to production
I think it has a lot to do with how good estimates can be, and how much can be shared between the members of the team. The extreme situation where the tasks are all boring/predictable and everyone in the team can do everything probably works well with Agile (or any estimation-based religion, I suppose).
The problem is that in many situations, many tasks are not very predictable (because they involve novelty, risk, exploration, challenge), and not everyone is capable of doing everything. In that case the estimates are a big joke, and Agile is just bullshit.
Agile in theory is great, teams should just do what works for them. End of story. But the issue is that agile and scrum are synonymous in the “agile” industry of consultants selling agile training to companies which largely drives how it’s practiced.
Kanban I think is a great organizational method though. It tracks work, shows what needs to be done and the progress. And gets out of the way.
Yeah, agile and scrum aren't the same. In my humble opinion, agile process is pretty fantastic and a lot better than waterfall (although waterfall has some elements that should be carried over to agile) or even Rational Unified Process. Yeah, Agile is taking over the engineering world (not just software) for a reason, because iterative development using small teams works.
1) Searched the entire agile manifesto site for "sprints", "stories", "velocity", "stand ups" etc. Zero references.
2) Searched the official scrum guide for the words "agile", "stories", "story points". Zero references. It only defined sprints.
Read through the principles and then find out how it maps to scrum.
Scrum is not the same as "Agile", but it tries to provide a simple methodology to implement parts of it.
> continuous delivery of valuable software
> Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
That's a sprint in Scrum.
> The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
A stand-up is one way to do it. Standing and talking face to face may seem foreign to people used to sit all day in front of computer screens, but I think it's worth trying... ;-)
and so on.
Basically we'd ask mgmt "what do you want next?" and they had to fuck off for the next 4 weeks while devs, ux, QA worked with no changes in plans until next demo and release. They were responsible for figuring out "when will everything be done?" etc.
I recently left a startup that said they were "doing Scrum" and it was just daily task tracking and pushing devs to overcommit to each sprint - that's not what I consider Scrum.
Yeah, that's definitely not Scrum like you said. The whole point is that the team promises to deliver features during a sprint and won't overcommit, they might deliver extra if they have extra time.
If your sprints continuously fail to deliver, then you need to decrease the team's velocity.
> #6 We measured how much it cost to deliver one story point and then wrote contracts where clients paid for a package of "500 story points."
> #7 Management lost it when they found that 500 story points in one project weren't the same as 500 story points on another project. We had many meetings to fix this.
I believe 99% of Agile's value comes from caring about developers and letting them pride themselves with their progress.
Managers benefit from regularly reminding devs that their progress is not measured by amount of code, but working features. "Can you do a demo?"
Care about your devs, let them demonstrate progress. There, I just invented another Agile framework.
Once things become difficult, challenging, or new, it's garbage.
Projects that are taking more story points than expected are "behind schedule". No, your shitty schedule is the problem, because you were unable to estimate the difficulty of doing something new. And that's the hard thing about hard things. Maybe it will be done in 3 days or maybe you'll need 2 weeks, but you can't do that with very difficult things.
Scrum is an attempt to label Parkinson's Law: that a task will expand to fit the time it is allocated in the schedule.
With people that need to be micromanaged, and tasks that you know how to do but take time, scrum can work. This is because it basically gives you a way to measure whether you believe a junior developer is performing up to the level of expected, rather than slacking off or sandbagging.
Personally, I hate scrum.
For features, I'd say that Kanban works better, when mixed with ideas from Scrum. Most of Scrum's ceremonies are useful without sprints, and gives, in my experience, the same value to managers as they do in Scrum. The overhead in administration and time that sprints bring are not worth it at all, though. And if management wants, commitments and planning can be done against a deadline, in the same way they'd do with sprints, just without the artificial short periods.
The tweet however contains lots of bad management, and general bullshit otherwise.
"Imagine having a manager, a scrum master, a product owner, and a tech lead. You had to answer to all of them and none simultaneously." I think this is fantastic, not having a single boss, but having different "hats". One person can also have multiple, for different projects. In my experience, this worked out well.
T-shirt and poker.... I don't see why they don't work as analogies, and therefore this is moot criticism.
Even the author himself acknowledges: that wasn't scrum, they were doing scrum wrong. So stop doing scrum? Why not do scrum better? What makes him think that the same bad management will do any other methodology better?
Management decided that the company needed to implement the 5S workspace management system company wide. In short, one focus of the system is to help you put tools and materials back in the right spot to keep the workspace organized for the next person that needs to use it.
This is helpful for organizing the manufacturing workspaces where different employees would be coming in on different shifts and using the same space.
They had engineering (software, mechanical, electrical) doing the same thing. They sent up rolls of different colors of tape so we could mark all the stuff on our desks and asked us to write documentation about our workspaces. We were all marking off with tape "Keyboard", "Mouse" and "Stapler". It was truly asinine. I left the company shortly after that.
In ops, I think sprints work uniquely terribly. Lots of super urgent tasks come up in a normal workday that aren't always captured in the workload or capacity planning, and some times are much more interrupt driven than others, leading to similar issues.
Another issue I had with it, it did not really encourage me to be super productive . Like, I took on 16 story points this sprint, finished them all in a week, what possible incentive do I have to take something off the backlog and squeeze it into this sprint when my teammates (some of whom are paid more than me) are doing half of the "points" I am? It creates tension where I don't think any is needed. To make things worse, the system is easily gamed.
Another thing is I think it created way way more meetings than was needed.
For me scrum is daily 10min meeting and that's it
and I like it, I don't have problem with one quick meeting to sync.
But when I hear stories about estimations in some imaginary units, then it sounds bad.
> She already knows what she is working for, and she is motivated enough. When she finishes on time, organize a meeting and give her a $500 check in front of everybody. This is what a good manager uses meetings for.
One of our engineers today said that he felt bad that some of the cards were on the board for so long. He was self conscious about some false sense of velocity that was expected. I told him it's just a page on the internet with some text on it. Scrum, with its frameworks and ideology and self righteous way of looking like a way to be performant and sophisticated, is just some words on a page and some performative meetings. Poor guy was getting distracted by that.
The goal of scrum is to let middle management and non coders bring Science(c) to the organization. There's a culture fostered by executives, consultants, that posits that engineers don't understand what to work on and waste time, therefore we need this stuff to run a tighter ship. As it happens, it'd also what justifies middle management's jobs.
Scrum is good at tightening things that work, or making work feel predictable. A lot of growth scenarios or experimentation aren't predictable, so it becomes more like a broken dogma that serves the needs of the bureaucracy.
Borrow the best fitting ideas from each methodology, but don't obsess on them.
Also agree with minimal meetings. 1-2 meetings/iteration. When new people start we'll add some office hours time every other day as needed until they get up to speed.
I absolutely hate guidelines and processes and methodologies. I'm totally not a team player either. I need to have my own responsibilities. As ISTP personality these things are totally contrary to my personality.
As such I hate every methodology, of course right now agile (and Scrum as a subset of that) is the darling of every project manager so I hate it. But I do realize it would apply to every other type too.
But anyway I do as I've always done, the absolute minimum to comply with the framework and ignore what I can get away with. Because I get results this is accepted and I'm usually maneuvered into a niche area where I can perform.
For example I always stop logging my mandatory hours in Jira until I get reprimanded and then I stop again a few months later :P
Of course "logging hours in Jira" is our company's idea of "we're agile". We literally don't do anything else :P So it's easy to get away with.
Unfortunately, our management changed, and we were no longer empowered. The new manager had his own ideas for how things should be done, and that resulted in a replacement process that was worse. We lost the ability to do effective capacity planning and iterate quickly. It was terrible.
That’s really my biggest issue with agile. There’s a big focus on process, but it’s about the people. If the people aren’t empowered, it won’t work. If you’re not iterating and communicating, it won’t work. If someone’s not on board with that, they can sabotage things (intentionally or otherwise).
From the Agile Manifesto: Individuals and interactions over processes and tools. What you described doesn't sound Agile by the book.
> 3. We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.
This continues to be one of the most aggravating parts of capital A Agile software development. Forcing people to be uncomfortable to make them talk less is something a child would come up with.
I remember one time got in several conflicts with a manager who -again- is trying to copy-cat all these shenanigans like standup and what not even though neither the work nor the team nature fits that type of work, first, I wrote him that wasn’t the best approach and better to use these tools, second I tried to communicate that face to face, third, I actually applied these tools I was suggesting in a project I am doing as a way to show an example how it’s done maybe that will convince him, unfortunately, nothing worked with him, it was “my wrong way or the highway” approach, he wasn’t even certified PM with no training and I was, had to leave them after delivering my project.
But to me it just means trusting the devs, close cooperation within the team and with the customer, iterative development, continuously refining the bits of process you have to fit the needs of the devs at the moment.
Not something you have conferences about.
Agile roughly says that if you find out that what you're doing is stupid or impossible then change and do something that will work. If it turns out that the goals of the company are stupid or won't work how does it "realise" that? Lets say you're fulfilling a contract - you really need to go to your customer and tell them that what they want will end up being of low quality at the time and price you've agreed and that adjustments have to be made if they want a success. I cannot see any incentive to try to do such a thing so it's at odds with agile from the start.
Sort of the opposite of agile.
> Agile roughly says that if you find out that what you're doing is stupid or impossible then change and do something that will work
Exactly. But with Scrum, if devs complain it's not working, the certified Scrum Master will just say what you're doing right now isn't exactly Scrum to the letter yet, you need more Scrum.
OTOH when you're starting out it takes some time to find out what works and a scrum master will probably want to make you try to stick to the basics until you've given them a chance. Most people cannot see the point of one part or another until it has helped them personally once. After a while the team should be able to have a rotating scrum master - one of the team for a sprint.
But you can't change the process to be not-Scrum.
Once a company has decided "we do Scrum", you can't argue in retrospectives that sprints are completely artificial and unnecessary for the project in this phase, or that things would go much smoother if devs talked directly to the customer instead of through a product owner. Or even that tickets on a board are not a useful way to work at the moment. Things have to stay Scrum.
I talked to customers as a dev - it's just that customers couldn't come and pester me to make me do extra work or change priorities. Is that too hard or inconvenient to understand?
Scrum fits new development more than maintenance and I've never found any other "phase" where it doesn't fit reasonably. I've been in situations where I've thought we needed longer sprints.
Ultimately if the overhead is too much we used the retrospectives to remove it.
The problem is if you're the only one in the team that wants some change - then you cannot force it.
What you need to recognize with all these processes that go beyond the direct dev team is that they are not there for the devs. They're for senior leadership and non-technical executives to pretend they can have their cake (agile with responsive and constant delivery) and eat it too (waterfall with scheduled "final" delivery). It still sucks but this understanding does help you survive.
Not metric as in the measure of the effect of your code, but Jira (or whatever your task manager is) metrics. It systematize the process, without taking the actual work into consideration. This is why you get a "but you did the other similar project with just 50 points."
The metrics always win because developers end up working overnight to complete the project on time. So it validates the metrics.
My teammates message me when they find issues with their task. We discuss, hop on calls, involve other teammates, the works. But then on the daily stand up, we repeat the issue to the scrum master, even though this person could care less about the issue.
Scrum is a fantastic tool if your job involves making reports about the work being done. Except, it doesn't reflect the actual work being done. And my poor reader, you are probably not in a position where you can do something about it.
Here's my more comprehensive post the last time this was raised: https://news.ycombinator.com/item?id=37289151#37290237
The TL;DR is that he's just making unsubstantiated angry ravings and being treated like he's saying something meaningful because there are people on this site who happen to agree with him.
But if course, if you pay him, he'll say whatever you like, per his website.
I'm more interested in some of the comments I have seen here of people observing the adoption of Scrum as significantly reducing the velocity at what was previously observed to be well run. Maybe adopting the more formal process revealed an underlying organizational dysfunction that could remain hidden in the previous laissez-faire culture, maybe there's something wrong with how Scrum gets implemented at those places, and maybe there's actually something wrong with Scrum itself.
My only interaction with things explicitly described as "agile" (Scrum, or otherwise) appeared to be very large organizations mostly just renaming roles and processes that already existed, with a few minor changes that did not appear to have any effect (other than being able to claim that they were now "agile"), so I don't have any personal experience to answer any of these questions.
1: Though in defense of the ranters, you'll be able to find many Scrum consultants that will argue it can.
It's a pity that we do not have more people doing systematic research related with Scrum/Agile practices and it's advantages, Regarding on outcomes, in comparison with RUP, empirically we know that it worked better based on economic results + adoption/spread + people empathetic to use it in a corporate environment.
However, after 22 years of Agile/Scrum we do not know in a systematic and in a scientific researched way the second order (side effects) of Scrum as a management tool, and which kinds of incentives it creates. We know empirically based in a small amount samples.
Tldr; scrum is another tool in your toolbelt you can reach for. Some teams work better with scrum, some dont. Experiment and see which one works - ultimately the goal is the same which is a productive, well oiled machine, regardless of the ‘how’
Different teams get by with different amounts of Scrum Processes.
Less experienced ones need the full-on shit with backlog grooming, planning poker, dailies and retrospectives.
When the team gets better (and there isn't much turnover), you can relax the Processes.
I'm pretty sure I might be the only one on HN who has Scrum actually work in real life. (I've had my share of shitty-Scrum too, like 45 minute "dailies"... =)
His pain seems to be real, even if it is not even connected with scrum.
What makes it really sad: all of this can be fixed very easy - the company "just" need to hire somebody who is able to address the underlaying root cause of this anti-pattern.
1) "1. They tried to convince me that Poker is a planning tool, not a game." Planing poker has nothing to do with scrum. It is an estimation technique. Just do "no estimation" and if it works for the team, everything is fine. Also it is a planning tool - if you didn´t understand how it works, maybe a quick google search could be helpful.
2) Scrum does not have "ceremonies". They are called "events" and can be extremely efficient - so if you spend more times in those meetings than actually working, something is very very wrong. Maybe get some outside help, have a retrospective that is done properly and understand the root cause?
2) "Scrum of Scrums" is not part of scrum - this is some scaled approach. Based on what he described it is most likely the anti-agile SAFe frankenstein of frameworks.
3) "We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention." -> WEIRD. People should pay attention to the actual meeting? Also none of this is part of scrum.
4) "We spent more time estimating story points than writing software. Story points measure complexity, not time, but we had to decide how many story points fit in a sprint." -> this is not scrum. This is whatever the team came up with.
5) "I had to use t-shirt sizes to estimate software." -> this is not scrum. It is estimation techniques.
6+7 "story points" are not a part of scrum. Agile contracts are a common practices however, but contracts based on story points are weird, because story points are a relative measurement that cannot be compared (same as velocity)
8. "Imagine having a manager, a scrum master, a product owner, and a tech lead. You had to answer to all of them and none simultaneously." - Scrum does not have the role of "manager" or "tech lead". So obviously you are not doing scrum.
No agile book or manifesto ever mentions this issue, because there simply is no solution for it.
Remember when wall street was complaining about how Bezos was running the company? If an accountant was in charge Amazon would have been quarter packing to please wall street, and would be much smaller/out of business.
The dev team keeps getting yanked around and interrupted. So every two weeks you get all the business people in a room and you have them make a list of things that the dev team will work on this cycle. Then the dev team can execute in peace. The Scrum Master's job is to protect the dev team. The Product Owner's job is to get the business people to converge on the prioritized list of work.
In a healthy organization, Scrum is much less useful. Scrum combines three different cycles: defining work, executing work, and reviewing work. In a flow-based process like Kanban, you can split them up.
The product manager builds a prioritized backlog of work, and the dev team estimates tasks to help do business ROI calculations. It's a collaboration between product and development.
The dev team implements tasks from the backlog one by one. You can batch up work to make a release, deliver incrementally, or use tools like feature flags. You evaluate whether features are effective working based on metrics.
It's really about teams adjusting themselves to whatever behaviour and process works for them and managers hate not having control. So it's inevitable that any method which gets adopted in name at shitty companies will be "enshittified".
It should also very frequently reveal issues. In misunderstandings, planning, underestimation, dependencies. This is a good thing as you can then course-correct early.
That said, it is soul crushing. Some jobs/tasks just don't fit into SCRUM yet one is forced to adhere to it anyway. There's way too many meetings. The boundaries of roles are not respected. Quality is not rewarded, only story point delivery. There's typically no feedback loop from users/the market as to whether actual value was delivered because you're working on the next sprint. Product owners are not actual owners. Scrum masters act as project management.
A typical scrum team easily costs 1M to run even here in Europe. And yet they produce so little. If you'd hire 3 A-class players in a high trust environment they'd produce 10 times more at superior quality.
True comedy is found in "scaled agile". This is where the SCRUM elite of the company get the teams together and ask: tell me for the next 6 months which stories you will deliver and figure out all the dependencies.
Mind you, near-zero input is given. You might as well roll a dice. And still we're all here to pretend that this insanity is normal. I no longer fight it.
I actually feel bad for business owners. They're setting on fire some 50-70% of their hard-earned revenue on talking and book keeping.
The company isn't trying to optimize for best use of your time individually or to make you happy. They are trying to get some kind of result. And it very well may be worth inconveniencing and annoying higher performers to improve the performance of lower performers to achieve the result they want.
So your management wasn't doing their job? They're supposed to know who's working and who isn't regardless of what rituals are practiced.
I got into management because I like solving problems and I reached a point where solving purely technical problems is no longer what it takes to actually drive a product forward and improve things. The problems I try to solve now are more organizational so that dev teams can actually reach that creative state where they are talking with the customer directly and engaged in the overall process. I'm an introvert. The face time and accolades are draining, but it's important work that you've got to be in a leadership position to take on effectively.
That is my understanding of what people name scrum or agile. A management harness with fancy words. The real benefit is when you let people do their work, gain experience and make them self organize their problems.
You get the senior devs who have been a law unto themselves for years and they certainly don't like anything that distributes power across the team. It might mean they have to do work they don't like sometimes.
From the start they're out to sink the whole scheme and even one of those in a team makes it very difficult to achieve any change.
That's just ontop of the fact that middle management don't like a method that removes their ability to interfere with the details or put pressure on individuals.
And of course in the end there are those developers who expect to do nothing but write beautiful lines of code all day long and consider every other part of delivering software to be beneath them - reviewing other people's code, writing tests, working on requirements, maintaining old code.
Until, of course, the things you want to improve are never in the sprint and you have no free day to tackle anything you want (and the project needs), ever.
Bonus points for using Product Increments and abusing the Innovation and Planning Sprint as buffer that always gets used.
I am in another section and we have retro meetings but they take 1 hour or less. Anyways, what caught my attention was two very stupid things introduced by their scrum master:
- estimating story points for completed tasks: they went over each ticket that was marked as done and asked how many days it took to complete the task. Me and the others on the car couldn't believe what we were listening to.
- making JIRA tickets for useless things like "how to install software X". We have a guide on Confluence with instructions on how to install said software and if you follow the guide from start to finish you can get it working and it shouldn't take more than 20 minutes. If, for some reason, it doesn't work, you can simply contact the author of the guide and ask them for help.
This is not what happened in my colleague's team. They had to create a JIRA ticket to track individual progress on installing the tool. I talked to this other colleague that created the guide and he said he was almost pulling his hairs out because he had to spend more than 2 hours debugging and troubleshooting with the people that apparently can't read a step-by-step guide on their computer. And then later they had to mark a JIRA ticket as completed.
This is very stupid and when I see this colleague of mine suffering with someone that is evangelizing SCRUM as any other meme scrum master out there just makes me hate it even more.
> If, for some reason, it doesn't work, you can simply contact the author of the guide and ask them for help.
> he was almost pulling his hairs out because he had to spend more than 2 hours debugging and troubleshooting with the people
Irony? Irony..
It might not be the best question to ask given the complexity of the software and experience/culture of the team.
The key part, however, is teams, departments, and companies, then modifying their actual working by eliminating ceremony and process.
The way I think Agile/Scrum/SAFE should work is that you expose all the teams to all the ceremonies, and all the different alternatives to each of the ceremonies to start with, but you also mandate thst 6 months to a year from now you should have reduced 50% of the ceremonies you started with.
The goal should be expose people the universe of options and ideas available, and then once exposed, require them to pick and choose between all these options to tailor their own customized solution which works best with the people on their team and the working styles and the kind of work they’re doing.
Mostly because launching changes so much.
Part of me does feel sometimes that ceremonies are for making sure the development practice is highly inclusive, including for new and less skilled developers still learning their ways. Another part of me thinks about how this also helps more people to be able to generally help with more of the codebase.
I think writing code for your future self or someone else, in a way you'd like to receive is critical to think about. This can include doing things the simpler way even if it's more verbose and more understandable. This isn't always possible, but more often than not, avoidable complexity also can encourage the engagement of a lot of ceremony around it. "Could this have been simpler?" is one useful question for code reviews.
Here is an answer that (I believe) works well: Hire a team lead that is willing to shield a small dev team (less than about 7 people) from the politics above. The devs still talk to users and other people in the company but they do not necessarily have to be accountable to them. The team lead understands the company’s budget cycles, has a vision for the product being developed and, importantly, has the time to sit down with each developer on the team to look at what they are making. Not a code review but a regular show-and-tell kind of arrangement. The fine line in this approach is to make sure it doesn’t degrade to micromanagement and ego poking.
Sometimes a lot can be understood from the team and it's current process in terms of where it did, or didn't come from.
Having a team lead that is technical as a product manager can be very helpful as you are outlining. Being able to speak the language of and maintain the respect of both is so valuable in terms of "getting it".
Clearing the way for devs to learn and do with customers and each other is the other key thing I think about a lot.
Startups likely have less politics (hopefully) but the longer they operate as startups politics likely increase, or hides itself better.
When I see startups leaping to hire VP engineering, etc, I can't help but think of my own experiences where having the founders at those seats translating what is being learned from customers directly into the product was so critical.
For existing or larger organizations, I think what you're saying is very true.
All of these are organic rather than formulaic. They require limited rates of growth to enculturate the new hires, and a seed group that understands this.
That works. But you can't hire a consultant to build that, or write a book about it. And bad elements in the mix can mess up the whole thing.
I heard an interesting explanation the other day, hard skills are easy to measure, and soft skills are hard to measure, but developing soft skills can be are more important than hard skills.
“How Big Tech Runs Tech Projects and the Curious Absence of Scrum”
https://blog.pragmaticengineer.com/project-management-at-big...
My own experience has been similar.
Start with keeping a very flexible core and codebase.. feed it with launched code from a plan that balances bug fixes, progress forward, and customer needs from the business.
This meant having a backlog, and by scoring each item on criticality where 1 was critical and 6 was someday/maybe, and whether it was internal facing, or external facing (customer is aware), you could almost start selecting what was done and ready.
Would love to hear anyone's processes they used that have worked well for them from start to growth.
It identifies if anyone will be stepping on anyone else's toes, or if anyone knows of something similar and can point you to it, and it lets the project manager know if anyone is working on something that can be traded for a higher priority task that just came up.
Most of the time, you work on what you say you're going to work on. Sometimes, the project manager will call you after standup to get more detail and/or adjust your priority to a different task.
This standup is the only formal meeting the developers go to, other than the odd department/company wide meeting. The project manager goes to all of the other meetings.
We are the most productive team in the company. I think the autonomy and the lack of formal meetings are the real magic. We're fully remote and talk to each other plenty throughout the day in an adhoc way, sometimes for fun and sometimes for technical discussions, problem solving, brainstorming, sanity checks (technical and personal), etc.
"I was figuring out how to add a doohickey that widgets foobar" is not a commit, but during the daily someone else might remember that there already is something that can widget foobars. Or they might know that widgeting foobars was tried before and it failed because X and Y.
Then they won't start debugging that during the daily, but will point it out and get in touch afterwards along with others that might care. Either on a $TEXTUAL_MESSAGING_APP thread or $VIDEO_CALL_SERVICE call.
To my experience 10% of software developers think 7 am is morning, 60% something between 9 and 10. 30% not before 11 or 12. The first and the last group tend to be the most productive ones.
Forcing all of them to meet at 10 or even 9 is the best way to kill motivation and foster cynicism about useless meetings and processes.
SAFe is the next buzz word laden cancer to infect the enterprise. It will bring Business Agility(tm) to areas of the business beyond software development.
Consultants love it!
The ball feels a little gimmicky but otherwise in general I am in favor. The whole point of no laptops / standing / forced attention is to actually cut down on the meeting time by encouraging people to be present. When people can tune out and multitask, you get wasted meetings. If people are paying attention, they'll call out time wasting.
> I had to use t-shirt sizes to estimate software.
Why is this a problem?
> We spent more time estimating story points than writing software
This I just really don't believe. Perhaps it was meant in jest / hyperbole and does not actually represent a true accounting of time. If actually true, this is not a problem with scrum, but with your organization. Just because a process is misused doesn't mean the whole thing is useless.
> scrum is not for developers
Probably the biggest thing I definitely agree with. You know what else isn't "for developers?" The existence of the business itself.
* Split up into multiple teams under different kingdom building directors/VPs
* More time is spent defending Jira SLAs and deflecting blame than actually solving problems
* Dev teams under different managers have an adversarial relationship
If the above is true, just adding a standup for a given initiative that includes all of the team members and just normal human behavior of exposure builds a little trust and collaboration is a miracle pill!
Albeit it's a 'miracle' pill that takes the org from laying on the ground kicking and screaming to slowly making code changes that no customer wants - but comparatively it looks like a miracle to legacy management!
The real solution is to fire 3/4 of the management staff and take the next 3 years to rebuild an effective organization. <-- however, this doesn't sell like a SCRUM Miracle Pill™
"Why didn't you finish this story? You committed to us you'd finish in two weeks!!" Perhaps well documented rapid iteration processes naturally tends towards dev mistreatment, but I genuinely hope not.
My dream world is where devs can aim high, fail, and try again as many times as is needed without being judged/penalized.
- Death or Scrum? - asked the CEO
The employees knew nothing about this Scrum thing, but were to intimidated to ask and the other choice was one they were not ready to make.
The first one thus replied in a quavering voice: "Scrum"
In this moment the first employee was grabbed by the CTO and was put through horrors not many could withstand:
- Neverending sprint planning meetings
- Daily Scrums that lasted 4 hours
- The sprint reviews
- Sprint retrospectives
- The backlog refinements
After all this the employee was only able to say: "Still working on User Story XYZ. No impediments."
The CEO then asked the second employee what their answer was. The employee was fighting a tough fight in their head.
"I hate meetings, I would love to do some real work, but I'm not ready to die yet. On the other hand, I can't go through life after all that abuse; There's no way I could live with myself". So he answered: DEATH!
To this the CEO swiftly replied: Death ... by Scrum
Scrum is garbage. Most software development methodology is garbage. And even if there are theoretically-good ones that are "only" garbage because people "implement them the wrong way", that too is the methodology's fault. If something is so hard to implement that most people get it wrong, with disastrous results, then that thing is indeed garbage, regardless of its merits when "done right".
We apply this principle to technical process: if someone manages to delete the production database, it's probably not that person's fault, but the fault of the processes around access controls and incident response. If everyone implements scrum catastrophically wrong, that's scrum's fault.
> We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.
I think the no-laptop thing is good, and unsurprisingly, it has nothing to do with Scrum.
> Story points measure complexity, not time, but we had to decide how many story points fit in a sprint.
Out of all the bullshit that makes up Scrum and (what has become) "Agile", this is the one that clogs the toilet. I can imagine a world where this idea of "complexity, not time" is done properly, but it's not this one.
Srumm is Agile™. Real Agile means working in incredibly fast feedback loops, to the point where you can't tell it's part of a process, because it's all working so fluidly. Trying to put that into a series of rigid set meetings is the antithesis of that.
Consultants suck the meat off the bones and resell the skeleton, then management wonders why the specimen doesn't appear to be the genuine animal.
This article from 2021 illustrates the different ways of running projects and the tradeoffs that are involved:
How Big Tech Runs Tech Projects and the Curious Absence of Scrum
https://newsletter.pragmaticengineer.com/p/project-managemen...
The new methodology was quickly pre-empted by middle managers as a new power tool, Scrum mostly replaced Agile because of all the weird cargo-cult rituals and sexy names.
My experience with it has been widely negative. People staring at the void during "standups", bullshit amplification, ticket misuse and misread by management.
Never seen any improvement from it, only overhead and demotivation.
With my team, we’ve focussed on developing talent just as much as we have on getting the work done. By improving skills through senior-to-junior coaching and code review we’ve built a much more cohesive team that’s better at what they do and can complete tasks which they couldn’t do before. Dexterity and fluency with code was more important to us than organisational skills.
Perhaps I’m missing the point and Scrum is only for people at the top of their game? It didn’t feel that way the few times I’ve seen it — to be a little bitchy, it appeared to be quite the opposite.
Things like weddings, graduations and funerals are important moments in life that cultures all over the world honor with ceremonies of some kind. Your quick morning meeting to discuss what you're working on isn't a @#(#(#( "ceremony".
I've seen (and managed) plenty of Scrum, good and bad. In general I prefer Kanban approaches, but I don't think it's the deciding factor in team performance by itself.
I'm interested to see when we reach the point where it's no longer the default methodology everyone reaches for because "Scrum is how you do agile".
To one manager scrum was a 30 minute sit-down chat in the conference room. To another manager was 2 minutes stand in the hallway. To another manager was a waste of time and he will come to each dev cube and get a gist of what we were doing.
A software development is only a team only in name. If developers like to help each other and talk to each other without having to be rounded up like gerbils is more of a fellowship.
I think it's a mistake to think in black-and-white terms about management approaches. It's a mistake to adopt scrum rigidly, and it's a mistake to reject it in full.
Instead, we should look at what works and what doesn't, and consider their merits on a per-project basis.
So at the risk of being a contrarian, here are the ideas that I personally think are valuable from scrum:
(1) Break down bigger projects into smaller ones. I'm not sure it's beneficial to rigidly define a spring as 2 weeks. But the opposite of this is endless scope creep, where there's no clearly defined finishing line. By my definition, some springs might take a day. Others, several months. It really depends on what we're trying to accomplish. The smaller the period of the sprint can be, the less risk there is of losing focus. To paraphrase Einstein: Sprints should be as short as possible, but no shorter.
(2) Sprint planning may have too narrow of a focus, since it's entirely focused on the upcoming sprint, rather than the big picture. But I prefer it to going into detailed monolithic plans (i.e. waterfalls). No plan survives contact with reality, and the further out you plan, the more fictional your plans become.
(3) While I don't like fixed meetings that repeat with a specific rhythm (i.e. what scrum calls "ceremonies"), there is value in at least considering them on a per-sprint basis. Not every sprint justifies a daily stand-up, iteration review, or retrospective. But they do have merit. I just think they should be evaluated on a case-by-case basis rather than applied across the board.
(4) I have mixed feelings about product backlogs. On the one hand, they spare you from trying to plan out how to implement every request under the sun. On the other hand, they encourage you to simply go to the backlog and pick things you feel like doing for the upcoming sprint, rather than being focused on the next most important things. Important things don't need backlogs to be remembered. Important things will keep coming up, over and over. You're not going to forget them.
(5) The term "scrum master" is icky for many reasons. But I do believe someone should be in charge. Search all the parks of the world and you won't find statues to committees. Leadership matters.
They are trying to apply scrum and agile to us. It is not working.
I've been told ot to work on anything without a ticket. Outages have gone up.
It's a disaster.
https://www.linkedin.com/feed/update/urn:li:activity:7101572...
Not extraordinarily insightful but an amusing take on occult ritualism as engineering.
https://www.visual-paradigm.com/scrum/scrum-pig-and-chicken/
https://www.scrum.org/resources/chickens-and-pigs
That's when it stopped being about teamwork and started being about micromanagement.
I'm not saying scrum and agile achieve the above. But what does? Seems like a 3 things pick 2 situation, and the 2 that get picked will time and again be the last 2.
Agile/scrum is almost explicitly contrary to this goal. There is a chance every two weeks to change scope, requirements, direction. What happens when requirements change? Work is redone, new work is taken on, dates get pushed. Scrum does not provide predictability beyond one sprint, it is part of the point. The work of the next sprint is based on the outcome of the previous.
> I'm not saying scrum and agile achieve the above.
Companies abuse scrum to try and achieve the last 2 objectives. Sprints become commitments, sprints are planned out in advance, story points become days etc
I really did not read your statement carefully enough and I apologize for that.
Bad managers would certainly like to do this but this is not what scrum is about
Opponents were ridiculed and bullied by proponents for being boring, old, unmodern, not team players, not using best practice or whatever. And way too many programmers were actual believers for grumpy safeguards to be able to keep things in check.
I think a cooperative approach might be better to get rid of agile or it will just be replaced by some other dogmatic cult. Agile is more of a symptom than the root cause.
Interestingly, me consulting solo at an hourly rate doesn’t scale. To solve this, about 5 years ago I started a side business of building an electron app for designing and printing labels. I feel like scaling up allows my customers to pick all 3. The app is immediately available, it works, and it’s inexpensive.
So there’s another way to avoid agile and scrum: solo entrepreneurship.
Good luck!
As an example, "Individuals and interactions over processes and tools". A standup is interaction between individuals. I believe it was invented to get away from the formality of heading to a meeting room and waste time with a long agenda. Instead, short and concise, stand up around the desks just where you work. Short, efficient, concise.
However, now it may have outlived itself in many teams. We work more remote, have other tools than 15 years ago. So if it doesn't work, don't do it. But if you don't know what to do, you can use Scrum as inspiration, and take it from there. There are certainly worse ways, because Scrum was not born from nothing. It was a reaction to a worse way of working.
One dev flat out refused to stand. I can still see the pulsing vein on the neck of the project manager who so wanted to scream ‘You will stand during the standup dammit!’
There's no project manager role in Scrum so he was already doing it wrong.
Pepperidge Farm remembers!
Due to this level of flexibility, it's always the right approach.
Scrum tries to provide a measure of velocity in such a subjective manner, it is not useful to anyone involved.
Why doesn't Scrum be a thing for humans? I feel like I'm a robot who has to be predictable all the time.
The title felt oddly hollow.
Just because a so-called "Scrum Master" not worth the title is forcing you to do BS things that inhibit your flow does not mean it's emblematic of the species. I mean, how would you feel if someone generalized all developers as a bunch of fat neckbearded social cripples reeking of BO? Same thing here.
I ought to bookmark this post in case anyone thinks that people on HN don't try to farm karma Reddit-style. What a crap bunch of outrage bait.
If only people weren't so ignorant, we could give pure Scrum a try and solve all the world's problems.
They are right, however the conclusion that should be drawn from this is that the most likely outcome of your organisations implementation of agile will be equally as poor, and that it should prolly be skipped.
What did you expect the parent commenter to say? "you've done well and have shown that scrum doesn't work"?
Obviously the people charged with implementing this in OP's company are doing it wrong. That doesn't mean it's OK to insinuate that everyone who ever tries to implement Scrum or Agile is doing it wrong. For every clueless toxic manager who doesn't understand how to use Agile correctly, there's an egotistical or lazy dev who also wants to throw what the Brits would call a spanner in the works for purely personal reasons.
But to call it a No True Scotsman argument is a lazy rebuttal which won't engage with the argument. There are plenty of shitty Agile practitioners, and no one is trying to dispute this.
Anecdata Of One: I have worked at many places since 2005 and the most successful projects have been those without any Agile[1]/Scrum imposed by management. In contrast, the places with the worst outcomes[2] have all had distinct Agile/Scrum imposed by micro-managers[3].
[1] Plenty of places with iterative development but solely due to the nature of the work (changes required by external QA, experiments, etc.), not imposed.
[2] Software quality and speed of development-wise. They're all still alive and limping along despite the horrific nature of their internal systems.
[3] Who have always been there in a place with Agile/Scrum. Only once in a place without. I don't think it's coincidental.
It seems to me that most American software companies use Cargo Cult Scrum. They basically take the terms and maybe read a blog about the processes and just wing it from there.
The only way an Agile/Scrum process works if you bring in a consulting company that's expensive enough to make even the top brass buy into it. You can theoretically try to bring it in from the ground up, but it's really hard to do Agile when the rest of the company is either waterfall or flying by the seat of their pants.
"I disagree with you and here's why!"
"I'm sorry that you're personally offended. See, you disagreed with my pure, sweet, logical opinion, which means you must be personally offended, because no REASONABLE person would disagree with me. And because you're offended, you operate on emotions, as opposed to my high-and-mighty self, who operates on pure, sweet logic. Thus I am right and you're a crybaby, because you dared to disagree with what I consider to be my pure, sweet logic."
Agile was needed, to replace waterfall management of software development projects. In particular, trying to do resource leveled critical path analysis for most software projects is the road to project hell.
But, yeah, Scrum, as too many Scrum Masters practice it, gives Agile a bad name.
That's part of it. In more practical terms, assigning people to tasks tactically as a project progresses is probably 80% of the advantage of Agile.
You are also spot on that you can start an Agile project and find your architecture is a pile of poo 2/3rds of the way through, in part because you can start without the waterfall set of specs.
A lot of the dissatisfaction in the "Scrum is cancer" article is about estimation, and I agree: Trying to improve estimation is a fool's errand. Your highest risk tasks are generally what create the most value, solve the hardest problems, etc.
More emphasis on retrospectives, and accepting that estimation fails most of the time, is what a lot of Scrum-as-a-cargo-cult misses.
I believe in this concept, but the implementation… is risky and invites failure. … The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.
It's incredibly frustrating, because so many of the things he says suggest that he or his organizations truly don't understand scrum, yet he proactively goes on the offensive against anyone who suggests he's wrong and won't listen to any evidence that he is. (And yes, I get that this post is just a 'vent', but 'just venting' content is not usually the sort of thing I expect to see make the front page of HN.)
I have been on multiple teams, including my current one, where Scrum has been a massive success (as measured by products shipping on time and in-spec with positive reception by customers, as measured by the company making money off my work, as measured by my own and my team's performance assessments relative to my org). Absolutely none of the following happen on my team, or on any team I've been on where things were working in those terms:
> We spent more time talking than doing. > We spent more time estimating story points than writing software. > We measured how much it cost to deliver one story point and then wrote contracts where clients paid for a package of "500 story points." > We paid people who told us whether we were "burning down points" fast enough. > We brought professional Scrum trainers. We paid people from our team to get certified. > We spent years [continuing to try things that didn't work].
Absolutely none of this happens on my current team and absolutely none of this is required to do Scrum "right" or at all. I've been on three teams in my current organization and five+ teams overall that used Scrum over a period of more than eight years and while all of them had issues, none of them did any of the above. I'm sorry this person has had so many bad experiences, but at a certain point, you've got to ask whether your attitude and approach are part of the problem. I see a lot of things in this person's attitude that make me think they could be.
For example, he makes comments where he just whines about not liking terminology, like:
> 1. They tried to convince me that Poker is a planning tool, not a game. > 5. I had to use t-shirt sizes to estimate software.
He also phrases sentences which are not arguments (or at least, are not really relevant without some explanation) as though anyone should understand why he's mad:
> 3. We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.
and then finally, spends lots of time asserting (with no evidence) things like:
> [Scrum] fails everywhere, every time, but they tell you “you aren’t doing it right.”
while simultaneously talking down anyone who tries to suggest he's maybe, legitimately not understanding Scrum.
If this is the approach he took with the people who were trying to help him implement Scrum, no wonder it didn't work. It was probably never going to.
By the way, this person offers a service where you can pay him to present "learnings" about your content on Twitter, or wherever. Without disclosing that the content is sponsored. Pretty scummy. See https://www.svpino.com/
https://github.com/rayfrankenstein/AITOW/blob/master/README....
> https://www.parabol.co/resources/agile-statistics/#agile-eff...
It's the Internet. You can find a few thousand (or few million) people who love or hate anything.
What's your point?
It’s a joke that writes itself.
the whole structure gives enough support, retros surface problems and give sufficient pushback against "features only, no bugs" management style, sprints gave some sane cadence to both devs and product, daily status checks help to detect folks who are stuck, "refinement" forces both sides to actually commit to some kind of written stuff, and "grooming" provides much needed priorization and black comedy relief as the team tries to come up with a non-pedo expression for the activity.
of course, there are valid criticisms of scrum/agile. mostly that it fails to teach developers to realize their need to set boundaries with regards to interaction with "the client", aaand that most managers and projects are non-ideal, underfunded, and devs should leave it, and look for better ones (even with possibly lower pay).
I got so tired of hating Scrum with passion, that I pulled a 179 and wrote a comic book about it.
In your honor for your courage and honesty, adrianmsmith, it's free, today only. All enjoy!
Agile and Scrum are for managers who don't know what they want, but they'll "know it when they see it". (Or more likely, they'll declare that they wanted is what they've got when the money runs out.)
Just stay away from it, if at all possible.
Yeah, most aspects of Agile (iterative development, MVP...) are fantastic and it has made most types of engineering lighter, more team-focused and well more agile.
We would like to try but we can't, as "everyone else here does Scrum so the problem is in you, not in the process".
If there are some teams in your organization or company using kanban, you can use them as an example. If issues brought up in the retrospectives are not being addressed and those issues are related to the scrum process, then that might be a way to get something to change.
You don't have to produce an alternative to critique something. In fact making such a requirement makes problems linger.
The say they are doing scrum, but they aren't really doing scrum
He says he's a christian but it's clear to me that he wasn't one all along.
So any successfully communicated methodology is going to be claimed by lots of hypocrits and then perverted while they simultaneously boast how much they love it.
And then you'll get the opposite kind of person who doesn't believe in forgiveness or loving their neighbors and sees a great chance to attack those ideas by supporting the hypocrits deception and claiming that their perversion is the real (evil) religion.
None of this helps software get built but is just a power struggle between developers who don't want to reduce the bus factor or despecialise or write tests or do maintenance or change their great plans to suit circumstances.
A sad take that's based on a sad experience with a great framework.
I dislike Scrum quite a bit, but oh gee ain't that a full plate for Scrum apologists to have a point.
Companies were making poor technical decisions for short term business reasons long before agile became popular.
The cancer you seek is actually called capitalism.