Live data from Hacker News

Agile Lite: Agile without all the burnout

github.com

261–270 of 292 posts

Re: Agile Lite: Agile without all the burnout

#261

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.

> They need to know that, because they need to decide if it's worth it in the first place If this is the case, they should also be able to state the threshold above which the item would be "not worth it", and I would assume this is significantly easier to figure out than it takes developers to build a decent estimate. From a developer point-of-view, the first high-level estimate is then much, much simpler: "Is it goi…

Then the project sponsors would have to estimate value at a granular level.

Which is essentially just as inconvenient for the business to estimate as schedule is for developers.

They are more important in the organisation, so they don't, and instead insist on perfect estimates from the dev team.

Re: Agile Lite: Agile without all the burnout

#262

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 Product Owner prioritises the backlog

Note: This would require a _really_ good product owner that does not merely focusses on features, but also on feasibility and 'fitness functions'.

The rest of that article had me cheering all the way.

Re: Agile Lite: Agile without all the burnout

#263

Earlier quoted context omitted.

I know. I wanted to get rid of our standup as it has no real point. The rest of the team wanted to hear what people were doing, so it stayed.

I find a good replacement for a traditional agile standup is a board based one. Rather than going through each person where it feels like you're being put on the spot individually, you go through each card on the board and ask what needs to happen for it to move to the next step. 90% of the time it's going to be one person putting their hand up and saying "I'm working on it" then you move on, and the other 10% of the…

The thing is that we are ~11 people working on ~20 projects (the largest has about 2-5 people working on it at any moment, the smallest is worked on a couple of times per year, all the rest is in between). So without keeping each other informed there is a lot that goes unnoticed just because your work doesn't depend on it.

Going through all tickets would take a lot longer than having an update of all people so I don't think that will be popular, but I like to look at the tickets that aren't assigned to anybody yet at the end of most standups so that we don't lose sight of them.

Re: Agile Lite: Agile without all the burnout

#264

Earlier quoted context omitted.

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.

The point of standup isn't to report status or get unblocked. Even in a large team or for x-team blockage, you can just talk to the PM. The point is to keep social pressure on weak performers. One of the main points of Agile (as implemented) is to push the team to perform. Otherwise natural habits of slack creep in. One or 2 people failing to deliver destroys all the good work of the strong performers. This is the re…

Yes, that sounds about right.

Re: Agile Lite: Agile without all the burnout

#266
An understanding of every comment here shows agile (or any other methodology) in all its "glory"......

People just can't agree on anything is the simple answer. It's how we get round that to get anything done as a group (given the many personality types and their experiences) that matters.

Usually, for something successful to occur (scope, time, budget are met), it comes down to a knowledgeable leader who understands people. And there's not many of them around.

Re: Agile Lite: Agile without all the burnout

#267

That's a good idea. Consulting firms have really overcomplicated Agile a lot. I've been displeased to meet bloated implementations these last years. My only point is that, at least in the companies I've worked for so far, a practical Agile implementation must provide some device for making a "pressure" over the team to avoid too many items ending up carried to next sprint. Of course there are lots of legitimate situa…

"pressure" aka micro management

Re: Agile Lite: Agile without all the burnout

#268

Earlier quoted context omitted.

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 madn…

Edit: I misread this to mean “all devs take a week off” instead of “a light week in collaboration on some backlog stuff” - that makes total sense.

I also misread the "first week" stuff to mean that you leave the room and take a week off.

Having a light week while this is happening makes sense. It ends up being light anyway while the transitions happen. Apologies for the misread.

As for madness - I was not at all implying the suggestion was madness, and different things work for different teams / projects. I personally find standups are super helpful so I wouldn't want to get rid of them. That regular cadence it creates is very helpful in making sure we all stick our heads up and incorporate what's going on around us. If your teams are doing this already without the regular touch-points, that's awesome, but I find that with most teams that is a learned thing that takes a lot of time, and regular scheduled places to update are important to success.

Re: Agile Lite: Agile without all the burnout

#269

Earlier quoted context omitted.

It says that the sprint planning takes about 45 minutes. What I take that this means, is that there is a backlog with stories and tasks which was created and refined by the dev team. These stories include specifications, estimates and more. So what the project leads actually do, is to decide which of these backlog items will get into the sprint. That's all.

Yep. If everyone’s updating issues in the ITS, it’s easy to plan a sprint. Priorities are mostly already assigned and the sprint planning meeting should be more of a sanity check. Engineers are only out of the loop insofar as they have fewer meetings where they’re sitting around waiting for their turn to speak. If they want to weigh in, they should, and nobody is stopping them.

[deleted]

Re: Agile Lite: Agile without all the burnout

#270
post #3

As a developer, seeing another developer suggest that they just take a vacation and leave the project leads and stakeholders to talk about what should be done in a month is really weird. That will not lead to the absence of a death march - it is a recipe for a death march. Not only will you not have an accurate assessment of the tasks but they will not be ordered correctly, and likely way overscoped for the timeframe…

It says that the sprint planning takes about 45 minutes. What I take that this means, is that there is a backlog with stories and tasks which was created and refined by the dev team. These stories include specifications, estimates and more. So what the project leads actually do, is to decide which of these backlog items will get into the sprint. That's all.

Sure, if this dialog is happening the whole time that makes sense, but burnout also seems like something that would be dealt with using the backlog - make time for exploration, test spikes, learning, etc. If all this work is well defined already and the backlog is owned by the devs, that seems like a solved problem. If, however the devs are actually spending a boatload of time refining stories before planning then sure, take a week off while others talk about it, but that has a bit of a smell to it also in terms of a happy medium.

If the overall message is “slow down sometimes” then I agree 100%.

Post reply on HN