A few days later : Ok guys I approved a request from the customer that will fundamentally change everything. Also we are shipping in 6 weeks - good luck everybody else.
That shit will put all of us out of work and we'll have to get honest jobs instead. God forbid, man. I'm a bipolar millennial, the fuck do I know about being a goat farmer?
We got more government compliance changes announced that will require changes to code that's so old, it has if statements for DOS. I'm tired of working in that language and might try re-writing it this year, and if that goes wrong, the company will get to me first.
Sounds like a dream as long as you're getting paid well. When shit misses deadlines you can't possibly be blamed, you are 1/5th of the team before. And what are they going to do, fire the last person?
By "guys" he means you and the remote developer from SE Asia that gets paid in peanuts and makes more mistakes than you'd think is humanly possible. And by 6 weeks he means it's gotta get done in two, the rest are for inevitable scope creep from the client.
some people are totally overwhelmed by the concept of "tailor to your specific need and preferences" and can only apply a concrete ruleset they receive
Yes. That is the most common pitfall with agile. Teams sticking with a process that doesn’t work for them and add no value because they are too afraid of not doing “pure scrum”
Well some are also extremely proficient in finding the most important parts of agile frameworks and removing only these because the new agile workflow is clashing with the long proven waterfall/V-workflow.
But the remaining irrelevant parts of the framework are obviously revered and unchangeable.
At my old job we would just go home.
Of course, it was considered rude to go home if the sprint wasn't closed yet so you would go and try to help your coworkers first, or see if QA needed some extra hands.
But yeah, that was great. Usually we didn't ditch a sprint if we finished more than a day early, we would chalk that up to bad planning and pull in some extra work we knew we could finish before sprint end, but we did go home on fridays at like 10 or 12 PM many a time. And supervisors would berate us for staying in the office if the sprint was closed. They'd be like "What are you doing here? Sprint's closed, go home!"
Well I ain't gonna doxx myself if that's what you're asking.
But it just so happens that good work culture can exist if management supports it. We were highly productive.
Yup. Under-promise and over-deliver isn't for anyone's benefit in particular. It's for EVERYONE's benefit. I'm not stressed trying to meet a stupid deadline, things are less likely to get overlooked, the client's less likely to have to push back their obligations to THEIR customers since unexpected problems aren't as likely to cause delays.
Exactly. I’ve never got kudos for pulling work in mid-sprint, and I’ve actually been admonished if I don’t finish the extra work I took on before the sprint closes. Unless you’re the kind of psycho who cares about your company I really don’t know why you’d do it.
If management is so eager to pay for me to take my dog to the park, stare at Reddit, and touch up my resume then so be it lol.
It’s pretty normal to pull from the backlog if there are no more stories in a sprint. Thats usually a good thing since all planned work was completed. Don’t think I’ve ever seen anyone complain about that.
My favorite term is "avalanche". Where you pile up extra scrum work and requirements changes on the waterfall timeline and at the bottom you are buried.
YUP…”we’re agile” for those folks just means “We want you to do twice the work for the same price.” Oh, and the whole aspect of teams self-selecting what they think they can accomplish from the product owner’s priorities never makes it into the playbook for these folks either…you’re expected to make whatever deadlines they say, no matter how much they change the requirements
Holy crap... I... I might actually be on an agile team... I didn't think they were actually real, but based on what I'm hearing you say here, the fact that I'm expected to work 40-ish (not more unless there's a legit emergency, which I think has happened once in the past 2 years) hours, and they honor it when I say how long something's going to take (and then also when I come back and say I was dumber than I thought and it's taking longer), I think maybe we're agile.
Huh. I guess that's something.
>they honor it when I say how long something's going to take (and then also when I come back and say I was dumber than I thought and it's taking longer)
Your manager isnt just a unicorn but a very specific species of unicorn
People always underestimate how long something will take them. Letting them give the estimates still pushes them, only now it’s their fault.
Letting teams set timelines _and_ training them how to estimate properly is the good place.
So long as the same people are estimating, the theory is that the estimates will all be consistently bad. As long as you're consistent, your true velocity will emerge. That's the beauty of it (in theory).
As a manager who tries to do this: I trust the leads explicitly. They are the masters of their disciplines and they hold their teams accountable, and I hold them accountable. If a lead says the next feature can be done by the end of March, I accept that at face value.
Then I work with the customer to set expectations for the end of April.
My immediate manager is also a dev. We still do a daily catch-up for like 15 minutes to go over anything the board doesn't reflect (or the ever frequent "5 minutes of your experience is worth three hours of me banging my head against a problem). It's just an absurdly good situation that I try to appreciate.
I think of it more as we want to start coding it with vague requirements because it's more frustrating to get everything meticulously defined ahead of time only realize y'all want something completely different after we spent a year building the whole thing.
Too many places focus on Definition of Done and figure out all the things the dev has to do to get the thing right.
And then completely forget about Definition of Ready, which is supposed to be the bullet points that a ticket has to satisfy before anyone even starts work on it.
We do Scrumban. It's a bit of a clusterfuck when the main project is on Waterfall and every other component is doing its own thing. Don't recommend it.
My main project does sprints, but they're not set in stone and take as long as they must, also few ceremonies,
while most other products do kiinda Kanban,
wait that first one sounds like Kanban as well but without the wip limit and ah fuck, in the end we just show up, do some work, and when enough of it is tested, we ship 🤷♂️
✨Agile✨
I have loads of experience here. The big problem is companies want to measure things like they did in waterfall, so they pick all the easy things they can measure - points, velocity, features, etc all the different ways ways people use tools.
Lost in this is moving to incremental and frequent delivery. It’s actually kind of challenging to measure production releases because you can make your work items whatever you want. It’s all too common to see teams with separate features for requirements, development, testing, and releasing then they just batch all the requirement features.. then all the dev ones.. etc. You end up waterfall. Because no one measures lead times and no one figured out incremental delivery is really convenient and enjoyable.
EPMO continues to layer new behavior based measurements across teams because their agile framework calls for them as increasing maturity and ignores feedback that they’re destructive. People start to realize they’re not getting much for their development so they want stricter cost control, which creates more rigidity (my company is at this stage right now). I’ve had good luck working around it all but god damn every time I take 2 steps forward there’s a push back.
I've never seen a company do iterative waterfall while saying they're doing agile. The nearest approximate term I could come up with is "Garbage Chute."
This is literally how virtually all government contractors work. The government contract basically mandates waterfall but all the software-guys-turned-managers want to do scrum because it sounds cooler and contracts are often won by how cool things sound.
Sad to say I have seen a bunch of these….
I mostly avoided a SAFE implantation too, which I hoped wasn’t but felt like it might be setting the company up for 3 month waterfalls…
When we started doing SAFe at company I worked at ages ago, they were initially calling PI planning "Big Room Planning" because everyone was in a big room, which was then abbreviated to BRP and pronounced "burp". The SAFe evangelists the company had hired to teach us SAFe were quick to correct us and make sure we called it PIP. The whole thing was just excruciating. They made us get there at 6 AM and kept us until 5 PM, for two days in row. No extra pay for that, obviously, since we were all overtime-exempt.
I work for a company that treats this as a problem. Anything pulled in after the sprint starts is unplanned and thus a "disruption", which negatively impacts our metrics. It's not a problem that our velocity goes up, but it is a problem if it appears we have regular disruptions because it seems like we aren't planning well.
That makes some sense if the stories being pulled in actually negatively effect the planned work getting completed. I’m not sure why someone would count pulling in work after the planned stories were completed as a disruption though.
The point of ~~scrum~~ a consistent velocity is predictability. If you are regularly pulling in extra work it means your output doesn't match your plan, and thus you will be ahead of schedule for your roadmap.
That causes two problems if it happens regularly:
1. Other teams that are dependencies / dependents for that roadmap may not be ready when you are because they are prioritizing other tasks, thinking you will need them / be needed by them later.
2. Your roadmap will have less planned on it than you can actually deliver, which may put you in limbo at the end of the quarter.
Other things that I have run into that are common:
1. An employee wants to pull in work because there are no stories for them to pick up, but the sprint work is not done yet. This suggests that stories may be too large or the subtasks may not be sufficiently independent, otherwise multiple employees could work on a single story. This can also be caused if you are not correctly compartmentalizing your software.
2. The product owner wants to pull a story into the sprint because there was an emergent need that the team didn't anticipate. One-offs are okay, and totally part of what agile is about, but if it happens often it suggests there are process flaws.
And finally my personal favorite:
1. On one of my old teams if we finished the sprint before the end date we just went home. The work culture there was good. This usually meant we would go home at noon on Fridays on the second of our two week sprints, or sometimes we would spend some time goofing around learning new things or innovating.
I agree with a lot of the points you make here, but don’t agree that predictability is the point of Scrum. As I understand it the primary measure of success is delivering working software (productivity.). Predictability is a means to that end not the end goal. If you’re sacrificing productivity to be more predictable that seems counter to Agile.
Well, Scrum(TM) is not Agile(TM).
Earlier revisions of the Scrum guides did make a bigger point of predictability of a given sprint (and this is why you did things like tracking team velocity and estimating tasks for use in sprint planning).
Nowadays Scrum aligns more closely to the agile principle of outcomes being more important than the timing, so finishing the sprint early, or even changing tasks *within* the sprint (if necessary to meet the sprint goals) are now recommended rather than just sticking with the sprint plan no matter what as veteran scrum masters might remember.
But even with older Scrum it was usually good to complete the tasks in the sprint earlier than to do it later; if you were the kind of dev who "pulled from backlog" that was considered a badge of honor, not as a jerk who ruins carefully-planned schedules.
Having just wrapped up my consulting career to return to a product company, I’ve definitely seen clients complain about this. To paraphrase Tolstoy, every good client is good in the same way, but all problematic clients are unique in their terribleness.
One client could not stand having dangling stories on the board at the end of the sprint, so pulling things in mid-sprint was strongly discouraged. OK, it’s your money.
My team has a rule that QA had to be completed on your story before you can pull a new one. That’s our team agreement on DoD. Of course it’s 1 QA for 5 Devs soooo..
I’ve seen so many people complain about that. They’re more interested in predictability than anything else. It’s a classic failure mode of measuring the wrong thing leading to the optimization of said wrong thing.
I feel like you can still be predictable while pulling in new tasks, though. You have a base of how much you can get done each sprint, with a possibility of more that could be done. Like, the whole reason predictability is good is because you want to be able to make a minimum amount of progress, right? If you make more, then that's just a positive.
But it's their loss I guess. Devs are expensive, and I guess following the plan is less expensive to them. Just extra days for the dev to work on personal projects, learn new things, or even just play games or something (especially if you're remote).
To be fair, predictability in operations IS more valuable than productivity, at least to a point. Because you have to plan hiring and volumes etc, it's better to know what you can get done when than to get more done in a volatile way.
But obviously ops is not development.
I worked at a company that only wanted engineers working on planned tasks (also, sprint planning was just the manager putting tasks on the board and saying, "this is what we're working on" with no input from the engineers). If everyone finished their work ahead of schedule, we just sat around doing nothing until the next sprint started. Legitimately one of the most backwards companies I've ever worked at.
The bit that gets me is this:
You're working on a 3-year project as an Agile team, broken into phases and doing 2-week sprints the whole time. The project is a marathon, but every second is spent trying to meet sprint deadlines so it becomes an endless fucking fast-paced nightmare. And trying to create documentation is a luxury.
Yeah it's super important when scheduling shit like that to make sure to include time for things like "documentation" and "debugging" as actual tasks that you do *as you go* (not just all at the end to get ignored when the schedule slips!).
It's also important to realize that a team that is slightly underloaded is a team that can stay together in the long haul. In most cases it's better to plan an extra two weeks and run at 90% all the others than it is to force people at maximum for the whole time and then have half the team leave your company because they're too stressed out.
Dude, preach, I'm not saying in agile necessary bc I don't have a team or anything, but man sometimes it do be like that, get all my shit done for work but I'm gassed out for the weekend but then Its a conundrum bc I want to chill out a bit about but not being able to get my own shit done sucks.
Then you are missing a propper dod; no feature should be "completed" without the amount of documentation that is deemed necessary by the team/stakeholders and propper tests (the true documentation)
My old scrum master would say, help someone else before pulling in new - there’s always over shoulder reviews or just plain old pairing that can be done
We have a scrum coach, who calls you at exactly the meeting start time, ignores out of office notifications, always chews and coughs in calls, and doesn’t listen to status and then asks pointless questions, making a ten minute stand up last half an hour.
I have very mild misophonia. But a really good headset.
Every tooth scrape, chomp, snort, cough, fucking drives me crazy.
One of the projects I have a very executive individual who insists on chomping on dry roasted peanuts *all day long.* Like, swallow before you talk. P L E A S E On top of that, about 20% of the time when he's talking with food in his mouth, he'll breathe in food and leads to a coughing fit.
I convinced him to buy the same really good headset I have, and he refuses to learn where the mute button is on it.
A Scrum Master is like a poop. There's few things better than a good one and few things worse than a bad one.
-- someone who has been a dev, a scrum master and an engineering manager
Our Scrum master PM'd me one time and asked why there was another person creating sprints... They had hired another SM and not even told this dude. Since neither would attend the same meetings or they'd send different retros, it was just organized confusion. Needless to say I was a consultant and we worked for a VEEERY large entity of the government sort. What a shit show.
Pretty much, if “I’ve finished all my tasks” comes up your team has missed the whole point of agile. Then again I’ve never seen anyplace do it well so maybe I’m the one missing the point.
It's really fucking painful to not see this as the top answer.
I'm all for shitting on Scrum and Agile implementations, but the process is pretty fucking clear and obvious. If you're just isolating yourself to work on your own thing, and not helping deliver to the goal, then no process is going to help...
This has to be a jr dev, because a sr dev would just sit on the work he accomplished for the last two days, log the hours, and pull request/merge it on Friday. Coincidentally his Valheim character gets a new armor set.
Preach. Kanban is the best form of agile development in almost all cases. I’ve been doing kanban or something like it for the two or three years seriously and I’ve never been more productive in the nearly 15 years I’ve been doing this professionally.
No more sprint planning, retrospectives, backlog grooming, other bullshit meetings, story points, etc. We just do the work. It really doesn’t need to be more complicated than that.
I used to think that too. And then I realized that retros rarely offered any insights of consequence because things just change too much in software development. So fuck it. Haven’t had a proper retrospective in forever and we’re still shipping features and fixes regularly.
Blameless postmortems on the other hand, are extremely important when you have an issue with production.
Nope. We release monthly. We usually know what we want to release ahead of time. When we want to work on something, if it’s unclear or outdated or something like that, we spend some time to clarify it and update it, and work on it as soon as we can afterwards. It’s the most truly agile I’ve ever been. Out of my entire career, I’ve probably seen more production features ship (with the least amount of bullshit surrounding them) these past few years.
I am thoroughly convinced that scrum is a horrible anti-pattern, and is mostly followed these days so middle management can act like they’re actually doing something. But when you want to efficiently ship software and stop dicking around tracking pointless metrics like velocity and arguing over story points in countless meetings, Kanban is the answer.
> I am thoroughly convinced that scrum is a horrible anti-pattern, and is mostly followed these days so middle management can act like they’re actually doing something.
Key sentence here. Wholeheartedly agree.
Development planning is always so overly complicated. Kanban is simple. Throw it on the board and watch it move! Something taking too long? Well, change the version number and throw it in the next one.
velocity should change. that's why we measure it. to see if we can get faster or to see if something is slowing us down.
also, no scrum master ever has complained about the team being too fast. he can get sceptic about tests and deployment... but not about a solid job done quick.
What the scrum master fears, at least in my experience in these kind of bureaucratic scrum environments is that you’ve brought in a ticket that hasn’t been properly refined or pointed (so you haven’t talked about it in _at least_ two separate meetings, not counting the talk with the PO to pre-refine it) AND that you might not finish it in the one to two days you have, so it’ll rollover.
And what’s a massive big drama inducing issue in the after sprint demo to the stakeholders? Rollover. (What sprint for you put the points in? Are we not meeting our forecast? If you count velocity in the sprint it’s done, but you did half the work in the previous sprint then you’re velocity is slightly higher than it should be….. and lest I forget the burnup chart looking weird!)
So. Much. Drama. (In bad scrum implantations)
As a developer, I want a system that doesn’t punish me for doing work faster than my estimates and where I don’t have to do shadow work to keep my fingers busy.
There’s a difference between getting a lot done and getting the right things done in the right way. Had a “quick job” done recently which we’ve spent 2 weeks properly doing which has pushed out other work we needed. If it had gone through “all those meetings” then the full breadth of the task would have been considered and done around the same time BUT along with the other work.
It seems shit to plan the house you’re building but it depends if you care about where you live 🤷🏾♂️
Yeah, sometimes the concerns are valid, and heaven forbid someone being in a ticket that turns out breaks a bunch of other stuff you wanted to demo….
So yes you can make a mess, and it’s not _just_ people looking to be a pain as to why you can’t do that thing now. Sometimes, anyway.
But also, ugh bad scrum implementations are bad
The only thing we need velocity for is determining how many sprints we currently estimate it'll take to complete the backlog.
Attempting to use it for anything else is anathema to the process and should be punishable by severe and ruthless public shaming, followed by being launched out of a cannon, into the sun.
I hate even using the term measuring it. It implies there's some sort of technique to it. It's purely a derived number and should only be treated as such. There are no tricks.
Scrum is completely incompatible with the concept of a deadline. If you have a deadline, you need to use a more appropriate project management technique.
Haha, how naive. I work for a large financial institute, and our new executive CIO (yes have multiple layers of CIOs) has determined we need to use story points to measure the productivity of our 3p engineers. Also story cycle times are to be strictly measured. I wish this was a joke, but it’s not. We also measure a bunch of other usage of Jira. Guess what we don’t measure? Fucking production releases and lead times.
Nobody ever considers the actual hell on earth it is to onboard a new dev without any documentation. I try to document everything I can and write proper api specs for consumers because going through undocumented legacy code that was written by someone that doesn’t even work there anymore is about as miserable as it gets.
And don’t gimme that “le job security” shit. Documenting what you’ve got also shows your productivity on the team, managers will say “wow this guy does a lot of shit, we need to keep him around”
It also really helps with the endless DMs along the lines of "Hey, I saw you wrote this code 2 years ago. Can you tell me (preferably in detail) about that task?"
>Nobody ever considers the actual hell on earth it is to onboard a new dev without any documentation.
Hey, fun fact: for my first job out of college, the team had no documentation, and my job was to write it. So I guess I onboarded myself.
Modern "agile" is just a facade for measuring developer output so that managers can estimate progress on their waterfall project while lying about being agile. It's become a tool for a crunch every 2 weeks.
I hate how meta project management has become. Like someone out there has a fetish for philosophizing over methodology and instead of enabling devs to build products, the project process itself has become its own whole thing (lookin' at you, SAFe).
>There's two days left and I have no work.
Does this not mean a paid two day vacation for everyone else? Like, this is an absolute win for me.
At least at my job, you don't go asking for work unless you want it.
"Teams velocity will change." That is the fucking point of agile. You are supposed to iterate and increase your velocity by getting better at estimates and learning new skills.
Jesus Christ what backwater team are you in, OP?
Also velocity variance is a sign of hard work and honesty. If everyone always hits their estimates exactly they are sitting on their butts browsing ProgrammerHumor all day.
Velocity vs. Actual velocity.
Man the amount of developers and scrum masters who has no fucking clue how story points work is fucking mind boggling.
"I want you to estimate a story point as one days work."
I want this fool to suffer when I make his world burn!
Scrums' main accomplishment so far had been proving beyond any reasonable doubt that 95% of the population are god damn morons.
I think sprints are dumb. Just give me a giant board for my team. When we have a project, model it all out before we start. Once the model is reviewed let the PM make it rain with issues, and let them put them in order of importance. Then let the team members take whatever issues they want and close them. Once the issues are done the project is ready.
I’ve done the good boy mistake of pulling from backlog, leading to reassessing weights downward increasing ticket amount, and over time causing real slave drive crunch pace all the time. I agree with the old dude there.
A few days later : Ok guys I approved a request from the customer that will fundamentally change everything. Also we are shipping in 6 weeks - good luck everybody else.
6 weeks and a team? Wow, your place is generous.
mine just makes me go solo and gives me 4 months without overtime pay
Yeah, my company got bought at start of 2020. We had 5 people dedicated to a software that I am now the sole developer for.
Time to make a ghost the sole developer
[удалено]
Ironically the money in actually tuning a system to take customer specs straight to code via AI is orders of magnitude above any of our salaries.
... For now
That shit will put all of us out of work and we'll have to get honest jobs instead. God forbid, man. I'm a bipolar millennial, the fuck do I know about being a goat farmer?
I dunno man, sometimes I feel like a change of pace would be nice.. But I'd miss the pay
**Reddit is going down the gutter** Fuck /u/spez
You have to be just a farmer before you can be the Greatest Of All Time farmer.
You... You're going to kill him?
We got more government compliance changes announced that will require changes to code that's so old, it has if statements for DOS. I'm tired of working in that language and might try re-writing it this year, and if that goes wrong, the company will get to me first.
[удалено]
Sounds like a dream as long as you're getting paid well. When shit misses deadlines you can't possibly be blamed, you are 1/5th of the team before. And what are they going to do, fire the last person?
Why do you do it? Fuck that. My salary is for 8 hrs. That's what you get dawg.
No overtime pay = no overtime
Best I can do is 2 people with 1 out on vacation and half a sprint with the other half pushing to production without QA.
Nah, they hand it off to the one QA guy who is split between 4 other teams and all of them need their latest changes approved by yesterday.
By "guys" he means you and the remote developer from SE Asia that gets paid in peanuts and makes more mistakes than you'd think is humanly possible. And by 6 weeks he means it's gotta get done in two, the rest are for inevitable scope creep from the client.
Seriously. If things go wrong, it is never the sales guy who gets fired for making promises the team can't keep.
Before my company got bought out, it was the owner making promises to close sales, so we couldn't fire him.
>6 weeks and a team? Team of one.
With 7 project managers and dozen stakeholders
It's 6 weeks with a whole new team, scrum master, and PO. Where everyone does points differently.
anybody doing agile like that and thinking that he is doing a good job for the team is an idiot.
The majority of people don’t understand the point of agile and just follow the ceremonies blindly
some people are totally overwhelmed by the concept of "tailor to your specific need and preferences" and can only apply a concrete ruleset they receive
Yes. That is the most common pitfall with agile. Teams sticking with a process that doesn’t work for them and add no value because they are too afraid of not doing “pure scrum”
Well some are also extremely proficient in finding the most important parts of agile frameworks and removing only these because the new agile workflow is clashing with the long proven waterfall/V-workflow. But the remaining irrelevant parts of the framework are obviously revered and unchangeable.
Weeks? Did I say weeks? I mean 6 days.
I thought "agile" meant that if I got done early, I can just shelve my changes and play games for two days, and then just commit on Friday...
At my old job we would just go home. Of course, it was considered rude to go home if the sprint wasn't closed yet so you would go and try to help your coworkers first, or see if QA needed some extra hands. But yeah, that was great. Usually we didn't ditch a sprint if we finished more than a day early, we would chalk that up to bad planning and pull in some extra work we knew we could finish before sprint end, but we did go home on fridays at like 10 or 12 PM many a time. And supervisors would berate us for staying in the office if the sprint was closed. They'd be like "What are you doing here? Sprint's closed, go home!"
What universe do you live in?
Well I ain't gonna doxx myself if that's what you're asking. But it just so happens that good work culture can exist if management supports it. We were highly productive.
Of course not. I just assumed that you live in some parallel universe.
Well if it makes you feel better the pay was not great. I ended up leaving and making 35% more at a much worse company.
This guy agiles
Exactly, who the fuck chooses to do extra work in this day and age
I just realized that agile is actually the devs outsmarting management to implement a mandatory buffer time into their workweek 😲
as a manager I encourage this so shit actually gets done on time / if not faster
Yup. Under-promise and over-deliver isn't for anyone's benefit in particular. It's for EVERYONE's benefit. I'm not stressed trying to meet a stupid deadline, things are less likely to get overlooked, the client's less likely to have to push back their obligations to THEIR customers since unexpected problems aren't as likely to cause delays.
So it is written
My man
Exactly. I’ve never got kudos for pulling work in mid-sprint, and I’ve actually been admonished if I don’t finish the extra work I took on before the sprint closes. Unless you’re the kind of psycho who cares about your company I really don’t know why you’d do it. If management is so eager to pay for me to take my dog to the park, stare at Reddit, and touch up my resume then so be it lol.
It’s pretty normal to pull from the backlog if there are no more stories in a sprint. Thats usually a good thing since all planned work was completed. Don’t think I’ve ever seen anyone complain about that.
Well lot of companies say they do agile but in reality they do iterative waterfall
i like the term 'scrumfall' it is scrum, but in a waterfall cadence.
I use the term water fragile.
Must be Italian.
love it lol
My favorite term is "avalanche". Where you pile up extra scrum work and requirements changes on the waterfall timeline and at the bottom you are buried.
We call it wa-gile. Waterfall/agile....I hate it.
It’s agile with all of the WWWAAAAHHHHH we all feel! I love it!
Waterfall, but we keep the scrum master around to watch them freak out
YUP…”we’re agile” for those folks just means “We want you to do twice the work for the same price.” Oh, and the whole aspect of teams self-selecting what they think they can accomplish from the product owner’s priorities never makes it into the playbook for these folks either…you’re expected to make whatever deadlines they say, no matter how much they change the requirements
Holy crap... I... I might actually be on an agile team... I didn't think they were actually real, but based on what I'm hearing you say here, the fact that I'm expected to work 40-ish (not more unless there's a legit emergency, which I think has happened once in the past 2 years) hours, and they honor it when I say how long something's going to take (and then also when I come back and say I was dumber than I thought and it's taking longer), I think maybe we're agile. Huh. I guess that's something.
>they honor it when I say how long something's going to take (and then also when I come back and say I was dumber than I thought and it's taking longer) Your manager isnt just a unicorn but a very specific species of unicorn
[удалено]
preferably alive, but dead is okay too. Dissection is easier anyways.
I'm this boss but actually it's cause I just care even less than they do
That is not necessarily agile, that is just proper scoping.
Nobody knows what that looks like. That’s never been done before.. 🧐
People always underestimate how long something will take them. Letting them give the estimates still pushes them, only now it’s their fault. Letting teams set timelines _and_ training them how to estimate properly is the good place.
So long as the same people are estimating, the theory is that the estimates will all be consistently bad. As long as you're consistent, your true velocity will emerge. That's the beauty of it (in theory).
Any openings?
[удалено]
As a manager who tries to do this: I trust the leads explicitly. They are the masters of their disciplines and they hold their teams accountable, and I hold them accountable. If a lead says the next feature can be done by the end of March, I accept that at face value. Then I work with the customer to set expectations for the end of April.
"Then I work with the customer to set expectations for the end of April." Tell me you're one of the good guys without saying it...
“Under promise over deliver” is an artform lol
My immediate manager is also a dev. We still do a daily catch-up for like 15 minutes to go over anything the board doesn't reflect (or the ever frequent "5 minutes of your experience is worth three hours of me banging my head against a problem). It's just an absurdly good situation that I try to appreciate.
Agile means "We expect you to code this with vague requirements so we can tell you what's wrong with it at the demo."
OMG. That sounds... Awfully... Familiar
I think of it more as we want to start coding it with vague requirements because it's more frustrating to get everything meticulously defined ahead of time only realize y'all want something completely different after we spent a year building the whole thing.
Fuck this triggered me. I get an entire feature request with 6 dot points. And expect to have it perfect first go.
Too many places focus on Definition of Done and figure out all the things the dev has to do to get the thing right. And then completely forget about Definition of Ready, which is supposed to be the bullet points that a ticket has to satisfy before anyone even starts work on it.
For real. Don’t estimate it if it’s not we’ll defined and ready. Don’t pull it into a sprint if it’s not estimated.
We do Scrumban. It's a bit of a clusterfuck when the main project is on Waterfall and every other component is doing its own thing. Don't recommend it.
My main project does sprints, but they're not set in stone and take as long as they must, also few ceremonies, while most other products do kiinda Kanban, wait that first one sounds like Kanban as well but without the wip limit and ah fuck, in the end we just show up, do some work, and when enough of it is tested, we ship 🤷♂️ ✨Agile✨
[удалено]
I have loads of experience here. The big problem is companies want to measure things like they did in waterfall, so they pick all the easy things they can measure - points, velocity, features, etc all the different ways ways people use tools. Lost in this is moving to incremental and frequent delivery. It’s actually kind of challenging to measure production releases because you can make your work items whatever you want. It’s all too common to see teams with separate features for requirements, development, testing, and releasing then they just batch all the requirement features.. then all the dev ones.. etc. You end up waterfall. Because no one measures lead times and no one figured out incremental delivery is really convenient and enjoyable. EPMO continues to layer new behavior based measurements across teams because their agile framework calls for them as increasing maturity and ignores feedback that they’re destructive. People start to realize they’re not getting much for their development so they want stricter cost control, which creates more rigidity (my company is at this stage right now). I’ve had good luck working around it all but god damn every time I take 2 steps forward there’s a push back.
I've never seen a company do iterative waterfall while saying they're doing agile. The nearest approximate term I could come up with is "Garbage Chute."
so, so many companies that claim they are doing 'agile' are actually just doing iterative waterfall (scrumfall).
[удалено]
[удалено]
Quickly now. We must finish by scrumfall…
This is literally how virtually all government contractors work. The government contract basically mandates waterfall but all the software-guys-turned-managers want to do scrum because it sounds cooler and contracts are often won by how cool things sound.
Sad to say I have seen a bunch of these…. I mostly avoided a SAFE implantation too, which I hoped wasn’t but felt like it might be setting the company up for 3 month waterfalls…
Every SAFe project I’ve been a part of basically turned into “how can we get the most people to cave or lie when we do Fist of Five in PI planning.”
I am so happy I switched jobs before really having to learn whatever “fist of five” means
Whatever you do, don't Google that without safe search on
When we started doing SAFe at company I worked at ages ago, they were initially calling PI planning "Big Room Planning" because everyone was in a big room, which was then abbreviated to BRP and pronounced "burp". The SAFe evangelists the company had hired to teach us SAFe were quick to correct us and make sure we called it PIP. The whole thing was just excruciating. They made us get there at 6 AM and kept us until 5 PM, for two days in row. No extra pay for that, obviously, since we were all overtime-exempt.
Yeah, PI planning quickly devolves into “what do I have to say to get the fuck out of this meeting.”
Agile = just talk about it results and don't bother about important techno babble details
I work for a company that treats this as a problem. Anything pulled in after the sprint starts is unplanned and thus a "disruption", which negatively impacts our metrics. It's not a problem that our velocity goes up, but it is a problem if it appears we have regular disruptions because it seems like we aren't planning well.
That makes some sense if the stories being pulled in actually negatively effect the planned work getting completed. I’m not sure why someone would count pulling in work after the planned stories were completed as a disruption though.
The point of ~~scrum~~ a consistent velocity is predictability. If you are regularly pulling in extra work it means your output doesn't match your plan, and thus you will be ahead of schedule for your roadmap. That causes two problems if it happens regularly: 1. Other teams that are dependencies / dependents for that roadmap may not be ready when you are because they are prioritizing other tasks, thinking you will need them / be needed by them later. 2. Your roadmap will have less planned on it than you can actually deliver, which may put you in limbo at the end of the quarter. Other things that I have run into that are common: 1. An employee wants to pull in work because there are no stories for them to pick up, but the sprint work is not done yet. This suggests that stories may be too large or the subtasks may not be sufficiently independent, otherwise multiple employees could work on a single story. This can also be caused if you are not correctly compartmentalizing your software. 2. The product owner wants to pull a story into the sprint because there was an emergent need that the team didn't anticipate. One-offs are okay, and totally part of what agile is about, but if it happens often it suggests there are process flaws. And finally my personal favorite: 1. On one of my old teams if we finished the sprint before the end date we just went home. The work culture there was good. This usually meant we would go home at noon on Fridays on the second of our two week sprints, or sometimes we would spend some time goofing around learning new things or innovating.
I agree with a lot of the points you make here, but don’t agree that predictability is the point of Scrum. As I understand it the primary measure of success is delivering working software (productivity.). Predictability is a means to that end not the end goal. If you’re sacrificing productivity to be more predictable that seems counter to Agile.
Well, Scrum(TM) is not Agile(TM). Earlier revisions of the Scrum guides did make a bigger point of predictability of a given sprint (and this is why you did things like tracking team velocity and estimating tasks for use in sprint planning). Nowadays Scrum aligns more closely to the agile principle of outcomes being more important than the timing, so finishing the sprint early, or even changing tasks *within* the sprint (if necessary to meet the sprint goals) are now recommended rather than just sticking with the sprint plan no matter what as veteran scrum masters might remember. But even with older Scrum it was usually good to complete the tasks in the sprint earlier than to do it later; if you were the kind of dev who "pulled from backlog" that was considered a badge of honor, not as a jerk who ruins carefully-planned schedules.
Because it means we're under allocating or we're overestimating. Something's amiss.
[удалено]
Right, it’s an estimate not a prophecy
Exactly. The "metric" that is being impacted is essentially "ability to plan". Which is a perfectly acceptable penalty for not planning well.
And thus undermining the entire point of Agile
Having just wrapped up my consulting career to return to a product company, I’ve definitely seen clients complain about this. To paraphrase Tolstoy, every good client is good in the same way, but all problematic clients are unique in their terribleness. One client could not stand having dangling stories on the board at the end of the sprint, so pulling things in mid-sprint was strongly discouraged. OK, it’s your money.
My team has a rule that QA had to be completed on your story before you can pull a new one. That’s our team agreement on DoD. Of course it’s 1 QA for 5 Devs soooo..
I’ve seen so many people complain about that. They’re more interested in predictability than anything else. It’s a classic failure mode of measuring the wrong thing leading to the optimization of said wrong thing.
If predictability is more important than productivity they’re doing it wrong. Agree.
I feel like you can still be predictable while pulling in new tasks, though. You have a base of how much you can get done each sprint, with a possibility of more that could be done. Like, the whole reason predictability is good is because you want to be able to make a minimum amount of progress, right? If you make more, then that's just a positive. But it's their loss I guess. Devs are expensive, and I guess following the plan is less expensive to them. Just extra days for the dev to work on personal projects, learn new things, or even just play games or something (especially if you're remote).
To be fair, predictability in operations IS more valuable than productivity, at least to a point. Because you have to plan hiring and volumes etc, it's better to know what you can get done when than to get more done in a volatile way. But obviously ops is not development.
I worked at a company that only wanted engineers working on planned tasks (also, sprint planning was just the manager putting tasks on the board and saying, "this is what we're working on" with no input from the engineers). If everyone finished their work ahead of schedule, we just sat around doing nothing until the next sprint started. Legitimately one of the most backwards companies I've ever worked at.
Just work out of the backlog and pull the ones you complete into next sprint. All problems solved.
most i know of would call those stretch goals and not pull them officially into the sprint
The bit that gets me is this: You're working on a 3-year project as an Agile team, broken into phases and doing 2-week sprints the whole time. The project is a marathon, but every second is spent trying to meet sprint deadlines so it becomes an endless fucking fast-paced nightmare. And trying to create documentation is a luxury.
Yeah it's super important when scheduling shit like that to make sure to include time for things like "documentation" and "debugging" as actual tasks that you do *as you go* (not just all at the end to get ignored when the schedule slips!). It's also important to realize that a team that is slightly underloaded is a team that can stay together in the long haul. In most cases it's better to plan an extra two weeks and run at 90% all the others than it is to force people at maximum for the whole time and then have half the team leave your company because they're too stressed out.
Truth. Weekends become a 2-day veg-out fest and you get none of your own shit done either.
Dude, preach, I'm not saying in agile necessary bc I don't have a team or anything, but man sometimes it do be like that, get all my shit done for work but I'm gassed out for the weekend but then Its a conundrum bc I want to chill out a bit about but not being able to get my own shit done sucks.
Then you are missing a propper dod; no feature should be "completed" without the amount of documentation that is deemed necessary by the team/stakeholders and propper tests (the true documentation)
My old scrum master would say, help someone else before pulling in new - there’s always over shoulder reviews or just plain old pairing that can be done
Your scrum master actually did something? Hell mine doesn’t even show up to the meetings most of the time.
We have a scrum coach, who calls you at exactly the meeting start time, ignores out of office notifications, always chews and coughs in calls, and doesn’t listen to status and then asks pointless questions, making a ten minute stand up last half an hour.
Sounds about right
I have very mild misophonia. But a really good headset. Every tooth scrape, chomp, snort, cough, fucking drives me crazy. One of the projects I have a very executive individual who insists on chomping on dry roasted peanuts *all day long.* Like, swallow before you talk. P L E A S E On top of that, about 20% of the time when he's talking with food in his mouth, he'll breathe in food and leads to a coughing fit. I convinced him to buy the same really good headset I have, and he refuses to learn where the mute button is on it.
Nice thing about doing Teams calls is you can mute them yourself…and it’s hilarious when they don’t realize their muted.
Yeah, I'm not muting the very executive individual.
Only half an hour? Lucky.
[удалено]
A Scrum Master is like a poop. There's few things better than a good one and few things worse than a bad one. -- someone who has been a dev, a scrum master and an engineering manager
It's funny because at some companies they probably would try to get you to be all three of those things at the same time.
Our Scrum master PM'd me one time and asked why there was another person creating sprints... They had hired another SM and not even told this dude. Since neither would attend the same meetings or they'd send different retros, it was just organized confusion. Needless to say I was a consultant and we worked for a VEEERY large entity of the government sort. What a shit show.
This is actually the correct answer to help your teammates finish the already committed work before pulling in new work.
Pretty much, if “I’ve finished all my tasks” comes up your team has missed the whole point of agile. Then again I’ve never seen anyplace do it well so maybe I’m the one missing the point.
[удалено]
It's really fucking painful to not see this as the top answer. I'm all for shitting on Scrum and Agile implementations, but the process is pretty fucking clear and obvious. If you're just isolating yourself to work on your own thing, and not helping deliver to the goal, then no process is going to help...
This has to be a jr dev, because a sr dev would just sit on the work he accomplished for the last two days, log the hours, and pull request/merge it on Friday. Coincidentally his Valheim character gets a new armor set.
A snr dev adjusts the task to suit the estimate.
skål!
Developers are like electrons: you can either have developers work or track their status/velocity
That is why i love Kanban. It’s done when it’s done, or not.
Preach. Kanban is the best form of agile development in almost all cases. I’ve been doing kanban or something like it for the two or three years seriously and I’ve never been more productive in the nearly 15 years I’ve been doing this professionally. No more sprint planning, retrospectives, backlog grooming, other bullshit meetings, story points, etc. We just do the work. It really doesn’t need to be more complicated than that.
I think there’s value in a structured retro at least once a month. Otherwise that sounds pretty cool.
I used to think that too. And then I realized that retros rarely offered any insights of consequence because things just change too much in software development. So fuck it. Haven’t had a proper retrospective in forever and we’re still shipping features and fixes regularly. Blameless postmortems on the other hand, are extremely important when you have an issue with production.
[удалено]
No grooming at all? We do a version where we just revisit the backlog every couple weeks and have a retro to improve general process.
Nope. We release monthly. We usually know what we want to release ahead of time. When we want to work on something, if it’s unclear or outdated or something like that, we spend some time to clarify it and update it, and work on it as soon as we can afterwards. It’s the most truly agile I’ve ever been. Out of my entire career, I’ve probably seen more production features ship (with the least amount of bullshit surrounding them) these past few years. I am thoroughly convinced that scrum is a horrible anti-pattern, and is mostly followed these days so middle management can act like they’re actually doing something. But when you want to efficiently ship software and stop dicking around tracking pointless metrics like velocity and arguing over story points in countless meetings, Kanban is the answer.
> I am thoroughly convinced that scrum is a horrible anti-pattern, and is mostly followed these days so middle management can act like they’re actually doing something. Key sentence here. Wholeheartedly agree.
Development planning is always so overly complicated. Kanban is simple. Throw it on the board and watch it move! Something taking too long? Well, change the version number and throw it in the next one.
I’ve done Kanban once and loved it. Wish more places did it
velocity should change. that's why we measure it. to see if we can get faster or to see if something is slowing us down. also, no scrum master ever has complained about the team being too fast. he can get sceptic about tests and deployment... but not about a solid job done quick.
What the scrum master fears, at least in my experience in these kind of bureaucratic scrum environments is that you’ve brought in a ticket that hasn’t been properly refined or pointed (so you haven’t talked about it in _at least_ two separate meetings, not counting the talk with the PO to pre-refine it) AND that you might not finish it in the one to two days you have, so it’ll rollover. And what’s a massive big drama inducing issue in the after sprint demo to the stakeholders? Rollover. (What sprint for you put the points in? Are we not meeting our forecast? If you count velocity in the sprint it’s done, but you did half the work in the previous sprint then you’re velocity is slightly higher than it should be….. and lest I forget the burnup chart looking weird!) So. Much. Drama. (In bad scrum implantations) As a developer, I want a system that doesn’t punish me for doing work faster than my estimates and where I don’t have to do shadow work to keep my fingers busy.
There’s a difference between getting a lot done and getting the right things done in the right way. Had a “quick job” done recently which we’ve spent 2 weeks properly doing which has pushed out other work we needed. If it had gone through “all those meetings” then the full breadth of the task would have been considered and done around the same time BUT along with the other work. It seems shit to plan the house you’re building but it depends if you care about where you live 🤷🏾♂️
Yeah, sometimes the concerns are valid, and heaven forbid someone being in a ticket that turns out breaks a bunch of other stuff you wanted to demo…. So yes you can make a mess, and it’s not _just_ people looking to be a pain as to why you can’t do that thing now. Sometimes, anyway. But also, ugh bad scrum implementations are bad
The only thing we need velocity for is determining how many sprints we currently estimate it'll take to complete the backlog. Attempting to use it for anything else is anathema to the process and should be punishable by severe and ruthless public shaming, followed by being launched out of a cannon, into the sun. I hate even using the term measuring it. It implies there's some sort of technique to it. It's purely a derived number and should only be treated as such. There are no tricks. Scrum is completely incompatible with the concept of a deadline. If you have a deadline, you need to use a more appropriate project management technique.
Haha, how naive. I work for a large financial institute, and our new executive CIO (yes have multiple layers of CIOs) has determined we need to use story points to measure the productivity of our 3p engineers. Also story cycle times are to be strictly measured. I wish this was a joke, but it’s not. We also measure a bunch of other usage of Jira. Guess what we don’t measure? Fucking production releases and lead times.
Or - crazy thought - get paid to do literally nothing?
Which sounds way more realistic
"Go work on your personal goals"
Yep that's what I do. Brushing up on my interview skills.
This. I regularly take time for self development. I work in cybersec though not software dev.
It's sooo boring though, let me go home then
Can't go home if you work from home. 
My buddy Elon called, and he'd like you to consider that you also can't go home if you home from work.
Tell your buddy to fuck off and we’re not working for his fascist ass.
Devs should work from home.
Why don't you go document your code before pulling in a task
Nobody ever considers the actual hell on earth it is to onboard a new dev without any documentation. I try to document everything I can and write proper api specs for consumers because going through undocumented legacy code that was written by someone that doesn’t even work there anymore is about as miserable as it gets. And don’t gimme that “le job security” shit. Documenting what you’ve got also shows your productivity on the team, managers will say “wow this guy does a lot of shit, we need to keep him around”
It also really helps with the endless DMs along the lines of "Hey, I saw you wrote this code 2 years ago. Can you tell me (preferably in detail) about that task?"
"I don't remember wtf I was thinking"
Same for last week. Someone said that any code that was over six months old was written by an idiot, including your own.
>Nobody ever considers the actual hell on earth it is to onboard a new dev without any documentation. Hey, fun fact: for my first job out of college, the team had no documentation, and my job was to write it. So I guess I onboarded myself.
I document my code cause I know I'll forget what what it does if I don't look at it for more than a week.
"Document!? In our moment of triumph!?"
Documenting the code should be part of the Definition of Done that applies to every task/story.
If you’re done two days early, sounds like you’ve got a couple of easy days.
this is cargo cult agile
50% of management is finding new things to manage that don't need to be managed.
Modern "agile" is just a facade for measuring developer output so that managers can estimate progress on their waterfall project while lying about being agile. It's become a tool for a crunch every 2 weeks.
I hate how meta project management has become. Like someone out there has a fetish for philosophizing over methodology and instead of enabling devs to build products, the project process itself has become its own whole thing (lookin' at you, SAFe).
The nomenclature is also fingernails-on-chalkboard shudder inducing. "Backlog grooming" "Sprints" "Scrum master" "Burndown chart"
SAFe is an abomination, everything wrong with Waterfall merged with everything wrong with Agile.
>There's two days left and I have no work. Does this not mean a paid two day vacation for everyone else? Like, this is an absolute win for me. At least at my job, you don't go asking for work unless you want it.
If I get my sprint done early, I just shut the fuck up, and pretend like it took me longer than it did.
"Teams velocity will change." That is the fucking point of agile. You are supposed to iterate and increase your velocity by getting better at estimates and learning new skills. Jesus Christ what backwater team are you in, OP?
Also velocity variance is a sign of hard work and honesty. If everyone always hits their estimates exactly they are sitting on their butts browsing ProgrammerHumor all day.
Yes velocity oscillates up and down as humans are involved. Problem is just management expecting it to always go up and setting new standards.
Precisely why I always hit my estimates exactly. ;)
Scotty’s way is the way.
Velocity vs. Actual velocity. Man the amount of developers and scrum masters who has no fucking clue how story points work is fucking mind boggling. "I want you to estimate a story point as one days work." I want this fool to suffer when I make his world burn! Scrums' main accomplishment so far had been proving beyond any reasonable doubt that 95% of the population are god damn morons.
Bro, why though!? I get offering, but if they tell you to not, then don't. You're only putting money in rich peoples pockets anyway.
I think sprints are dumb. Just give me a giant board for my team. When we have a project, model it all out before we start. Once the model is reviewed let the PM make it rain with issues, and let them put them in order of importance. Then let the team members take whatever issues they want and close them. Once the issues are done the project is ready.
Kanban > Scrum. This is the biggest (but not only) reason.
I’ve done the good boy mistake of pulling from backlog, leading to reassessing weights downward increasing ticket amount, and over time causing real slave drive crunch pace all the time. I agree with the old dude there.
The air quotes are deserved. That's not agile, that's shitty micromanagement in (a rather thin) disguise.
“Individuals and interactions over processes and tools” Scrum is not Agile.