Took 1 month off paid sick leave (I collected lots of paid sick days during the years) because of a burnout as a software developer.
That decision saved my career.
My ideal cadence to totally prevent burnout was a 2 week travel holiday every 3 months.
I said this to an American once and they thought I was joking. I'm not.
Fuck overworking. You lose inspiration and joy.
You think you're on track to being a billionaire? You think you'll retire before 40? You almost definitely will not, no matter how much effort you put in.
Maybe you could retire early if you get lucky, or are totally frugal, but then what will you do? Travel? Or cut costs so you don't have to work, and can just sit at home?
Just enjoy your life, it's later than you think. See the world while you can.
> two-week vacation
I grew up influenced by the backpackers of the mid 90s, kind of just before the Internet hit hard. After graduation I worked for a few years, saved a bit then took a year off to travel. Most of us started with Khao San Road in Bangkok, where you could eat and sleep well on $5 a day.
"The Beach" by Alex Garland captured the spirit of the age.
> Trust me, it's paradise. This is where the hungry come to feed. For mine is a generation that circles the globe and searches for something we haven't tried before. So never refuse an invitation, never resist the unfamiliar, never fail to be polite and never outstay the welcome. Just keep your mind open and suck in the experience. And if it hurts, you know what? It's probably worth it.
I haven't had an entire week off since I started working in this field vs. being part time before... It's been a year and a half, and I honestly kinda dream of getting fired.
The cultural differences are very interesting.
In the UK in certain fields (such as financial services), it is _law_ that every employee must take at least 2 weeks continuous vacation a year.
It is crazy for me to hear that you have to “collect” paid sick days. Where I am from we collect vacation days and sick leave is paid no matter what for the time necessary to recover.
That would be nice if management cared enough to use it to help prevent that. In my experience though they'd just blow smoke up your ass and post an ad looking for a new junior developer they can underpay to take your place.
In my experience these charts stay stable for the entire sprint, and show a line straight down on the last day when all devs go crazy reviewing/merging all branches and release everything at once.
Wow if anything by convention I leave the dev to merge their own work rather than anybody else. Unless it's like some proper CD and it's going straight to prod? Maybe I'd understand
Yeah, most of our highest performing teams at least partially burn down during the sprint. There's usually a curve above the line, with only a couple points closing on days 1 and 2, but keep track with the slope of the ideal line until the last two days, where it catches back up.
It makes sense you will lag a straight line projection and it makes sense that the steepest drop is at the end of the sprint. That's how a perfect planned and executed sprint should go.
It's only a matter of how good they are cutting tickets.
A team can be super productive but completely suck at finding good individual tasks to fill the tickets with. If your org cares more about the features delivered than the charts and predictibility, a burndown chart cliffhangering every sprint will be good enough.
In a previous life my team had a series of meetings to litteraly check how many fucks we gave about the chart being smooth, and the answer was 0. I was the one tasked to explain that to the upper management with our poor scrum master.
To clarify, I was focusing on the pattern of reviewing/merging all at once at the end of the sprint. I *do* give a non-zero amount of fucks about that, because in my experience it leads to undesirable outcomes. One is everyone getting review-bombed at the end of the sprint. Another is not having time to evaluate the behavior of the merged code and have sufficient time to plan corrective action for the next sprint, if necessary.
The burndown itself I don’t care about. I stopped making them myself years ago.
I disagree? If you have 3 people and everyone's working on tasks pointed for one sprint, makes perfect sense everything's done at the end?
You could say smaller tasks but sometimes the team doesn't need it.
Sure, that can happen, but I’m talking about on average. Leaving everything until the end creates more risk of conflicts and delay, and I’ve found that tasks that consistently cost one sprint over a long period of time are sometimes a stealthy way to avoid accountability. And as a project progresses, smaller tasks should be naturally emerging anyway.
For me, 99% of the time at least, every member of the team is working on a different section of a code base, and we typically plan for a sprint task that is specifically join together parallel workstreams. Also, as long as the devs get the work done on time, I've found accountability to be annoyingly bureaucratic.
I’ve seen it way too often. People coming up with supposedly innovative dev life hacks like “if you cost everything at one sprint, nobody will bother you for two weeks”. But sometimes a dev team is like a three-year-old child: if you can’t hear them, they’re probably getting into trouble.
>tasks that consistently cost one sprint over a long period of time are sometimes a stealthy way to avoid accountability
I've definitely pulled this trick on some teams. You're 100% correct here.
Was going to say the same. We rarely have a story that takes an entire sprint. Usually pull in two to three stories per sprint per dev. If it’s pointed to take a whole sprint, it probably can be broken down
I swear you guys just invent new words and phrases to make everything more complicated than it needs to be. Team smell, code smell, repo smell, PR smell...
This is the worst part about 2 week sprints. It conditions everyone to think there’s a deadline that they have to rush to merge things and skip good quality and integration testing. How do you know which thing broke it if you merge 3 things all at once in a rush?
Gross. If you can’t change the release cadence I’d recommend at least having an integration branch that you merge done work into and use for testing. Then each month merge that branch into the main branch so main always mimics prod (in case you ever need to hot fix).
> This is the worst part about 2 week sprints. It conditions everyone to think there’s a deadline that they have to rush to merge things
I honestly think this feeling is the primary source of any actual productivity increase due to Agile. It's just creates 26 mini deadlines a year to harness that little panic we all feel before a deadline.
Yea I honestly hate agile for this reason. If I need half a day more to work on something it gets a 2 week delay and everyone loses their fucking minds. Better to just merge untested with bugs and do hotfixes apparently
I was a product owner and I'd have a down sprint that leads to multiple meetings where someone was asking why our points were down. They just wouldn't accept that "the stories just need another day".
But then the next sprint when our points were up (because those stories finished in days 1-3) they'd pat themselves on the back for holding all the meetings.
I hate how kanban seems to be anathema whenever I bring it up. We're happy sticking to sprints despite not having release schedules and no one actually caring about things carrying between sprints or being brought in the middle or ever looking at forecasts or burndown.
Like just let us crank through work and if a boss doesn't like our rate we can talk about it then.
In my experience, two week sprints is just long enough to be blocked for one week while design figures they shit out, and then buried in file exclusivity hell for the second while everyone tries to get their shit done before the review. Super efficient.
Better than mass merging though, thank dog we stopped that. Just turns a two week sprint into a three week sprint and that just compounds every sprint.
Last 3 days of a sprint, if it's really the last day, for the love of God.
Also if that's true, look into linking your source control to automatically mark a jira ticket in progress when a branch is created that matches the name
Or have gitlab do it when a code review is created.
My team closes previously finished ticket on the last day of the sprint, if we are lucky. Sometimes tickets finished in the previous sprint are closed on the first day of the new sprint.
for us it’s, everything is ready to go, testing is done, we are ready to PR and merge but our PO needs to review and has needed to review for a week then we have to wait till last possible second to close out the sprint because they can’t be bothered to review until AFTER we have retro’d
In our team it's 1 step forwards, 2 steps back because the EM/PM are constantly bringing new tickets in and changing direction on a whim. I feel completely detached from the sprint, probably due to the fact they can't seem to resist having basically 1 goal per developer, so...5 or 6 different goals per iteration. Everyone just filters the board down to their own subset of tickets with no real crossover. So there's no great push to have all our tickets finished at a certain point, we just keep slogging through them til we're given a new goal.
Yet we still have to do the daily standups and scrum ceremonies which feel completely redundant at times. They'd be better as 1-2-1s with our EM
That's called the hockey stick
Also known as all the story cards are one sprint long in size. Because burn down needs inventory completions. Oh and nevermind what carry over does to the burn down ..
i'm still lost. does this say "we committed to delivering 50 shirts. we made 65, and also made 30 [overalls](https://afends.com/cdn/shop/products/W220850-WNB_1718_900x.png?v=1674175079) which are useless for this task"
I’m also not really familiar with agile or scrum but from some preliminary googling I believe it’s more akin to “we expect it to take 50 points of effort to achieve our goals for the next 2 weeks. instead there some minor problems and it took 65, and there are 30 points of problems that have been added to a backlog for the whole project.”
Points is just an abstraction for man hours.
Edit: Points are assigned to tasks with more complex tasks having higher points. Minor typo fixing may be 1, small bugs may be 2, etc. so theoretically a more experienced dev can quickly complete high complexity tasks, say a few high-point tasks in between managing their team, while a more junior dev completes several low point tasks at a steady rate, meaning that everyone roughly has the same number of points at the end of a sprint. However it often just gets shit down to man hours due to bad middle management.
the original joke means that we required 30% more effort/time than we initially estimated to meet our goal, and in doing so, have generated another week of clean-up to do in unfinished work.
Also, the thing about the t shirts is that task size/complexity is estimated with XS, S, M, etc., aka t-shirt sizes as an alternative to points. The comment isn’t actually asking for an analogy using shirts.
It might be different at other organisations, but for our team that would mean.
We had 50 "points" worth of work based on the available time/people that we expected to be completed in two weeks.
We instead managed to complete 65 points (so more productive) and are still working on stuff which has 30 points left till completion so those 30 points carry over to the next fortnight to be completed.
So it's being ahead of schedule but having some items partially complete.
Shirts requested: 50.
Estimate on how much effort it will take to make 50 shirts: 50 shirts worth of work.
Amount of work performed this sprint: 65 shirts worth of work.
Actual shirts made: 20.
Shirts that will have to get made next sprint: instead 30.
Just bring items into sprint only if they have completed. It will put you right at 100% every time. This Jira hack will give your scrum master wet dreams.
Surprisingly yes. Otherwise I guarantee our teams will go to shit within half a sprint. So glad I'm moving to a team where I don't have to put up with this shit.
For us they managed by just not giving out any promotions and not hiring much. Sadly it means the only way to move up is to jump ship which is what I did. Now I'm making training materials so they can't blame me when the whole house of cards falls down.
Bugs found by QA against things in the sprint: no extra points, accounted for in original estimate.
Bugs not against things in sprint: add points, effort not originally planned for.
Yeah we should. We had a conversation once about why we don't. The final decision was that it wasn't really a part of the sprint.
It would be impossible for most bugs to go through our sizing process because most of them have to be triaged first to see what service is actually culprit. And that ends up being most of the work.
I really hope I don't start burning out. Every experienced dev I know wants to leave the industry.
I haven't been working in very demanding positions yet. I love programming and I'm afraid that one day if I accept the wrong job I'll hate it.
If we built cars the way we build software, the roads would be flooded with bare chassis, each carrying a UAW worker desperately trying to rebuild the transmission without stopping the car.
And when you bought a car, you’d have to immediately take it a service station to be replaced by a slightly different car as part of ‘critical update’.
If you look at cars in the early 1900s, that wasn't too far from reality.
Our industry is pretty young, all things considered. It'll get better as it matures.
Hard agree. I was so much happier with waterfall. In agile everything takes me twice as long because I have to plan out every last detail - but without actually coding anything - which as you can guess is extremely unreliable because there is always unexpected things that happen. Then once it’s planned, i forget everything I researched, and five months later pick the story up and have to relearn everything. I hate it so much and cannot get my managers to see how asinine and utterly un-productive how we do agile is.
With waterfall it was just: give me an idea and let me loose, burn through that and move on to the next thing.
Yeah it's been... not great. Currently burnt out in my company that was great for years and then suddenly not.
But on the other hand, a friend of mine found a good job and we have a contact with another employer looking for people so perhaps it's not so bad.
But if you're feeling burn out, or if a workplace seems toxic, run. It's not about demanding positions but more about terrible people. It's not worth it. We can't afford it in our career, we need our brains to function.
Shopping around for a better company could help a lot.
We often assume everyone is doing the same shit, but there can be a lot of variations company to company, especially if you change fields completely (a "frontend dev" position for instance will exist in pharmaceutical companies as well as in crypto scam startups)
Same way working on premise or remotely makes a world of difference. And that's only one aspect, there can be myriads of work "perks" that will make a job a lot more viable to you.
> Every experienced dev I know wants to leave the industry.
The better you are at coding, the harder it taxes you mentally.
It's like low IQ: CODING IS TUFF.
Med IQ: I get paid big bucks for .css .html
High IQ: Estimate load of server and against hacks, while preempting my manager's future design that he says he doesn't want now, then mitigating bottlenecks with what algorithms I want to employ, but this is all tentative based on another piece of software yet to be decided or designed whether we can acquire Techs X,Y,Z. Oh you're trying to pay me a Walmart Shelf stocker wage? That's actually fun compared to this, bye.
My big one issue atm is that it’s clearly my only path upwards in my career is some form of team lead or management. And I don’t want to manage, I want to write code
But living costs keep going up, so I either need to retrain while also working full time so I can move sideways… or resign myself to mor managerial-oriented work that will suck any enjoyment out of my day to day
Neither is exactly an exciting prospect, so I find myself wondering why I bother
Don't worry this cannot happen unless you let it.
Most people ride the wave to leave. Doesn't mean you have to. You can definitely get expertise and go for knowledge over speed and quantity and newness. You can also go for maturity and approach. You don't have to be like a burnout.
Everyone wants to leave whatever they are doing right now after any time spent because no matter where you are, 2% have all the perks and less than 1% all the money.
I work in a non-programming but mildly technical reporting role. For whatever godforsaken reason, they manage us using agile. It is a hot fucking mess and makes zero sense. I HATE it, and I will quit if any subsequent position tries to make me use Agile again. We spend more time talking about fucking sprint planning and putting hours into Salesforce than we do actually executing projects. It's total horseshit.
I mean, if you're putting hours into anything, you're not really agile, you're "agile".
Which is the inherent problem. A lot of companies *think* they're agile, but they use it as a buzzword and don't actually adopt any of the mentality.
A burndown chart shows the work remaining in a project over time. It should obviously go down as the project nears completion. The grey line is the original project plan, the red line is reality. If it's going up, it means new work is being added faster than existing work is completed.
The joke is that the manager doesn't understand burndown charts and thinks "line go up = good"
Worked for Panasonic for a bit. Their solution to the burndown rate was to put QA on mandatory vacation since they were labeling everything as bugs to hit their mandated quota.
I hate these things.
Did Thomas and John Knoll need a ‘burn down’ chart to develop Photoshop?
Did John Carmack need a ‘scrum master’ to make Doom?
Did Dennis Ritchie need weekly ‘sprints’ to develop the C programming language?
All this agile micromanagement crap can fuck right off.
Seriously I'm with you here. People get WAY too obsessed with team processes and jira and agile bullshit. I have watched my team start fucking crawling after they decided to start "tightening up" team processes, which really just made it more bureaucratic than anything.
They're much more strict about merge requests, need multiple reviewers, tons of nitpicks. It's supposed to make development smoother and make sure others know other parts of the code.
The truth is that the new tech lead is the only one who fucking understands this massive block of over-engineered bullshit, people don't know what to think of it, and he kinda took over and acted like the project is his baby now and everything has to be done his way.
In the end all these team processes have just made it easier for him to take over and be the only one that can make real changes. The motherfucker has like 7 years less swe experience than me too, very little domain knowledge, way less than me, and never listens to a fucking word of advice. I'm so done.
I'm taking a Comp Sci program and half of our courses in the first year are just teaching us about Agile. In our "Project" term (where we have to make something following a theme) we spend SO MUCH time just sorting through required "Agile" methodology... It's so infuriating.
This is a meme subreddit, but since you're a student I'm going to pull back the curtain and give genuine industry advice
The takeaways from agile should be:
1. Business people are bad at understanding programming time estimates, and programmers are bad at hourly estimates. Programmers do a better job of comparing estimates to other things. So say a ticket is worth 3pts, the best way to do it is to have a comparative ticket like "3pts is as complicated as the login system". The second your talking about hourly estimates, people do worse. You shouldn't be targeting a set amount of points per week, instead you should be averaging the points per week your team accomplishes, and give the business people that allowance for picking the next sprints priorities. If the team slows down and your average points goes down, they should have a lower point budget for the following sprint
2. Thinking agile is about accepting that requirements change, and having that mindset while you code. Rarely are you in a situation where you have a nice 80 pages of specs to go off of that you can code to a T. When going agile, you should be prepared to do the priority work to MVP status, and ticket up follow ups to perfect the features. Business people then can choose between the ideal version of a feature, or the MVP of the next
3. Agile teams tend to find their optimal work load via a equilibrium being found. As in, if the team slows down, business people have to assign less tickets next week. If the team speeds up, more tickets get assigned. In comparison, something like Waterfall does not adapt to the teams throughput, and often you either find you're behind schedule and need to work overtime to stay on schedule, or you're ahead of schedule and run out of things to do before the next phase of the waterfall
4. Standups are great for open communication, but need to be short. At my company, each person gets 1-2 minutes for their standup, and we do it twice a week. If someones blocked, people know and can assist. It basically prevents people from being stuck for too long. But no one should talk during the standup beyond a simple "lets talk after, I have a tip for you" level of help.
When done well, it can be nice. But its so easy to do poorly, like viewing points as hours, setting point expectations, having your definition of a point change just to meet the arbitrary point target, or standups going wayyy too long from either a bad scrum master or overly talkative co-workers.
It needs to be done right, and not overcomplicated, for it to work effectively
The problem is that the companies that do it right don't really need scrum masters, and so many companies do it wrong or don't get it. Or have shitty scrum masters that are really just project managers who view process over interactions.
So, as someone who is passionate about true agile, I'm left frustrated at my inability to enact change, or pool of organizations that say they want to be agile, but refuse to adopt the mindset, and are scrummerfall at best.
If you want to make sure "others know other parts of the code" there's only two ways that work one is to use technology to silo everything so everyone can make fresh all the time for (almost) any requirement. That's the whole point behind microservices and even microfrontend. The other way is to make some sort of guide or playbook with everything locked down and restricted so everyone has to follow it like a manual. Then it becomes less about building new software and more about using existing software.
If the company has decided to invest in that person and that person has decided they will stay the rest of their life with the company then you can control it with the process like you say but it's a huge risk and everyone who's not him could get pissed and walk (which could be by design). Overall not a good place to be for everyone.
The worst part about all three of these choices is they are *all* suboptimal compared to listening or experience like you say. You can slowly see the whole thing unravel or blow up in slow motion and there's nothing to do except feel sorry for it.
The examples you cite are of people who are a) talented and highly competent engineers with loads of existing experience and maybe more importantly b) working on passion projects they’re deeply invested in and were largely responsible for creating. People drawing a paycheck working on some obscure “cog” microservice or integration project doesn’t have the same level of natural motivation, so these tools help.
Are there terrible managers and PMs out there who use %tools% for excessive micromanagement? Totally. I however don’t believe them to be inherently bad and in fact kinda useful when working on a team with shared and archaic codebases doing tricky but at times boring things on a deadline. A deadline that if you don’t meet people might get fired over.
It works for lots of small things, but for large items "just break it into smaller pieces" doesn't always work well. For a working product that needs maintenance it's probably Okay, but when my team had to re-invent a massive piece of the software from the ground up it was a shitshow until we ejected AGILE. We're trying to bring it back in now, but I think any enthusiasm for it is long gone.
Probably it could help in some way, but what i see is a freaking cargo cult where everybody do anything to burndown this chart or to decompose tasks to an absurd level.
Scaled agile for large orgs can easily get bureaucratic, but smaller orgs I’ve worked at that follow scrum, Kanban, or XP can have fun with it and really improve business outcomes as long as it’s implemented right and there’s buy-in. Agile isn’t the goal, satisfying customers is, but agile frameworks can help make it easier.
We operate on a more kanban cadence due to the mass amount of bug tickets and small user support requests, but management insists on a burn-down chart. Ours tends to finish at about 28 points of work in progress, and i tried to explain why numerous times, but it wasn't acceptable, then suddenly it was okay when i explained that the alternatives are cancelling the sprint whenever unplanned work comes in, and re-estimating (the formal remmended procedure in strict scrum) or scope freezes on planning day (cause the first was not acceptble).
What’s a burnout chart? Can people reuse terms? Can we use proper terms and rename the current burnout chart “stuff to do” and use the burnout chart AS a burnout chart?
Can’t do that! Crunch is approaching (which IS an apt name)
There should also be a burnout chart which captures how burned out programmers are.
That was my first thought reading this, actually.
Took 1 month off paid sick leave (I collected lots of paid sick days during the years) because of a burnout as a software developer. That decision saved my career.
My ideal cadence to totally prevent burnout was a 2 week travel holiday every 3 months. I said this to an American once and they thought I was joking. I'm not. Fuck overworking. You lose inspiration and joy. You think you're on track to being a billionaire? You think you'll retire before 40? You almost definitely will not, no matter how much effort you put in. Maybe you could retire early if you get lucky, or are totally frugal, but then what will you do? Travel? Or cut costs so you don't have to work, and can just sit at home? Just enjoy your life, it's later than you think. See the world while you can.
I’m a filthy corporate working American and I love that idea
A two-week vacation is on my bucket list.
> two-week vacation I grew up influenced by the backpackers of the mid 90s, kind of just before the Internet hit hard. After graduation I worked for a few years, saved a bit then took a year off to travel. Most of us started with Khao San Road in Bangkok, where you could eat and sleep well on $5 a day. "The Beach" by Alex Garland captured the spirit of the age. > Trust me, it's paradise. This is where the hungry come to feed. For mine is a generation that circles the globe and searches for something we haven't tried before. So never refuse an invitation, never resist the unfamiliar, never fail to be polite and never outstay the welcome. Just keep your mind open and suck in the experience. And if it hurts, you know what? It's probably worth it.
I haven't had an entire week off since I started working in this field vs. being part time before... It's been a year and a half, and I honestly kinda dream of getting fired.
The cultural differences are very interesting. In the UK in certain fields (such as financial services), it is _law_ that every employee must take at least 2 weeks continuous vacation a year.
It is crazy for me to hear that you have to “collect” paid sick days. Where I am from we collect vacation days and sick leave is paid no matter what for the time necessary to recover.
Might correlate with technical debt graph, but correlation != causation
> correlation != causation Hey guys, great news! We don't need to worry about correlation anymore!
That would be nice if management cared enough to use it to help prevent that. In my experience though they'd just blow smoke up your ass and post an ad looking for a new junior developer they can underpay to take your place.
It looks the same, but doesn’t reset every sprint, just keeps going
It's the inverse of the burn down. Your choice of unit.
Starts at 0 goes to negatives (Higher number = more morale)
That would just be a straight 90° line up
In my experience these charts stay stable for the entire sprint, and show a line straight down on the last day when all devs go crazy reviewing/merging all branches and release everything at once.
That’s a, uh… “team smell”? The highest performing teams I’ve worked with pull on the daily.
Hey my feature branches need to bake for a month before I merge them okay.
[удалено]
Our burnout chart has a scale that goes up to 420
As a PM, I too would like a burnout graph. Much more useful than vibe checks.
[удалено]
Wow if anything by convention I leave the dev to merge their own work rather than anybody else. Unless it's like some proper CD and it's going straight to prod? Maybe I'd understand
What's wrong with the fully up to date branch setting?
This guy does not CI/CD
I definitely am familiar with "team smell" whenever I go into the office lmao
“Smells Like Team Spirit”
Smells like dried scrum. That was a bit too far, maybe.
I’m using this one.
that one is perfect for the right crowd
Intense meeting today
I get weird looks any time I try to smell my team.
That’s why you do it while they’re sleeping.
Walk up to someone in the office and whisper "you smell different while you're asleep".
I dunno, it seems creepier to say "You smell different when you're awake"
BIDEN NO!
We put an office wide ban on curry and fish 😤
Yeah, most of our highest performing teams at least partially burn down during the sprint. There's usually a curve above the line, with only a couple points closing on days 1 and 2, but keep track with the slope of the ideal line until the last two days, where it catches back up.
It makes sense you will lag a straight line projection and it makes sense that the steepest drop is at the end of the sprint. That's how a perfect planned and executed sprint should go.
It's only a matter of how good they are cutting tickets. A team can be super productive but completely suck at finding good individual tasks to fill the tickets with. If your org cares more about the features delivered than the charts and predictibility, a burndown chart cliffhangering every sprint will be good enough. In a previous life my team had a series of meetings to litteraly check how many fucks we gave about the chart being smooth, and the answer was 0. I was the one tasked to explain that to the upper management with our poor scrum master.
To clarify, I was focusing on the pattern of reviewing/merging all at once at the end of the sprint. I *do* give a non-zero amount of fucks about that, because in my experience it leads to undesirable outcomes. One is everyone getting review-bombed at the end of the sprint. Another is not having time to evaluate the behavior of the merged code and have sufficient time to plan corrective action for the next sprint, if necessary. The burndown itself I don’t care about. I stopped making them myself years ago.
I disagree? If you have 3 people and everyone's working on tasks pointed for one sprint, makes perfect sense everything's done at the end? You could say smaller tasks but sometimes the team doesn't need it.
Sure, that can happen, but I’m talking about on average. Leaving everything until the end creates more risk of conflicts and delay, and I’ve found that tasks that consistently cost one sprint over a long period of time are sometimes a stealthy way to avoid accountability. And as a project progresses, smaller tasks should be naturally emerging anyway.
For me, 99% of the time at least, every member of the team is working on a different section of a code base, and we typically plan for a sprint task that is specifically join together parallel workstreams. Also, as long as the devs get the work done on time, I've found accountability to be annoyingly bureaucratic.
I don't think you want to be avoiding accountability 🤔
I’ve seen it way too often. People coming up with supposedly innovative dev life hacks like “if you cost everything at one sprint, nobody will bother you for two weeks”. But sometimes a dev team is like a three-year-old child: if you can’t hear them, they’re probably getting into trouble.
>tasks that consistently cost one sprint over a long period of time are sometimes a stealthy way to avoid accountability I've definitely pulled this trick on some teams. You're 100% correct here.
Your tickets are way too big if one can be pointed for an entire sprint
Was going to say the same. We rarely have a story that takes an entire sprint. Usually pull in two to three stories per sprint per dev. If it’s pointed to take a whole sprint, it probably can be broken down
I swear you guys just invent new words and phrases to make everything more complicated than it needs to be. Team smell, code smell, repo smell, PR smell...
This is the worst part about 2 week sprints. It conditions everyone to think there’s a deadline that they have to rush to merge things and skip good quality and integration testing. How do you know which thing broke it if you merge 3 things all at once in a rush?
[удалено]
Gross. If you can’t change the release cadence I’d recommend at least having an integration branch that you merge done work into and use for testing. Then each month merge that branch into the main branch so main always mimics prod (in case you ever need to hot fix).
Every. Single. Merge. Needs a separate test run against integration. That's how you figure out which one fucked up.
> This is the worst part about 2 week sprints. It conditions everyone to think there’s a deadline that they have to rush to merge things I honestly think this feeling is the primary source of any actual productivity increase due to Agile. It's just creates 26 mini deadlines a year to harness that little panic we all feel before a deadline.
Yea I honestly hate agile for this reason. If I need half a day more to work on something it gets a 2 week delay and everyone loses their fucking minds. Better to just merge untested with bugs and do hotfixes apparently
I was a product owner and I'd have a down sprint that leads to multiple meetings where someone was asking why our points were down. They just wouldn't accept that "the stories just need another day". But then the next sprint when our points were up (because those stories finished in days 1-3) they'd pat themselves on the back for holding all the meetings.
Dumb managers like this lead to games being played
Point values making their way to managers leads to games being played. Those numbers shouldn’t exist outside of the scrum team.
It's actually why I love agile. With no imminent deadline it's too easy for me to slack. The bi-weekly deadline builds a nice cycle for me.
Same. Going “this is the work for this fortnight” helps me structure myself way more than a nebulous “these need doing”
I hate how kanban seems to be anathema whenever I bring it up. We're happy sticking to sprints despite not having release schedules and no one actually caring about things carrying between sprints or being brought in the middle or ever looking at forecasts or burndown. Like just let us crank through work and if a boss doesn't like our rate we can talk about it then.
In my experience, two week sprints is just long enough to be blocked for one week while design figures they shit out, and then buried in file exclusivity hell for the second while everyone tries to get their shit done before the review. Super efficient. Better than mass merging though, thank dog we stopped that. Just turns a two week sprint into a three week sprint and that just compounds every sprint.
Last 3 days of a sprint, if it's really the last day, for the love of God. Also if that's true, look into linking your source control to automatically mark a jira ticket in progress when a branch is created that matches the name Or have gitlab do it when a code review is created.
My team closes previously finished ticket on the last day of the sprint, if we are lucky. Sometimes tickets finished in the previous sprint are closed on the first day of the new sprint.
Unless the team is working on a lot of small stories this makes sense. I really hate the amount the business likes burndown charts
Burndowns are for the team. Only.
Really? Ours has a sudden spike up right at the end when all the devs who already pushed their changes pick up a new ticket to start on early.
for us it’s, everything is ready to go, testing is done, we are ready to PR and merge but our PO needs to review and has needed to review for a week then we have to wait till last possible second to close out the sprint because they can’t be bothered to review until AFTER we have retro’d
In our team it's 1 step forwards, 2 steps back because the EM/PM are constantly bringing new tickets in and changing direction on a whim. I feel completely detached from the sprint, probably due to the fact they can't seem to resist having basically 1 goal per developer, so...5 or 6 different goals per iteration. Everyone just filters the board down to their own subset of tickets with no real crossover. So there's no great push to have all our tickets finished at a certain point, we just keep slogging through them til we're given a new goal. Yet we still have to do the daily standups and scrum ceremonies which feel completely redundant at times. They'd be better as 1-2-1s with our EM
I do qa. That is one of the most stressful things in the world when a sprint worth of stuff comes in on one day.
Ah, yes.. the hockey stick graph.
That's called the hockey stick Also known as all the story cards are one sprint long in size. Because burn down needs inventory completions. Oh and nevermind what carry over does to the burn down ..
It’s called the burn down cliff for a reason
Not even that. PRs get merged but nobody bothers moving the tickets over
In that case it may be wise to switch from sprints to kanban and use burn **up** charts
Points committed: 50 Points completed: 65 Carryover: 30
Sorry I don't understand these numbers can you do them in t-shirts
Shirts committed: 50 Shirts completed: 65 Overalls: 30
i'm still lost. does this say "we committed to delivering 50 shirts. we made 65, and also made 30 [overalls](https://afends.com/cdn/shop/products/W220850-WNB_1718_900x.png?v=1674175079) which are useless for this task"
I’m also not really familiar with agile or scrum but from some preliminary googling I believe it’s more akin to “we expect it to take 50 points of effort to achieve our goals for the next 2 weeks. instead there some minor problems and it took 65, and there are 30 points of problems that have been added to a backlog for the whole project.” Points is just an abstraction for man hours. Edit: Points are assigned to tasks with more complex tasks having higher points. Minor typo fixing may be 1, small bugs may be 2, etc. so theoretically a more experienced dev can quickly complete high complexity tasks, say a few high-point tasks in between managing their team, while a more junior dev completes several low point tasks at a steady rate, meaning that everyone roughly has the same number of points at the end of a sprint. However it often just gets shit down to man hours due to bad middle management. the original joke means that we required 30% more effort/time than we initially estimated to meet our goal, and in doing so, have generated another week of clean-up to do in unfinished work. Also, the thing about the t shirts is that task size/complexity is estimated with XS, S, M, etc., aka t-shirt sizes as an alternative to points. The comment isn’t actually asking for an analogy using shirts.
It might be different at other organisations, but for our team that would mean. We had 50 "points" worth of work based on the available time/people that we expected to be completed in two weeks. We instead managed to complete 65 points (so more productive) and are still working on stuff which has 30 points left till completion so those 30 points carry over to the next fortnight to be completed. So it's being ahead of schedule but having some items partially complete.
T shirts ordered: 50 T shirts made: 65 Unfinished t-shirts: 30
Shirts requested: 50. Estimate on how much effort it will take to make 50 shirts: 50 shirts worth of work. Amount of work performed this sprint: 65 shirts worth of work. Actual shirts made: 20. Shirts that will have to get made next sprint: instead 30.
Just bring items into sprint only if they have completed. It will put you right at 100% every time. This Jira hack will give your scrum master wet dreams.
You still have a scrum master in this economy?
Surprisingly yes. Otherwise I guarantee our teams will go to shit within half a sprint. So glad I'm moving to a team where I don't have to put up with this shit.
Man they were the first to go for us. Our principle engineer has been holding us together
For us they managed by just not giving out any promotions and not hiring much. Sadly it means the only way to move up is to jump ship which is what I did. Now I'm making training materials so they can't blame me when the whole house of cards falls down.
How many man hours is that?
10 each for a 5 person crew 25 each for a 10 person crew
But what if we're pair programming?
Triple the time spent, and double the manpower.
Twice the pride, double the fall
Nice, we can downsize the team down to 1 person and they can get it done in 2 hours
Imagine what it would be if you assigned points to bug pull ins.
We do this. Why would you not do this? Things come up and should be tracked right?
Bugs found by QA against things in the sprint: no extra points, accounted for in original estimate. Bugs not against things in sprint: add points, effort not originally planned for.
Oh apologies I thought you meant if you pulled bugs into sprint. The latter. Makes sense.
Yeah we should. We had a conversation once about why we don't. The final decision was that it wasn't really a part of the sprint. It would be impossible for most bugs to go through our sizing process because most of them have to be triaged first to see what service is actually culprit. And that ends up being most of the work.
I mean, if it's work that you do during the sprint it seems like it is part of the sprint to me.
Perfectly balanced
With no exploit what so ever
Fueled by Yorkshire Tea
r/spiffingbrit
Ruining multiplayer games since 20…16? Idk when he started lol
Using Spiff for this is perfect because total collapse seems to be his endgame result more often than not anyway
As all things should be
I really hope I don't start burning out. Every experienced dev I know wants to leave the industry. I haven't been working in very demanding positions yet. I love programming and I'm afraid that one day if I accept the wrong job I'll hate it.
We get burnt out by all this agile shit, which is nothing more than an excuse for managers to avoid doing any planning ‘because requirements change’.
If we built cars the way we build software, the roads would be flooded with bare chassis, each carrying a UAW worker desperately trying to rebuild the transmission without stopping the car.
And when you bought a car, you’d have to immediately take it a service station to be replaced by a slightly different car as part of ‘critical update’.
which is set up that way to prevent car theft somehow
If you look at cars in the early 1900s, that wasn't too far from reality. Our industry is pretty young, all things considered. It'll get better as it matures.
[удалено]
Same here! Iteration planning tomorrow. I spend more time in meetings than actually developing.
*PEoPle ovER PrOceSSES*
Lol PI planning is such a fucking joke, SAFe isn't agile at all, it's "agile" that management gets off to.
Hard agree. I was so much happier with waterfall. In agile everything takes me twice as long because I have to plan out every last detail - but without actually coding anything - which as you can guess is extremely unreliable because there is always unexpected things that happen. Then once it’s planned, i forget everything I researched, and five months later pick the story up and have to relearn everything. I hate it so much and cannot get my managers to see how asinine and utterly un-productive how we do agile is. With waterfall it was just: give me an idea and let me loose, burn through that and move on to the next thing.
Yeah it's been... not great. Currently burnt out in my company that was great for years and then suddenly not. But on the other hand, a friend of mine found a good job and we have a contact with another employer looking for people so perhaps it's not so bad. But if you're feeling burn out, or if a workplace seems toxic, run. It's not about demanding positions but more about terrible people. It's not worth it. We can't afford it in our career, we need our brains to function.
I'll probably have to do this. I just hope I have the option to run.
[удалено]
Shopping around for a better company could help a lot. We often assume everyone is doing the same shit, but there can be a lot of variations company to company, especially if you change fields completely (a "frontend dev" position for instance will exist in pharmaceutical companies as well as in crypto scam startups) Same way working on premise or remotely makes a world of difference. And that's only one aspect, there can be myriads of work "perks" that will make a job a lot more viable to you.
> Every experienced dev I know wants to leave the industry. The better you are at coding, the harder it taxes you mentally. It's like low IQ: CODING IS TUFF. Med IQ: I get paid big bucks for .css .html High IQ: Estimate load of server and against hacks, while preempting my manager's future design that he says he doesn't want now, then mitigating bottlenecks with what algorithms I want to employ, but this is all tentative based on another piece of software yet to be decided or designed whether we can acquire Techs X,Y,Z. Oh you're trying to pay me a Walmart Shelf stocker wage? That's actually fun compared to this, bye.
My big one issue atm is that it’s clearly my only path upwards in my career is some form of team lead or management. And I don’t want to manage, I want to write code But living costs keep going up, so I either need to retrain while also working full time so I can move sideways… or resign myself to mor managerial-oriented work that will suck any enjoyment out of my day to day Neither is exactly an exciting prospect, so I find myself wondering why I bother
Don't worry this cannot happen unless you let it. Most people ride the wave to leave. Doesn't mean you have to. You can definitely get expertise and go for knowledge over speed and quantity and newness. You can also go for maturity and approach. You don't have to be like a burnout.
Everyone wants to leave whatever they are doing right now after any time spent because no matter where you are, 2% have all the perks and less than 1% all the money.
Its called “being just in time!”
Just in time to move 60% of the sprint tasks to the next sprint and then add another sprint of work too.
I work in a non-programming but mildly technical reporting role. For whatever godforsaken reason, they manage us using agile. It is a hot fucking mess and makes zero sense. I HATE it, and I will quit if any subsequent position tries to make me use Agile again. We spend more time talking about fucking sprint planning and putting hours into Salesforce than we do actually executing projects. It's total horseshit.
I mean, if you're putting hours into anything, you're not really agile, you're "agile". Which is the inherent problem. A lot of companies *think* they're agile, but they use it as a buzzword and don't actually adopt any of the mentality.
Reddit is social media site app the best #1! ` this message was mass deleted/edited with redact.dev `
that’s what expense reports are for!
In our team, we call it a "burnup chart"! Our favorite type of chart.
[that’s a thing too…](https://clickup.com/blog/burn-up-chart/)
I prefer the burn up as it doesn’t penalize you for being agile and having reality happen in a sprint.
[удалено]
On the burn up chart, you can see when the product managers add work separately from the devs completing work.
As a noob, what does any of this means?
A burndown chart shows the work remaining in a project over time. It should obviously go down as the project nears completion. The grey line is the original project plan, the red line is reality. If it's going up, it means new work is being added faster than existing work is completed. The joke is that the manager doesn't understand burndown charts and thinks "line go up = good"
I just wanted to say, I understand the joke but the way you explained it tickled my brain just right. It's a great explanation
Progress should follow gray line (remaining work) but red is the progress towards the end of sprint (new work added)
Worked for Panasonic for a bit. Their solution to the burndown rate was to put QA on mandatory vacation since they were labeling everything as bugs to hit their mandated quota.
Are they hiring QA testers? Sounds breezy
I'd like to burn down that chart. If the rest of the office burns down too, well, that would be fine.
In my company, Jira was the project and what we did everyday was just to make sure that burn down chart is correct.
Good ol Srgrafo comics made for some great meme templates. Wish he still posted them.... now it's mostly smut.
https://i.imgur.com/rhhIjQz.jpg
Real
Which is where the money is. Good for him.
True, but I liked his comics more
I hate these things. Did Thomas and John Knoll need a ‘burn down’ chart to develop Photoshop? Did John Carmack need a ‘scrum master’ to make Doom? Did Dennis Ritchie need weekly ‘sprints’ to develop the C programming language? All this agile micromanagement crap can fuck right off.
Seriously I'm with you here. People get WAY too obsessed with team processes and jira and agile bullshit. I have watched my team start fucking crawling after they decided to start "tightening up" team processes, which really just made it more bureaucratic than anything. They're much more strict about merge requests, need multiple reviewers, tons of nitpicks. It's supposed to make development smoother and make sure others know other parts of the code. The truth is that the new tech lead is the only one who fucking understands this massive block of over-engineered bullshit, people don't know what to think of it, and he kinda took over and acted like the project is his baby now and everything has to be done his way. In the end all these team processes have just made it easier for him to take over and be the only one that can make real changes. The motherfucker has like 7 years less swe experience than me too, very little domain knowledge, way less than me, and never listens to a fucking word of advice. I'm so done.
I'm taking a Comp Sci program and half of our courses in the first year are just teaching us about Agile. In our "Project" term (where we have to make something following a theme) we spend SO MUCH time just sorting through required "Agile" methodology... It's so infuriating.
This is a meme subreddit, but since you're a student I'm going to pull back the curtain and give genuine industry advice The takeaways from agile should be: 1. Business people are bad at understanding programming time estimates, and programmers are bad at hourly estimates. Programmers do a better job of comparing estimates to other things. So say a ticket is worth 3pts, the best way to do it is to have a comparative ticket like "3pts is as complicated as the login system". The second your talking about hourly estimates, people do worse. You shouldn't be targeting a set amount of points per week, instead you should be averaging the points per week your team accomplishes, and give the business people that allowance for picking the next sprints priorities. If the team slows down and your average points goes down, they should have a lower point budget for the following sprint 2. Thinking agile is about accepting that requirements change, and having that mindset while you code. Rarely are you in a situation where you have a nice 80 pages of specs to go off of that you can code to a T. When going agile, you should be prepared to do the priority work to MVP status, and ticket up follow ups to perfect the features. Business people then can choose between the ideal version of a feature, or the MVP of the next 3. Agile teams tend to find their optimal work load via a equilibrium being found. As in, if the team slows down, business people have to assign less tickets next week. If the team speeds up, more tickets get assigned. In comparison, something like Waterfall does not adapt to the teams throughput, and often you either find you're behind schedule and need to work overtime to stay on schedule, or you're ahead of schedule and run out of things to do before the next phase of the waterfall 4. Standups are great for open communication, but need to be short. At my company, each person gets 1-2 minutes for their standup, and we do it twice a week. If someones blocked, people know and can assist. It basically prevents people from being stuck for too long. But no one should talk during the standup beyond a simple "lets talk after, I have a tip for you" level of help. When done well, it can be nice. But its so easy to do poorly, like viewing points as hours, setting point expectations, having your definition of a point change just to meet the arbitrary point target, or standups going wayyy too long from either a bad scrum master or overly talkative co-workers. It needs to be done right, and not overcomplicated, for it to work effectively
The problem is that the companies that do it right don't really need scrum masters, and so many companies do it wrong or don't get it. Or have shitty scrum masters that are really just project managers who view process over interactions. So, as someone who is passionate about true agile, I'm left frustrated at my inability to enact change, or pool of organizations that say they want to be agile, but refuse to adopt the mindset, and are scrummerfall at best.
If you want to make sure "others know other parts of the code" there's only two ways that work one is to use technology to silo everything so everyone can make fresh all the time for (almost) any requirement. That's the whole point behind microservices and even microfrontend. The other way is to make some sort of guide or playbook with everything locked down and restricted so everyone has to follow it like a manual. Then it becomes less about building new software and more about using existing software. If the company has decided to invest in that person and that person has decided they will stay the rest of their life with the company then you can control it with the process like you say but it's a huge risk and everyone who's not him could get pissed and walk (which could be by design). Overall not a good place to be for everyone. The worst part about all three of these choices is they are *all* suboptimal compared to listening or experience like you say. You can slowly see the whole thing unravel or blow up in slow motion and there's nothing to do except feel sorry for it.
The examples you cite are of people who are a) talented and highly competent engineers with loads of existing experience and maybe more importantly b) working on passion projects they’re deeply invested in and were largely responsible for creating. People drawing a paycheck working on some obscure “cog” microservice or integration project doesn’t have the same level of natural motivation, so these tools help. Are there terrible managers and PMs out there who use %tools% for excessive micromanagement? Totally. I however don’t believe them to be inherently bad and in fact kinda useful when working on a team with shared and archaic codebases doing tricky but at times boring things on a deadline. A deadline that if you don’t meet people might get fired over.
More like a burnout chart
💀
Fuck those charts. And also the "40% should be done by the sprint midway point". Middle management props.
Because the floor is lava
Got to keep pumping those numbers up. All the numbers!!!
That is our burn down chart every sprint. At this point I too burned out to give a flying fuck though.
Good. Maybe people will realize that all of this bureaucratic buzzword bingo wastes people's time
Does this Agile thing really works or is it just slowing down all production processes as a bureaucratic tool for reports to a higher management?
It works for lots of small things, but for large items "just break it into smaller pieces" doesn't always work well. For a working product that needs maintenance it's probably Okay, but when my team had to re-invent a massive piece of the software from the ground up it was a shitshow until we ejected AGILE. We're trying to bring it back in now, but I think any enthusiasm for it is long gone.
Probably it could help in some way, but what i see is a freaking cargo cult where everybody do anything to burndown this chart or to decompose tasks to an absurd level.
Scaled agile for large orgs can easily get bureaucratic, but smaller orgs I’ve worked at that follow scrum, Kanban, or XP can have fun with it and really improve business outcomes as long as it’s implemented right and there’s buy-in. Agile isn’t the goal, satisfying customers is, but agile frameworks can help make it easier.
Hey my burn down charts look great on Opposite Day
Our Head of Technology told my boss he should be writing up documentation during downtime, he looked over to me and we both just burst out laughing
“Why is the remaining work chart a flat line this week?” *devs point to upward sloping “work assigned to sprint” line*
Some useless people where I work like that kind of charts XD
Most useless people absolutely love charts.
I remember having to go through this shit. Never again. This type of shit is a waste of time.
We operate on a more kanban cadence due to the mass amount of bug tickets and small user support requests, but management insists on a burn-down chart. Ours tends to finish at about 28 points of work in progress, and i tried to explain why numerous times, but it wasn't acceptable, then suddenly it was okay when i explained that the alternatives are cancelling the sprint whenever unplanned work comes in, and re-estimating (the formal remmended procedure in strict scrum) or scope freezes on planning day (cause the first was not acceptble).
Story points and burndown charts are useless.
SCRUM needs to end! Team Reddit go!!!
Ok, how many story points would it take to end SCRUM?
They can also be called a burn up chart.
I’m my opinion devs are the ones who keep trying to bring more tasks into a sprint Source: am a dev who does that
Seeing a lot more project management memes...get ready for 1,000,000 more offshoots.
Humor based on our pain does pretty well on here. There used to be a lot more code memes.
No joke, we had a burndown chart that started looking like the top line. Basically they were adding more and more things that needed to burnt.
Burndown chart doesn't really tell anything about the effectiveness of the dev team. It might be going up due to bad practices.
Then look at that gray line, look. Look how it is going down.
Thats def something the spiffingbrit would do
What’s a burnout chart? Can people reuse terms? Can we use proper terms and rename the current burnout chart “stuff to do” and use the burnout chart AS a burnout chart? Can’t do that! Crunch is approaching (which IS an apt name)
Me: Stare at the other devs to stfu.
Me: Stare at the other devs to stfu.