Live data from Hacker News

Agile Lite: Agile without all the burnout

github.com

131–140 of 292 posts

Re: Agile Lite: Agile without all the burnout

#131

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…

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.

Another bit of wisdom I got from Kent Beck is that there are three basic controls to every project... schedule, scope, and resources. You can only control two of them. And resources are generally fixed at the beginning of the project(1), so most projects are either scope-bound (we must have all these features), or schedule-bound (we must hit this hard date). If you're feature-bound, estimation failure means you'll be late. If you're schedule-bound, estimation failure means you'll be incomplete.

This can be a very hard pill for the business to swallow. They want it all, and they want a predictable schedule. But Beck's triangle is akin to thermodynamics. Do you want the volume, or the pressure, or the temperature? When fixing devops-related and agile-related process problems, I often hear "But we're a schedule-driven company!" when they have a scope-driven problem like process transformation.

1. As The Mythical Man-Month pointed out almost 50 years ago, adding resources to a late project makes it even later.

Re: Agile Lite: Agile without all the burnout

#132

One of my biggest pet peeves is the pointlessness of standups. I have never worked anywhere where they did not immediately become a status update, which is (in theory) what the board is for. Why is the board not up to date? Because we just talked about all of that an hour ago and doing all of that over again is infuriating. What is the status of ticket x? Either wait until the next day’s status report/standup or star…

We do our standups in VR in Hubs (https://hubs.mozilla.com) so it serves as a great integration test :)

Re: Agile Lite: Agile without all the burnout

#133
post #88

Earlier quoted context omitted.

The point of standups is to help teams to learn to communicate and to steer the team to a habit of working on the most important things. Once that's a behavior, standups can be less frequent or dropped all together. This is especially useful for new teams or when the team changes.

No, the point of standups is to go around in a circle and make sure that everyone has everything they need to keep working (that there are no “blockers” in the parlance of agile). That’s why they’re called stand ups - you’re supposed to stand so that everyone gets annoyed if it takes more than a handful of minutes. If you’re discussing what you did yesterday, what you’re going to do today, when you think x is going t…

But if something is blocking you, you should not wait for the standup to bring it up, what a strange way of working is that. Just ask someone who can help you. That's one thing that works well in my company.

Still people also want standups, basically to hear what others are doing and feel like a team.

Re: Agile Lite: Agile without all the burnout

#135
post #128

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.

Theoretically. Practicaly they don't do that kind of planning and high estimate leads to pressure to lower it down (or making you feel ashamed for it being to big etc), which most developers will do, because developers tend to sux at negotiation.

That's where it breaks down. If you strip the Scrum-Industrial Complex nonsense away, one of the basic concepts of Scrum planning is that the business gets to define the stories, and the developers get to assign the points (or whatever mechanism is being used to estimate). Business sets the scope, technical sets the resource requirements.

If developers can't hold the line on estimates, they're toast. Nothing will ever get done on time or under budget, because the organization is focused on basic dishonesty about what work can actually get done. Which means people are being rewarded for the wrong things. Measure by estimate accuracy rather than promises made, and you'll see a lot more honesty in estimation.

Re: Agile Lite: Agile without all the burnout

#136

Earlier quoted context omitted.

Indeed, and the Scrum-Industrial Complex has vested interests in codifying a certain format that it can sell.

not heard that term before (Scrum Industrial Complex) but it's pretty good, going to use it from now on :)

I just used it in another comment. :)

Re: Agile Lite: Agile without all the burnout

#139

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…

And velocity should be an internal team measurement not shared with outsiders because (Goodhart's Law) when management says "Let's increase our velocity" and the team and developers are GRADED/PROMOTED on their velocity then you'll get point/estimate inflation which will hurt you more in the long run since the inflated estimates actually now allow for the work to fill the time (Parkinson's law).

Re: Agile Lite: Agile without all the burnout

#140

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.

Yes, this is more along the lines of what I'm talking about. I'm advocating common sense over religious adherence. Do what works for you.

I am saying there's a lot of burnout in the tech industry and it's at least partly a process problem.

Maybe it's just me and I'm "doing it wrong", but I think it speaks to the issue that the suggestion of "taking it easy a week out of every month" is met with cries of "This is madness! It will never work!"

Post reply on HN