151–160 of 292 posts
My team insists on sprint deadlines, but no sprint meetings . That's cargo culting.
Whilst this may help with burnout so do the main implementations of agile when done correctly.
Agile done properly is all about quickly getting feedback on the speed of work so the business can correctly plan in accordance to this.
If you're getting burnout doing agile, you're doing agile wrong. Don't do sprints. Have a continuous backlog. Don't do overtime. Don't make estimates. Always do the simplest thing. Only ever do the most important thing, as defined by the stakeholder. I've written and talked about this at great length. The fact people suggest agile gives you burnout reinforces my experience that Scrum is largely misinterpreted and peo…
Also, "always do the simplest thing" is one of those phrases that can be twisted and morphed to support literally anything, which makes the phrase useless. It feels good to hear and say, but the reality is it doesn't help you out of a jam.
Sprints are exactly what you're describing, except with accountability built in. That shouldn't scare people, but it does, and that is what causes burnout. Fixing the fear around accountability is how you fix burnout, not eliminating the thing that your boss can use to justify your job.
Earlier quoted context omitted.
I'm not sure the author is advocating for no developer presence during the planning period. > The first week of each month is spent with project leads and stakeholders defining the upcoming sprint At the very least, I'd suggest that developer leads or engineering managers are stakeholders and therefore involved. They should be liaising with their development team (also stakeholders) during the planning phase. Perhaps…
I agree. I didnt read that as an invitation to take 5 days off every month, therefore advocating 60 additional holidays in a year. I saw it more as an opportunity to catch up on "other stuff". Maybe a tool you wanted to work on to make your work life easier, or leave a little early to wrap up taxes, or do some PoCs etc. to see whether a refactoring idea you have is actually feasible or not.
Earlier quoted context omitted.
The business wants to know how much feature X is going to cost and when they can expect it. They need to know that, because they need to decide if it's worth it in the first place, or because they need to plan follow-up actions for when the feature will be done. If the developer doesn't make estimates, you're just forcing other people to make their own estimates, that they'll hold you to.
> The business wants to know how much feature X is going to cost and when they can expect it. Of course they do. We all want things that are impossible to have. I want to know the AAPL stock price in 6 months. The traditional way to manage this impossibility is that engineering lies about it (they have to lie, because they can't know either), and once people are lying to each other, trust is unlikely to arise. The ag…
Also, avoiding scope creep is paramount.
It works very well for us as a small team of five developers.
Agile is dead. As a subculture the muggles and sociopaths have taken over Agile. I think #NoEstimates is the next cool thing.
I feel like #NoEstimates has been a thing. I think #NoMethodology or #NoProcess is the next cool thing (Some might call it #GSD).
Most of the time, agile fails due to an unwillingness to be flexible. It's either stakeholders or managers with rigid deadlines/demands, or teams that are incapable of adapting their processes to increase productivity.
If you ever want to test your agile setup, ask yourself this: what happens when you finish a sprint and you have time remaining on a task? For me, this is the ultimate test of agility in an organisation, and it's usually where you see the first problem(s).
A lot of people in tech like to complain that consulting firms have ruined agile, but I blame you/us. We've ruined agile because we refuse to be agile, and we ultimately accept a process where we rush into development without adequate planning, or the ability to change course during production.
In all fairness, it's not just developers faults. It's also the fault of managers that implement this "agile" thing we've sold as a rigid process that needs to fit a set of concrete parameters.