"I like doing stuff without coordination with my fellow co-workers or towards to goal of my program/business."
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."
Well said. Afaik, people aren't getting compensated by LOC * $X. Sometimes the value to the team/product/company is higher by going to pointless meetings than it is by being a code monkey in your basement. No process is perfect but I can't even count the number of man years of wasted and unreleased code because there was no coordination.
I would argue that pointless is a key modifier here.
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.
> think their job is just lines of code vs accomplishing the business goals
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.
Nobody cares what the agile manifesto says. The only way I have ever seen scrum manifest is as a daily meeting where everyone on the team reports their incremental daily progress to the manager. Of course, no developer actually makes uniform incremental daily progress so this really just turns into a demoralizing exercise in lying about what you did the previous day, punctuated by underselling the days where you actually got quite a bit done. Then you tune out as everyone else goes in their turn giving updates on something that doesn't affect what you're doing in any way whatsoever.
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.
See how many days in a row you can say "I didn't make progress yesterday" to your manager before it becomes an issue. Myself and all the best developers I know have days or weeks of doing very little punctuated by days or weeks of doing quite a lot. Of course, I don't lie to my comrades - as intimated by the quip about weeks where the manager leaves, we were very truthful with one another if we actually bothered having a daily scrum.
Go ahead and posture online about how you would never overstate your accomplishments to your manager I guess.
As a manager or co-worker, if you reported "no progress" a few days in a row, I'd ask why not. I would honestly be looking for ways to help you make progress because getting stuck in a rut sucks (and we've all been there).
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.
And such help would not be useful, because these are problems of motivation. So to avoid such unhelpful help (which can often exacerbate issues - such are the mysteries of the self) I tell you everything is fine. Tally up my work at the end of the month and you'll be happy.
Another angle is that in software development, it's pretty common to have days where there isn't much material progress but things are getting better understood by the developer themselves. Senior engineers in my experience are quite comfortable doing several days or even weeks of scoping, investigating, prototyping, and general maneuvering before coming to a solution that ends up taking a day or less.
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".
But scoping, investigating, prototyping, etc are all forms of progress. Tell me that's what you're doing.
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).
> As a manager or co-worker, if you reported "no progress" a few days in a row, I'd ask why not.
"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.
I suppose it all depends on how you measure "progress"? If I run a stand up meeting and you tell me that you found out that the problem you're working on is more complex than it looked, and that you didn't write a line of code yet while still exploring it, I will still consider that progress.
No, absolutely not. Many people, myself included, can’t just be firing on all cylinders all the time. The downtime is necessary for the uptime. “Help” of this type from coworkers (or rather managers, let’s be real) only drives home the idiotic message that anything other than uniform incremental daily progress is an aberration that must be corrected.
If you only report your work as progress/no progress, then some days will look like nothing is happening but that’s not true. You might want to expands a little more on what you were actually doing rather than brush off the question with a “no progress” umbrella.
> The only way I have ever seen scrum manifest is as a daily meeting where everyone on the team reports their incremental daily progress to the manager.
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.
>The only way I have ever seen scrum manifest is as a daily meeting where everyone on the team reports their incremental daily progress to the manager.
Then you've never seen scrum, regardless of what your manager told you.
The real question is, does the Agile Manifesto accurately predict or reflect reality?
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.
You can coordinate and report without heavy duty micromanaging process like scrum. And you can achieve much better relationships between people then scrum generates too.
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.
Micromanagement - there is literally ability to make own decisions. You have to accountability either. Every single tiny aspect of work is dictated by somebody else, commitee or some kind of process.
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.
> Every single tiny aspect of work is dictated by somebody else, commitee or some kind of process.
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.
They might not meant it, but that is what it creates. It does not create empowered workers. It does not even talk about people or individuals, it is always team. But "the team" does not make decisions, individuals do. There are emergent decisions, coming out of the system, but no empowerment to anyone (maybe except PO).
> 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.
It establishes a set of steps that need to be followed (often time daily) and interactions to be had regardless of the nature of the work and the psychology of evolving unique set of relationships inside a social group? How does it not?
Aren’t these interactions put in place to create transparency across the team regarding progress and purpose as well as empirical validation? I am not sure how that necessarily clashes with social structures inside the Scrum Team or micro manages its members.
> I am not sure how that necessarily clashes with social structures inside the Scrum Team or micro manages its members.
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".
> 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 know it’s easy to dismiss that way, but what you are describing is not SCRUM
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.
Status updates every hour or half hour sound like a productivity hellscape. How do people get anything done with such invasive interruptions throughout their working day? You can't even enter a flow state with those sorts of requirements.
> Status updates every hour or half hour sound like a productivity hellscape
(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.
Transparency is provided by a Jira board - and the board is always up to date. Purpose and blockers are better discussed 1:1 or in small groups with whoever is in charge of dealing with the stakeholders.
> Aren’t these interactions put in place to create transparency across the team regarding progress and purpose as well as empirical validation?
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.
“But that just means your org isn’t really implementing Scrum properly! Here read this few hundred articles about how your Scrum isn’t really Scrum, but sCrum”
Do you dislike Scrum because of the specifics of Scrum, or do you dislike defined process altogether?
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 don't know about you but I can and do jump on a call with the product managers and my peers the second I run into any issues when it's fresh in my mind; I don't do well at remembering the problem the next morning, an hour after I just woke up.
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.
If you don't remember something the next day, it's probably not important enough to report anyway. Scrum isn't a recitation of minutiae for its own sake, it's a quick summary of progress and blockers. I would hope you could remember what you did or didn't finish yesterday, and whether you're blocked.
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.
It's not a big burden to update people, I've just seen the process abused so much that it becomes a colossal waste of time. Why can't I just post an asynchronous update to some group page at the end of the day?
> 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.
You definitely don't need to have "all the abstractions" ready in your mind. All you should be doing in scrum is summarizing the current status and what you need from the team. Standup isn't for solving your issue, or even describing it in detail. If the process is being abused, stop abusing it and let your teammates know when they're drilling down too much. If your standups are bad, it's because you and your peers are letting them be bad.
> Scrum isn't a recitation of minutiae for its own sake
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".
Even your own contribution? Scrum is a team thing---if your scrums are terrible, its because you and your teammates like them that way for some reason. You have no one to blame but yourself if you let it go on for 12 years.
It is an insane burden that wastes everyone's times. Communicate immediately don't wait until the next day. It is an anti-pattern, you end up structuring your work around status updates instead of the real problem.
Scrum is a floor on communication, not a ceiling. There's nothing in scrum that says the team can't meet outside of the daily standup. The standup just ensures that everyone has a chance to hear what's going on with others on the project. If you're "structuring your work around standups", that's on you. I've done scrum for over 15 years and I've never felt the need to do that.
> I don't know about you but I can and do jump on a call with the product managers and my peers the second I run into any issues when it's fresh in my mind;
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.
I tell everyone to not wait, ask as soon as they need something, just hit the squad channel on slack, etc. If people all did this perfectly, we would end the standup in 30 seconds everyday (we don't bother with the recitation part, just if anyone is blocked or needs anything). And yet, people often need help and haven't asked yet. I think it lowers the barrier for some people.
Idk, I think we waste a lot by doing tickets and meetings for every little thing that has to change. More so for front-end changes than backend changes though.
I think tickets are more important for auditing purposes, being able to establish what was deployed when and for what purpose. But yes having too many tickets just creates more over head.
> It ultimately boils down to "I don't want to report on what I am doing or how I plan on doing it."
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.
Nah. I like being told what the mid/long term end result should look like and let me figure out the details and find the best way to that to me and my other engineering team mates. I like to be judged by what we achieved last month, last three months, last 6 months and last year. Not by what I reported in the "daily" what did yesterday because otherwise everyone thinks I've been slacking instead of moving mi Jira tickets.
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.
Scrum stifles innovation. Whenever someone tries to introduce scrum to my team I just link them to DHH's thoughts on the matter, he sums it up far better than I could hope to: https://nitter.net/dhh/status/1196856292683350016.
"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."
A link to DHH seems like an appeal to a pretty faulty authority who has a closet full of strawmen. Honestly, a link like that makes me take scrum more seriously.
Just my opinion, mind you, but your methodology might backfire.
Despite him not saying "Scrum", the structure he's describing is not Scrum anyway. It might be close to what some people understand when they say "Scrum", but it is not Scrum.
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.
Having played a lot of rugby in my youth, I remember that scrums basically involved having one's head and ears rubbed very harshly by someone else's sweaty scalp while severe pressure was exerted on your neck and back. During all this, the steaming mass of teenage boys never really moved anywhere and very often ended in a collapse in the mud. I have never really understood why the name Scrum was chosen or whether the people who named it have ever been in one!
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.
I still don't understand why people hate JIRA so much. It's not great but it's not nearly as awful as people seem to make it out to be. I found the Github integration was really sharp as well.
I guess you're not a developer. JIRA is incredibly convoluted and backwards from a development perspective, because it was built for a different audience (product? sales? I'm not sure).
Just try to find a diff in a JIRA "issue". It's crazy how many clicks that takes.
Perhaps it's down to how JIRA is configured. At $JOB, if you mention the JIRA ticket in a commit message, a link will show up in the ticket to show the commit (it may take some time to show up, but it does eventually). Also, there's an obvious link on the ticket to see all activity.
25 years of professional developer experience here. I think JIRA works just fine. Is it perfect? Of course not. Nothing is. Is it better than most other imperfect alternatives? Yeah pretty much. Is the cost of switching to something else that also isn’t perfect worth it? Probably not.
For the teams I've been on, Jira is less in support of team processes and more an excuse for their nonexistence. The following exchange is only slightly doctored:
"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.
JIRA as a generic issue tracking system is fine - and to the extent that it's used as a generic issue tracking system in cases where you actually need a generic issue tracking system, it's acceptable (bugzilla was just fine, too, though). It is very useful, when somebody identifies and reports an issue, to have an "issue #" to associate with it so that if somebody wants to know whatever happened to issue #34, they can just go take a look and see that it was never assigned to anybody, or it's already been fixed, etc.
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 think on-prem JIRA (often with some additional DB customisation work) is probably the reason.
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!
Well, JIRA isn't terrible. It does its job reasonably well, but it really shows that it's a project management tool that developers happen to be forced to use, and it's the standard "agile" tool. Its use is a red flag that maybe the org hasn't put much thought into encouraging developers to work efficiently and cultivating Csikszentmihalyian "flow". A typical corporate JIRA workflow is an example of what I call switch-cutting: making the production of metrics that will be used by management to crack the whip later, the responsibility of the line workers (akin to the old-timey practice of making a child cut the switch with which they will be beaten). But Scrum itself has this problem as well, and JIRA is just a tool to that end.
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.
The author does not suggest how to get stuff done, for that reason I think the title is clickbait. The issues the author has with Scrum are relatable, on top of that there is also rituals, someone recently switch teams and they were happy that we had 1 ritual and on average ~2h of meetings a week, compared to 8h of meetings a week on the other team: planning, retro, daily stand up, pre-planning, grooming, scoping, etc.
If you read to the end the author links to their second article suggesting Kanban instead. I concur with this suggestion in general. This talk is an entertaining classic intro into it: https://youtu.be/CKWvmiY7f_g
Scrum was effective at my old workplace, but maybe for a bad reason. Almost every software engineer had a time split between at least two teams, usually 50-50 but sometimes imbalanced or split further. Since teams tended to ask as much of you as they could -- much like the proverbial professor who doesn't particularly care that you have other classes, theirs is the important one -- engineers were incentivized to stay shallow and get stuff done quickly rather than well.
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 general I'm openly against Scrum. Whenever I join a team doing Scrum I can immediately notice how the artificial concepts stiffle innovation and productivity. The "sprint" made sense when we used to release software every 2 weeks, not every 2 hours. The "scrum master" is a glorified meeting facilitator, and I've never seen anyone doing both sprint review and retrospective every 2 weeks.
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.
I agree that scrum is dumb but abstract size estimates are dumb too for the same reason. All that matters is time, and if time is variable per person then… record the time it would take per person. I have never worked in a team where sizing ever worked, because junior says large, senior says small, the facilitator settles on medium… and then the junior ends up doing it and takes twice as long as expected.
Your anology assumes everyone knows where the building is, that they know how to run etc etc
If measuring as a team, then it evens out. Unless you have a specialist that would be better placed on other tasks, and a generalist taking that specialist's tasks, that junior engineer is going to take longer than the senior engineer that has been on the team for a while. So, if you are measuring the team's capacity, it usually doesn't matter what task the junior engineer does - it's going to take longer and require assistance from the senior engineer.
If you measure on size of task with modifiers for tasks novel to the entire team, the differences will usually average out.
I’d love to believe that but I’ve never seen it in practice. The misses always outweigh the hits and it creates a frustrating team dynamic. You end up with seniors steam-rolling through estimates (hah! I did a large in a day! Applaud me!) and juniors stuck on a small for a week.
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.
This is why it can be better to just -prioritize- without -estimating-. Make sure you clearly and strategically prioritize the work to do, and plan for continuous delivery, or release milestones. Assume that your engineers will work just as fast as if they made inaccurate estimates (keep in mind overestimates might result in engineers slacking off to fill the over estimated time). You can always look at the work that engineers deliver, see how long it took them, and senior engineers will be able to tell if that engineer spent a reasonable amount of time for that task. You could call this post-estimates vs traditional pre-estimates. So tl;dr: just do good prioritizing and do post-estimates to gauge whether people are slacking off
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.
Will have to read more about Taylorism, thanks for putting this on my radar.
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
My problem with abstract estimates are as a product manager my dev team cannot seem to provide me a time measurement that will allow me to accurately bill my customers for custom feature requests to recoup development costs and hopefully make a little extra. So abstract estimates might be good for determine sprint velocities…and may be great for carving up releases, but they suck when you are doing custom modifications you need to accurately quote before the work begins.
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.
> * 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.
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.
Hehe, as part of an onsite test I did back when I was doing Devs recruiting was to ask them to estimate how much would it take for them to finish the remaining part of the test (a 10 point programming challenge where they would usually finish 5 or 6 of the points; and each point was to implement certain aspect).
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.
In my experience we take these estimations and have a conversation or set up a pair.
"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?"
How will the junior estimate the complexity of something he does not understand? Either too short or too long. So the difference is not that big between points and time.
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.
> 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.
So what is the point then? We can abstract away distance. It doesn't help you cross that distance.
I don't know if the author is being sarcastic but:
> 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.
In practice it doesn't matter. Because t-shirts/Fibonacci just become a proxy for time anyway. Any abstract estimate you can dream up will become a measurement of time when it passes through management.
I like the distance metaphor, I hadn't read that one before! We estimate stories before any particular developer picks them up, so it's especially important to estimate complexity and not time.
All this scrum bullshit is so fucked up. I've left a company just after a couple months because of 1) A terrible product manager and 2) A blindly by-the-book scrum process which led the project to a terrible state, worsening every day.
Rugby feels angry and aggressive about the situation, but in a joyful sort of way. Rugby throws its body at the situation while shouting. Then afterwards it shotguns a beer out of a boot and screams while beats its chest.
At least that’s what I gathered of the rugby stages of emotion when my girlfriend played.
sigh I mean, I'm not a huge fan of how Scrum gets done (yeah yeah, True Scotsman) and all that, but I have so many issues with this.
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.
Interesting. I think the author got it wrong but by totally different reasons, LOL.
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...
They're not different by exclusion. I largely agree with a lot of what you say there. Your reasons just aren't the most glaring issues from my perspective (which isn't a judgement call, just a different perspective).
Yep. Because, in aggregate, they will average out to something. A 5 point story may on average take 5 days. Some 5 point stories will take 2 days. Some will take 10. As our team's collective estimation changes, as the team comp changes, as the product changes, that 5 point story average might start taking 4 days, it might start taking 6 days.
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?"
Whenever I come across teams with situations outlined as in this article and I talk to the people involved, it becomes apparent that Scrum was implemented for the sake of implementing Scrum without understanding. The values and the concept of empiricism are important to grasp in order to effectively leverage Scrum - that is why you have a Scrum Master, not as a manager of any kind, but as a coach and facilitator.
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.
Yes people who can get things done are great and useful. If what they get done is what you want. If what they want to get done is not what you want, that's when we invent project management in order to have them report that what they are doing is what you want. This is different to peer review. Project management slows everything down. Peer review expands to keep pace, but only if both people now want to do what you want.
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.
The article is great and right however it misses the point. The point is that the non-tehnical managers have the power and developers will be forced to work in whatever conditions the managers decided.
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.
> Sprints are useful like achievements in video games are useful; they make us feel warm and fuzzy inside. Motivation is a powerful tool, don’t misunderstand me. The problem is that those warm fuzzies are mostly for the sake of the management team. It makes leaders feel in control and informed. They know exactly what was done and when it was completed.
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.
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.
This describes a lot of terrible practices, but they aren't Scrum. Scrum is what's defined in the scrum guide. If you do something else and call it scrum, it's not scrum's fault.
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.
The concepts you listed are pretty uncontroversial. However, the more specific things the article and other commenters here are complaining about (fixed length sprints, daily scrums, etc) are definitely in the Scrum Guide.
I hate the term "Sprint" (it implies the effort is about speed and not responsiveness, which is a more accurate understanding of the timeboxed structure). But this is just stupid:
> 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".
A team of good developers will do good work using any process. A team of bad developers will do bad work no matter the process used. Which is why every year a new process or interpretation of a process is invented to this time finally solve the problem that can’t be solved using a process. Stop fiddling with the process. Instead figure out how you can attract good developers.
I've solved all these problems for myself already: I won't join any company/team were scrum is mentioned in the interviews when you ask how do they work/organize. I'm just not compatible with so much bullshit.
130 comments
[ 3.8 ms ] story [ 114 ms ] threadI 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?
https://www.halfarsedagilemanifesto.org/
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.
"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.
I dunno, the name sounds appropriate to me.
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.
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.
If you have a team that’s deeply bought into agile ideas, you don’t need Scrum.
At least that’s what I gathered of the rugby stages of emotion when my girlfriend played.
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?"
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.
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.
Now I just play a video game during the ceremonies.
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.
Leave scrum to rugby, I like getting stuff done - https://news.ycombinator.com/item?id=23233683 - May 2020 (86 comments)
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.
> 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".