Live data from Hacker News

Agile Lite: Agile without all the burnout

github.com

141–150 of 292 posts

Re: Agile Lite: Agile without all the burnout

#141
What we do where i'm at is the perfect amount of "agile" for me. Granted we're a small team, but it's worked VERY well for 3 years now.

What we do:

- Standup twice a week, never lasts more than 15 min

- 1 hour "planning" meeting each sprint where we discuss new stories for the upcoming sprint and assign them points

- 2 x 2-week sprints (1 release a month containing work from both sprints), this gives us flexibility for unexpected problems if we have to cut stuff out of the release or add features missed during planning

- We do not track hours

- We track velocity by points, but it's only a guide for the next sprint and not taken as do or die

- Developers freely choose what they want to work on, but they must go down by priority on the sprint's items

- When a dev is finished with their story, they pickup the next item in the sprint

- If all sprint items are taken/done, we grab from the next sprint assignments. If those are all done, we have another planning meeting or work on tech debt in the backlog

EDIT: Formatting, words

Re: Agile Lite: Agile without all the burnout

#144

Earlier quoted context omitted.

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.

And so we circle back around to the pointlessness of all meetings.

If it is as-needed to hash out an idea or determine the best way to fix something or to scope and point... that’s fine.

If it’s every day, twice a week, every MWF, etc. there is absolutely no way it’s actually necessary every one of those times and everyone is going to eventually defer to human nature and wait for the meeting to bring things up.

Part of that is natural and well intentioned - I’ve got the meeting in an hour, I won’t bother them yet, I’ll wait for it.

Part of that is natural and self-defeatist - if we already discussed everything then what will we discuss in the meeting?

The actual solution is to get rid of the meeting. The real solution is to just wait and discuss it all there. It’s like why I don’t call my mother the day before I go over to have dinner with her - we’re going to cover it all in the phone call and it’s going to be awkward silence while we eat.

And finally, if a standup is the best way you’ve found to make everyone feel like a team... there is no hope. That’s a really, really crappy way to make people feel included. Though that is what passes for team building at more places than not...

Re: Agile Lite: Agile without all the burnout

#145

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).

Re: Agile Lite: Agile without all the burnout

#146
I don't think this is a viable solution to Agile. I think the spirit is fine in that its painfully obvious that Agile has become little more then a buzzword sold by consultants, and almost all implementations of it look a lot like mini-waterfall then anything truly agile, but this misses the biggest faults in current agile implementations

1. It still puts process over people, you can never have an agile workflow that has ordained gatekeepers, in this case the separation of "project leads and stakeholders" from "developers" is going to lead to the same class of sprint problems you have in any implementation today. The people you need are the one's doing the work ( every single one of them, from the most junior to the most senior ) to sit down with the people

2. The lack of agility in scoping work in sprint means this is just a three week waterfall rather then a two week waterfall. You can't call any process agile that doesn't allow you to change direction at any point in time, hence the word agile. In traditional agile this is supposed to be a terminated sprint, but for reasons this is almost never done.

3. The baked in rest week will just make people unhappy. Teams are at their best when they are working together and making progress, that rest week will foment dissent within the team, especially since the "stakeholders" still have tasking to be done that week.

Re: Agile Lite: Agile without all the burnout

#147

I've been through the wringer it sounds like this team is going through more than once. You have to teach your stakeholders and managers how to be agile, if they aren't willing to actually get that, it always turns into a death march eventually.

And agility requires slack (unscheduled capacity) which means less than optimal "resource" efficiency. Stakeholders and managers need to understand that if they what to be able to handle changing plans and requirements then their time can't be fully booked. Problem is then many expect the developers to just work more hours leading to burnout and turnover. I really think developers should push for hourly exempt status (the only class of workers in the US that are allowed hourly exempt status) instead of salary exempt status. With hourly exempt, while you won't be paid time and a half, at least you'll be paid straight time for anything over 40 hours a week.

Re: Agile Lite: Agile without all the burnout

#148

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…

>Don't do overtime. Don't make estimates.

Said another way, estimates are not promises. Don't crunch to meet them. I think it should be phrased as "no deadlines".

The whole sprint structure is so you're constantly adjusting your plans and estimations at some predictable time. Without a sprint you can end up with randomization.

Re: Agile Lite: Agile without all the burnout

#149
This seems like more or less basically what I've been doing.

(Not with "one week off" though, that sounds nice but neither necessary or realistic).

It works out okay. As with everything else, the competencies/interests/capacities of the people, especially "product owner", make a big difference.

Re: Agile Lite: Agile without all the burnout

#150
> most communication happens through the issue tracking system (which is faster to work with than e-mail)

Written by someone who hasn't communicated this way (especially remotely). This is really just a way to mark your ticket as blocked, and fuck off for the rest of the day because the person who needs to respond won't get to it until they're out of "flow" or whatever (isn't maker time great?).

> Once a sprint has begun, Issues may not be added to the sprint

So the company is just supposed to eat the extra time in a sprint if there happens to be that extra time? No fucking way will a company opt into that, especially combined with the monthly beach week time (AND any reasonable absences during the sprint itself).

This is a pipe dream. Sorry, but asking a company to treat you like this is asking a company to basically pay you for doing nothing. Ridiculous.

Post reply on HN