Leave Scrum to rugby, I like getting stuff done (2020)
wagslane.dev
wagslane.dev
I disagree with 1 thing in the article though: the estimates.
> A simple estimate of “how many days?” would have been easier to think and reason about, while also providing more granularity.
How many days will it take you to do this task? - you can ask the team
* Ben, a junior dev, says a week.
* Carol, a senior dev, new to the company, says 3 days.
* Dara, a team veteran, say 1 day, at most.
That's why estimating using time is wrong, because time depends on an individual. Instead of asking "how quickly can you run to that building?" ask "how far do you think that building is?". The distance is independent of anyone's skills. The complexity of the task does not depend on how skilled you are, that's why we're using abstract units, to measure the size, not the time.
Your anology assumes everyone knows where the building is, that they know how to run etc etc
If you measure on size of task with modifiers for tasks novel to the entire team, the differences will usually average out.
External stakeholders may see that over time you end up with performance and estimates averaging out to match up, but that’s very vulnerable to turnover in a team (a few juniors join and the team is underperforming and it’s all the juniors fault) and the internal team dynamic does not mirror the external.
Tasks and engineers are not fungible, allocating the right developer to the right task and giving it a developer-specific estimate will have much greater results.
Estimates are there to help you forecast what you can get done within a particular time period, which in turn helps you prioritize units of work.
Using them as post-hoc commitments and second-guessing your team is toxic.
I agree as a default scenario, you are correct.
However, we always need evidence to show if a team member is struggling and needs extra assistance, or in the worst case is not contributing positively to the team. This is not over a single blown estimate but rather a larger pattern of underperformance.
This is the failure mode, however.
I can see how the post reviews could be toxic, but pre estimates could also be toxic especially if estimates suddenly become hard deadlines. I think it comes down to nuance in both cases.
Post estimates could tie into performance reviews and bonus allocation as well. Where your bonus and performance would be a tight feedback loop, and determined by multiple peers vs. a single manager.
It really depends on each individual org which way works best
Now your colleagues aren't estimating the task, they're estimating the post-estimate. I'd suggest adding Goodhart's Law to your reading list as well.
Every single time I've seen estimates tied to anything performance related they've been actively gamed and lost their utility as a forecasting device.
Because I also have a development background too, I just tend to look at custom features through through the lens of “how much time this feature would take me”, then add a few multipliers and cross my fingers that the faster and better devs pickup those stories so we don’t lose money.
Maybe it's just me, but usually the estimates get longer with seniority. It might take them as long as you said it would, but the stated length would probably be reversed, since the more senior employees can easily see the pitfalls and the required housekeeping that the task brings.
You could see someone was junior, when, after implementing 6 points in the 3 hour allocated, they say they would finish the remaining tasks in 1 or 2 hours. The people that were more senior, took a bit more of time to think about their estimates, given the knowledge they had gained during the past 3 hours, and usually they will give a 4 to 5 hour estimate.
The dangerous thing about inexperienced people doing estimates is that they have no idea of basis on where to do estimates from.
Estimation is a halting problem.
"Great, Ben and Dara can you handle this together?" To give Ben a chance to grow and Dara a chance to show leadership/mentorship/develop institutional knowledge.
Alternately: "Okay, a bit disparate. Dara (or whomever) how are you thinking about solving this?"
“I think it will take 5 days but it’s complex and I’m not sure”
“It’s taking longer than I thought because it’s complex. But marketing isn’t ready so it’s not my top priority”
“Marketing still isn’t ready so I’ve deprioritised it”
“What do you mean ‘I promised 5 days and it’s entirely my fault it’s late?’”
Also, in all the teams I’ve been the devs had no problem using the points. The managers are the ones that force a link between points and days. In that case the author says: just use the days.
So what is the point then? We can abstract away distance. It doesn't help you cross that distance.
> To that, I propose base-2 exponentiation based on the scale you care about in the first place, time.
> 1, 2, 4, 8. Hours, days or weeks.
I think this is actually a pretty good system. The point being that estimates get less fine grained as the size of the task increases, which is pretty sensible.
I can't count the number of times I've heard this argument by SWEs who think their job is just lines of code vs accomplishing the business goals of a program that pays them. It ultimately boils down to "I don't want to report on what I am doing or how I plan on doing it."
There are many meetings that are valuable, but they are valuable because people put effort into making that time valuable outside the meeting. Meetings should prove themselves.
That's... not what he said at all. "Getting stuff done" means accomplishing business goals more than it means lines of code, so you're very nearly accusing him of saying the opposite of what he said. Feel free to go into the essay and search/replace "getting stuff done" with "accomplishing business goals" - it still makes sense and is completely accurate. Modern "scrum" gets in the way of just accomplishing business goals by pretending that they're perfectly predictable.
Where did you get that idea? The Agile Manifesto literally says:
"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."
Scrum is deliberately incremental precisely because it's designed to accommodate continuously changing business requirements that are NOT predictable.
The best weeks are when the manager goes on vacation so you don't have to put up with the daily bullshit. Also, every manager swears their scrum isn't like this. And every one of them is wrong.
What depressing places you worked.
I have worked once at a firm that had a daily meeting of developers. It was very useful, no expectations, we kept each other informed.
Why would you lie to your comrades? I can guess answers to that....
Go ahead and posture online about how you would never overstate your accomplishments to your manager I guess.
I don't care if some widget in Jira gets moved today or next Monday (but you're making progress to completing that feature/fix/whatever). I do care if you're literally making no progress.
The constant need to interject with help when "no progress" flags are thrown gets into the realm of micromanagement, and that is doubly so when every day or even hour of "no progress" gets treated as a crisis that needs to be solved ASAP.
Scrum fosters an environment of "no breathing room" for these frequent and common stretches of "no progress".
In my experience, "I got nothing done" is a giant red flag that the developer is actually stuck on something and not in a "I need a day or two to figure this out" way (because the developer would have said as much if that was the case).
"Do you need help?" coming from someone in a position of power over you could be either a genuine question, or a veiled threat to improve your performance ("or else"), possibly even unintentionally veiled on the assumption that a "gentler" way of putting it will be less stressful. For me, it's anything but.
If a "do you need help" happened several times in a row, I'd be getting an anxiety attack every time I get pinged on Slack, and frantically polishing my CV in the assumption that I'll get found out and fired any day now, fairly or unfairly.
Yes, I am jaded about this. That's why I don't like daily status updates.
On days when you get done very little shouldn't others be helping to figure out ways to get you unblocked and making progress again?
This is why, as a manager, I don't attend daily stand-ups. The meetings aren't for me. They're for the team. I've managed orgs where some teams had daily stand-ups, some twice a week, and others not at all. It was up to the team to decide what worked best for them.
In return for this magnanimous gesture, all I asked was for the work board to reflect reality and that people raise any blockers that I could help out with.
Need smaller teams so that the people in your stand ups are actually collaborating on the same project.
If the things people on your team are doing are not relevant to you, you're not a team in any real sense.
Then you've never seen scrum, regardless of what your manager told you.
Place I was working at, my boss arranged something of a coup so he could work for Boss-Boss-#2 instead of old, not "with it" Boss-Boss-#1. A project appeared, Boss-Boss-#2 wanted to meet with me. Told me we would be doing Agile, also when would I have this done? I hadn't seen anything at this point. Promised meetings with stakeholders; no such meetings occurred. And so on and so forth. But we were doing Agile, he said.
Despite having zero to work with and being ill the entire time, I delivered ahead of the deadline. Turns out the deadline wasn't real, nobody looked at it for seven months. Felt very nimble, very Agile!
It doesn't matter what the Manifesto says. It was written without orthodoxy. There are no section where it says, "If this doesn't happen, you are no longer Agile. The Stakeholders must be beaten with wooden rods, then they are to purify themselves in the waters of Lake Minnetonka. Should the PM fail to beat them with wooden rods, the PM is no longer Agile, and must be beaten by the devs." It has no teeth.
Well, it doesn't matter if no one in the organization has read it or committed to its principles, sure. The same can be said for a constitution, a contract, or the Bible. Just because someone says they're "doing agile" doesn't mean they are. I can say I'm the King of France; just because I'm wrong doesn't mean France doesn't exist.
> It makes leaders feel in control and informed. They know exactly what was done and when it was completed.
> I’m not against management being informed…
So seems like there is a little bit of passive aggressive pushback here about having to keep managers updated and in the loop about progressive towards goals.
The one thing scrum ignores is human psychology.
The fact that defense of scrum is so often manipulative, attacking critics personally or twisting what other people said is not good reflection of that system.
Personal guess: groups full of people with high interest in people and great social skills won't produce something like scrum. It exists only because tech can give decision power to people who don't have those.
Human psychology: to large extend the above. It leads to absurd conflicts and power struggles over nonsense. Then it blames people who actually reacted in predictable way. It creates unnecessary hard social situations.
It is also massively demotivating. In fact, the components of motivations in pretty much any other fields are autonomy, mastery, accountability. Scrum lacks all three.
That is not the way Scrum is meant to be implemented. The goal is to have a cross-functional, empowered team with the ability to make their own decision. The Product Owner - as part of that team - makes ultimate decisions as to what the product will be.
> It creates unnecessary hard social situations
Yes, social conflicts in team can be tough. Following the values of Scrum, respect and openness in particular, helps teams sort these things out. I know that in practice, it involves a lot of skill to guide a team through those phases.
> the components of motivations in pretty much any other fields are autonomy, mastery, accountability
You are absolutely right. If you read through the Scrum guide, you will find all those aspects in there. I think what you are describing, though, is how Scrum is "lived" in many organizations, which have difficulties empowering teams and provide the environment necessary to do Scrum.
In these situations, the answer is often that Scrum simply don't work, it's clashing with your culture and structure. Many teams opt to implement parts of Scrum - which is fine and might work exceptionally well, but it's not Scrum.
> Following the values of Scrum, respect and openness in particular, helps teams sort these things out. I know that in practice, it involves a lot of skill to guide a team through those phases.
"Respect" helps to solve conflicts in literally any kind of methodology. And healthy asertivity too. That does not make Scrum special. It still makes it harder then other methodologies. It still leads to harder and more emotional conflicts. Probably because people with no feeling of control are fighting over control
> If you read through the Scrum guide, you will find all those aspects in there.
That is not true. Scrum does not give any agency to people working in team, only to "team" as a collective entity. People working inside the team work at 2-4 hours long tasks at maximum, all the problem solving was done "by system". Individuals are not improving, except in following the process.
I would expect emergent behavior from said team (which I consider a team; not a SCRUM team; a human team working on software) to be a better representation of who they are as humans and of how they best think they should organize in order to attain the company goals.
As for the micromanagement, I would love to hear an explanation of how SCRUM is *not* micromanagement when every day, a guy (which in my decade long experience has always been either a manager-role or someone wanting to be a manager) comes and gets the report on the tasks that you work to the granularity of one hour (sometimes even 30 minutes for properly crazy SCRUM masters) and intervenes afterwards if he considers it needed.
> Aren’t these interactions put in place to create transparency across the team regarding progress and purpose as well as empirical validation?
Depends on how big you think the team is... If we're talking about a small cross-functional team, I've never had as much transparency and signal over noise over progress, purpose as well as empirical validation, than I had working with a bunch of great people (healthy mix of junior, middle and senior), going out eating every day for lunch (usually more than one hour :o) and discussing. If we're talking about the organization as a team, then yeah, clearly more transparency regarding progress for them because before this whole SCRUM thing they didn't have a load & run way of creating an analytics pipeline for their software projects.
Look, you're clearly in the SCRUM side of the stadium and I'm squarely in the emergent-process side, and it's been a discussion for aeons of which I am tired. What I am arguing is not pro / anti SCRUM, what I am arguing is that SCRUM as most enforced things "micromanage and/or ignore human psychology".
I think you are arguing Scrum can lead to these situations - which you cover in your other thoughts. And I agree, I have seen that often, however, I’d still don’t say it’s inherent to Scrum itself.
> how SCRUM is not micromanagement when every day, a guy (which in my decade long experience has always been either a manager-role or someone wanting to be a manager) comes and gets the report on the tasks that you work to the granularity of one hour (sometimes even 30 minutes for properly crazy SCRUM masters) and intervenes afterwards if he considers it needed.
Yeah that’s awful micro management. I know it’s easy to dismiss that way, but what you are describing is not Scrum, that’s just saying Scrum and making people miserable.
In the end, I do not want to argue for Scrum as the solution for everything. It’s really hard to do it right. On one of the teams I am consulting right now, we went away from Scrum because it didn’t work - fascinatingly due to different reasons as you mention, different mindset in terms of what management does and how control is exercised.
I think it's easy to dismiss because this was easy to digest in the first years and first teams, but after a decade and corporations and some smaller companies and some startups, I just don't believe it anymore.
I am actually a certified SCRUM-master (but not practicing) and sometimes google 'what is SCRUM?' just to check up on the new articles. I find a million of them each with their own interpretation that could just work and each of them seemingly valid while mostly ignoring the agile manifesto they love so much.
> On one of the teams I am consulting right now, we went away from Scrum because it didn’t work
Congratulations on actually attempting to solve the problem and not cargo-culting a magic solution.
(SCRUM-master / AGILE coach / Project Manager / Line Manager) felt like she was losing control of the development and doubled down on processes to the point where nothing moved anymore and this was her solution to it. It was amazing!
One software solution (nothing fancy, just a shit payment processor integrator), three teams, three technical leads, three team leads and one incompetent master overseeing the Kafkaesque nightmare.
Now you're making me curious if the project is still ongoing. :P
> How do people get anything done with such invasive interruptions throughout their working day?
They mostly didn't really, the biggest concern in that company was how to tweak your timesheets to match the estimations as requested by the master.
----
A lot of times when I'm hating on SCRUM I wonder if I really got unlucky, especially due to my outsourcing beginnings, but then I find it hard to understand how come I get lucky to work with great teams when there are no such barriers in place.
I'm not even against the whole process thing, used to build emergency management systems where we spent 80% of the time planning, estimating, figuring out what can go wrong, working in heavy processes. But they made sense.
Original motivation does not changes anything, we are talking about effect here. Effect is the same.
Also, transparency regarding progress and purpose does not require scrum. I dont know what you mean by "empirical validation".
I don't recall the "not knowing the progress" being issue in any methodology for developers. Maybe, most of the time we dont really need to know how fast tasks are progressing. Speed on other tasks is important for management, but not for me. I need to know their thoughts about codebase, about where to go, what they consider issues and such. But progress, not so much.
Because if it's the latter, I've found that the optimum amount of defined process in an organization is not zero. But of course it can quickly move to too much process if left unchecked.
Ideally each team needs to figure out how much or how little process works for them, and have autonomy in implementing the process they decide on.
I'm not saying there aren't benefits to scrum but the ones you are stating are poorly done if they are mostly done via scrum.
And it's great that you communicate with your team when you run into a problem. But spending a few minutes each day giving everyone on the team a quick summary of the outcome of those issues shouldn't seem like a big burden and could be helpful given that you're all working on the same project.
> If you don't remember something the next day, it's probably not important enough to report anyway.
It can be a big enough deal and still take A LOT of effort to have all the abstractions ready in my mind for that meeting.
In 12 years of having to deal with the annoying fad of agile/scrum, I've never seen it be anything other than precisely that: "a recitation of minutiae for its own sake".
But this can disrupt whatever flow state your peers are in, reducing their productivity.
The purpose of stand ups is LESS meetings and FEWER interruptions. If you're still interrupting coworkers frequently throughout the day then, sure, a stand up doesn't add much value.
That's not a good take on it, let alone all boiling down to it by any measure.
The constant status reporting of scrum is a distraction. That doesn't of course mean the engineering team shouldn't communicate both plans and results in a timeline that makes sense.
If the work is so incredibly trivial that status needs to be reported every.single.day, then it's not work I'm interested in even doing. Progress on anything creative and challenging takes a longer timeline and daily reports are a very annoying distraction.
I worked this way I like with just a kan ban board at previous jobs, and at my current one. It works, and everyone is happy. But it requires people with experience and trust at all levels, from engineers to PMs to CTOs to CEOs.
I dunno, the name sounds appropriate to me.
Problem #1 "Scrum is vague" - no indication why that's a problem. If scrum claims to be agile, it has to be somewhat vague, because it has to leave room for the retro to lead to actionable change.
Problem #2 "The Sprint" - Artificial stopping points aren't a problem. As he mentions, good devs may pick up something new, but speaking as a manager...I don't actually care. I trust the devs to figure out the best use of their time at that point; if it's starting something new, okay, and that will affect our future estimates. If it's working on non-functional stuff ("let me add some better tests around that thing that keeps breaking"), also great. If it's training/learning ("I've always wondered what the hubbub around Rust is..."), also great. And if it's taking a break ("Man, I'm mentally exhausted. I just want some time off"), also great. There is literally no outcome that isn't a positive, because we already got the stuff we wanted to get done, done, and I trust my team to actually determine what is going to be the best use of their time.
Problem #3 "The Scrum Master" - I generally agree with this. It's a role, not a position. That said, in especially messed up orgs, the position was 100% warranted, and it truly did help me manage upwards.
Problem #4 "Estimates" - Op mentions "workload -> time" as the goal of estimates. No. They aren't. Story points are chosen -specifically- to break that connection. Because the temptation, if we correlate to time, is for stakeholders to say "We need this tomorrow! You said it would be 1 point! 1 point is 1 day, I expect it tomorrow!". The temptation is also to bias our estimates; my estimate for a task that we don't need until 6 months from now is going to be quite a bit different from my estimate that you're pressuring me to deliver in two days (in fact, my definition of what the task -is- might change!). By using story points we break all of that. Estimates don't change due to time pressure (because they aren't based on time), and the team can't be held to a certain time for completing them (because they aren't based on time). Nevertheless, we get something we can use at a higher level to determine if a project is going to be late or not.
I really don't like SCRUM, but sounds like the Author got it totally wrong.
Problem #1 - Scrum Is Vague: Nope, it can be vague, you can create your own dialect from SCRUM, but you can do SCRUM by the book and it's fine
Problem #2 - The “Sprint” : The context switch is a problem, however you can build a feature or a set of features iteratively, in 2 weeks block. It is doable and normally I have to admit you move forward with more confidence because you are able to expose your work sooner to the users (i.e as a beta feature)
Problem #3 - The Scrum Master: "In addition to all of their development work, the engineers are now interrupted frequently by the scrum master who is asking when the Java code for the React app will be done.": Nope it will never happen. Scrum Master don't do follow-up on the dev team. SCRUM has well defined cerimonies to introspect the development. At least I never saw or heard of this issue.
Problem #4 - Estimates: You don't have to over-engineer it. We size cards to make sure that everyone understood the problem. If I card a card as L and the whole team sized it as S, we discuss to make sure that we are all on the same page. It helps us a lot to map all work to be done in one card
Beside that I don't think doing SCRUM you spend more money than necessary.. Normally the SCRUM master is one developer and SCRUM actually can be used to reduce the development costs. It's pretty common to have teams with 1 or 2 senior devs and the rest juniors, forcing the seniors to do coaching and micromanagement from the junior devs...
And yet they are then used for measuring "velocity."
We can track that average (and, more importantly, the average points we burn down per sprint). Doing so serves multiple purposes; we can divide the amount of remaining work by that average and know whether, to the best of our knowledge, we will hit a certain date or not. We can also use changes to that average as a reflection point on what could have caused them, and let that affect our process (i.e., the new VP started scheduling a buncha status meetings, and oh look, our velocity dropped).
But the point is at no point can that 5 point story actually get held up as being doable in 5 days, even if that's what it equates, on average, to. Because it's an average.
Whereas if I told a business stakeholder "it'll take 5 days", you can bet they'll be at my desk on day 6 going "where's my feature?"
Now I just play a video game during the ceremonies.
If you have a team that’s deeply bought into agile ideas, you don’t need Scrum.
Not in my experience. If the job req calls for experience working in an agile environment, or the HM tells you they're an agile shop or undergoing an agile transformation... they do Scrum, and they probably use JIRA; if not JIRA then something even more unfathomably horrible like VersionOne.
Nobody gives a shit about what's in the Agile Manifesto. Agile is Mornington Crescent, and the Manifesto is the game they want you to think they're playing. The game they're actually playing is a quasi-Taylorist affair about generating constant, real-time, fine-grained metrics and accountability. Agile gets adopted in corporations because, and inasmuch as, it promises those to corporate management.
Just try to find a diff in a JIRA "issue". It's crazy how many clicks that takes.
Used it for 5 years at a midsized business and had an overall positive experience with it.
It quickly becomes not fine when you have PMs, Teams Leads and whatever creator vast amounts of workflow crap, automation, a billion tags, sprints.
"What are our team processes?"
"Oh, we use Jira."
...
I suppose that's not Jira's fault, exactly, but you can see why it would have a bad rap.
The problem is when "scrum masters" start trying to apply Taylorism (the only thing they know) to software development on top of JIRA. That's when you get JIRA tickets with vague descriptions like "simplify login flow" or "reduce memory usage" and some self-important jerk insisting that you either assign a "point value" to it and finish it in two weeks or "break it down into smaller chunks that you can estimate".
I've been at a few places where it was hideously slow and flakey (erroring just after you save a long story edit).
In recent years I've mostly used it in SaaS form, or at least very well provisioned.
I don't love it, and the UI is clunky (especially the messed-up almost-but-not-quite-markdown or wysi-almost-wyg) but it's usable, widely known, and as you note has some useful integrations.
Edit: the hard part - and this has nothing to do with JIRA is getting people to write well-formed stories. I have spent a lot of my professional life fighting to deprecate contentless stories!
Like I said, there are far worse things that could be forced on a developer team -- like VersionOne, switching away from which to JIRA will seem as a breath of fresh air.
In that context, the longer something could be put off, the less stressed you would be. Scrum was (mostly) effective at setting sprint-sized deadlines to hold people accountable to.
Personally, I'd much rather have used a lighter Kanban system, but the issues caused by the time splitting culture were very real; I don't think we could have moved off of Scrum without addressing the deeper issue.
I don't think this is the point Scrum wanted to win, but there you go: it's a decent backstop against bad policies elsewhere. Unfortunately, that's a pretty mediocre bar to set.
In the end, if you want something different from the people actually coding and designing your product, hire different people who do get your idea.
Or spend a lot of time persuading people.
Either way, persuasion or searching, it looks nothing like scrum or project management.
> Let’s also say that I estimate the whole task will take ~two months if I can work consistently.
> I need to break the API into pieces that can be completed in 2-week increments. We don’t plan super far ahead in Scrum (which is good, things change rapidly) so I just need to figure out what I can get done in my next sprint.
"We don't plan super far ahead" does not mean "We don't plan two months ahead", it means, "We don't plan a year or more ahead, and we don't have a detailed plan out more than a few months, because detailed plans out that far are a waste of effort unless you've done the work 100 times before or it's the simplest problem you've ever seen." If you choose not to plan a couple months out, that's on you and your team. Don't be stupid, make reasonable plans. Then accept that the plans will undoubtedly be crushed by reality, and have to be adjusted (which is the purpose of the timeboxing, to give you a structure for reevaluation and replanning).
Of course "super far ahead" is subjective, your "super far" may be 5 minutes, someone else's may be 6 months. It's contextual, if you know your domain well, you can plan (and be confident in the plan) further out. If you don't know it as well, or you know it well enough to know that it fluctuates too much to provide certainty, you plan for shorter periods. I've worked on projects that did have accurate detailed plans for 12+ months, but they were:
1. Stupidly simple (just grossly tedious for, mostly, valid reasons).
2. Very well understood (more or less the same project had been done a few hundred times before, though with different people at different times over 20 years).
With increasing complexity and decreasing understanding, you have to restrain the desire to plan further out. But that doesn't mean "be a moron and wing it day-to-day".
Leave scrum to rugby, I like getting stuff done - https://news.ycombinator.com/item?id=23233683 - May 2020 (86 comments)
The main challenge I see people having is that Scrum was designed in a way that it screams in your face when you screw up and many organizations fight that instead of inspecting and adapting their way of working.
For example, do you remember when remote was a perk? Do you remember when countless devs wrote posts just like this one explaining why no real work can be done in yesterday’s offices? How did that go? The pandemic prove them right but no manager wanted remote devs until then. This is the same. Every good developer will find evetually the best way to write code. This is very different from what we have now, scrum, agile.
Scrum is rarely the problem in a team without nontechnical managers.
The issue is that this rarely occurs.
"Carving up the work to fit into these little, disjointed stories that can fit within a oppressively short two-week sprint is just soul crushing. Agile was supposed to be liberating us from process, but its current incarnation doubled down on its alienation. Software developers and designers aren't happy doing assembly line work. Calling that work "stories" is the great con of much modern agile process. A story without a beginning, a middle, or an end is a shitty one. It's more like just a scene, shot out of sequence."
Just my opinion, mind you, but your methodology might backfire.
And that quote pretty much describes conflict with reality that notion had.
On the contrary, I'm perfectly happy doing "assembly line work" - or rather, I'd be perfectly happy doing "assembly line work" for what I get paid as a software developer and just seeking fulfillment outside work. The problem isn't the assembly line work-ization of software development - if it were, this job would be a $10/hour unionized grind. The problem is that managers only know how to manage assembly-line work, so they insist that software development must be assembly-line-izable in spite of all the evidence that it isn't.
At least that’s what I gathered of the rugby stages of emotion when my girlfriend played.
Sprints are used to reduce risk "that the wrong thing is delivered", to make sure end to end functionality is considered as soon as possible. And yes, it may not be easy to find a vertical slice the fits in a sprint, but you can push for it.
Thus this summary is too generic...
> Scrum (noun) - 1. [software] Any good process that works good
Scrum is not a binary thing. It is a method that guides a team to produce tangible increments of the product quickly to inform the further development. I.e the idea is that you can and must pivot a lot during development of multi month effort.
So if you are 100% sure about the requirements, waterfall development/ frozen requirements, is the most efficient way to produce a thing, zero meetings needed, no adaptions needed.
The only problem is that most software development environment do not provide a high enough certainty, and that in the end big course corrections are needed when the outcome is finally produced/testing or integrated.
Scrum opts for smaller corrections spread through out the development, yes there is overhead. It is a trade-off.
And like everything else Scrum/Agile can be misused, misinterpreted by "management" and "engineers", however, that doesn't mean the idea of "Scrum/Agile" is "bad".
The goal of Scrum/Agile is "getting stuff done" namely the right stuff. If it does not work for you/your team, no problem, but i think it is helpful to differentiate between the idea/ideal and the implementation in your context.
I have seen Scrum fail miserable in some teams, and it some it was the best thing ever.
> I’m incentivized to stop.
I have never been in a scrum team, that was incentivized to stop.... because when we were done early... we would just pull items from future sprints a head. However, this can be tricky if other items in the sprint are not yet done. So that the team should help each other to get the other open tickets done. This is a trade off: Scrum deals with a team, that delivers software as a team. (which can have drawbacks).
> The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. > Let’s just talk about the worst possible scenario where the scrum master is a non-technical, non-product people manager.
soo how do you get from the above statement to:
> In addition to all of their development work, the engineers are now interrupted frequently by the scrum master who is asking when the Java code for the React app will be done.
That is a total misinterpretation of the scrum master and is the contrary what a scrum master should do. The statement didn't say the Scrum master should perform "interactions" on behalf of someone...
> Scrum Master isn’t a full-time job. Who said it should be a full-time job ? Some scrum masters can guide two/three teams, or do fulfill other roles in the company.
Finally at the end of the article the author links to a follow up "Scrum vs Kanban". https://qvault.io/jobs/kanban-vs-scrum/
Just one thought on this row in the cited table:
Release methodology Scrum: At the end of each sprint Kanban: Continuous delivery
In almost all scrum teams, where I have been, we had multiple releases per sprint, the most mature team I have been on, had "deploy to production" as part of the DoD of a ticket.
Scrum is all about breaking down large, complex projects so they can be delivered incrementally, then delivering those increments. Then you incorporate feedback from your stakeholders, including new requirements or work. Then you reflect on how it went and adjust your process. Then you do it again.
I have seen Scrum suck too, but mostly because the org left out or ignored some huge part of what makes it work. But the framework itself makes a lot of sense, and I haven't seen another that works better.