Scrum seems to be the go-to Agile methodology. It sometimes is quite effective, depending on the project; However, it is not obvious to me that it is worth being the de facto standard for software engineering. I'm curious on everyone's thoughts and experiences with Scrum at your workplace. Here are a few of my thoughts: 1) The daily stand-up makes almost no sense to me when you work with independent, motivated engineers. It is a ritual that exists as a status report, with the occasional unblocking going on; However, in a team where software engineers are largely independent, it is rare that one would need to wait until an official meeting to unblock themselves. Throughout the day, if one were to be blocked on an issue, they would unblock themselves more organically, through chat messages, posts, emails, or just having a *gasp* conversation if we were in-person. 2) Task creation, estimation, and backlog grooming is a high effort / low value process. You have to make these tasks that are conceptually small enough to fit within a sprint. If you are being dogmatic, you will then write a lot of things about acceptance criteria, test cases, usage, user stories, elaboration, etc. Then you will go through and take tasks and commit to them for the duration of the sprint with your team after estimating the relative effort for each task. This seems like a lot of up-front effort, when you could be much more lean. The epic-level task is all that is really needed, the high-level goal that one would like to achieve. The sub-tasks become implementation details at that point, and not something that needs an entire team to estimate, or really be aware of at all. My ideal process, and what we do on my current team, is essentially: "I want to unlock X functionality" -> put up some design doc for comments -> start implementing and iterating. If X is not large, or if the path is quite clear, skip the doc. You move quicker, you aren't having meetings for meetings sake, you're delivering value. 3) Scrum Master is the 2021 snakeoil salesman, and the fact that it is a title is just proof that people are more obsessed with the optics of appearing agile than actually being agile. 4) In a team with continuous deployment, continuous integration, and a rapid approach to engineering, the entire concept of a recurring 'sprint' does not make much sense to me. If you were to cut some release, or actually loop customers in for a demo like Scrum mentions it would be more reasonable; But every place I have done Scrum we just essentially divy work up into 2 week sprints cause Scrum says. CI / CD + feature flags lets you constantly iterate, aggressively get customer feedback ( not just at the end of a sprint ), and move more quickly because moving back is as simple as flipping a switch. 5) Different engineers work differently. Forcing everyone to some Kanban / Jira / tracking tool is imposing upon the engineer a workflow that may have neutral or even negative value add. People on my team may aggressively use TODOs, sticky notes, trello, full-spec'ed tasks, or whatever combination they want. If an engineer is not empowered by the process, they are losing cycles to allow someone else to come in and make nonsense artifacts like burn down charts, gantt charts, etc. 6) Last one is that the entire methodology seems to cater to dependent software engineers while independent engineers are slowed down. There are a lot of patterns here. Independent engineers are able to unblock themselves as soon as an issue pops up, yet Scrum prescribes a daily meeting to talk about blockers in-case other SWEs are not empowered enough to bring up concerns, issues, etc. Independent engineers are able to communicate issues to their team about process, testing, etc. yet Scrum prescribes a sprint retrospective for everyone to have time to say what's on their mind. Independent engineers are able to break down high-level goals into sub-tasks and eventually into their implementation, yet Scrum has ceremony around this to make it a team effort to groom a backlog and make tasks bite-sized. This makes productivity more consistent ( over X weeks team Y will typically have Z output ), but lowers it to the lowest common denominator instead of allowing developers to have more peaks, the ability to rapidly introduce business impact / value. Caveat: my career has been in infrastructure. This obviously shapes my view of the methodology, but the concerning part is I see it so unproductive yet it is still the go-to standard for many teams whether it works or not and the downsides are potentially large. Curious what everyone else feels about it, if you do use it what makes it valuable for your team and use-case ( customer facing, contractor / consulting, heavy collaboration with many moving parts, etc.? )! Oh and at FB my team does not do Scrum, at my past four places we did. #engineering #software #swe #agile
Did you really type this essay on mobile?
I typed this essay on my keyboard, hoping to get into the young adult writers of america club
Sorry but the spaces inside the brackets is a big turn off.
fuck daily stand ups. i just play video games during them
I HATE scrum
I hate daily stand ups!
I agree with the majority of your points. I recently re-read Robert Martin's "Clean agile". Seemed like a cargo-cult to me, which might sound good on paper, but doesn't seem to work in reality. I blamed Amazon managers for it a bit, since they like to use stand ups and planning as a room for micromanaging. Do you have it different in Facebook? Are teams free to choose their own methodologies or lack of one?
Yeah we are much more lightweight, I believe it's up to the team and my team has results so it works out. I track my work how I would like, share a task if someone wants to stay updated, but there's no general pool of work to see what everyone is doing. We do 2 'standups' a week but they're more just for remote / say hello to each other since WFH is isolating - in office we don't have them. We have projects we pick and commit to at the beginning of the half, and from there you work with partners / stakeholders to define priorities and execute on the project. in terms of process time per week, I probably spend < 45 minutes across those two 'standups', tracking my work in tasks, and other nonsense. I really only use tasks since it's so easy come psc time to just link an overarching task for what you delivered.
Sounds great to me compare to my current experience. Maybe, I should try to interview with Facebook again some time in future ;)
Does anyone know if TPMs have to be Agile/Scrum proponents? Cause I’d imagine if one project is agile and the other isn’t in a program it’ll be harder to manage.
Working Parents
Yesterday
578
What do you think is wrong with a kid who got rejected by 9 colleges?
Tech Industry
Yesterday
2098
Quitting this Slave life
Tech Industry
Yesterday
1680
The end of Backdoor Roth?!
India
Yesterday
753
Who are these retards asking for dictatorship in India?
Tech Industry
Yesterday
395
One time annual stock vesting is a scam
Is this a Facebook recruiter tactic?
Perhaps?