Agile Lite: Agile without all the burnout • Hacker News Board

Re: Agile Lite: Agile without all the burnout

#81

Post by PaulHoule » Thu, Apr 04, 2019, 2:49 PM UTC

Matticus_Rex wrote: post #19

PaulHoule wrote: post #5

The key thing people miss about agile (and project management in general) is that you have to tune the process to the situation. If you look at the PMBOK (Project Management Book Of Knowledge) it is really a comprehensive list of all the things you might have to think about while running a project. All of them are relevant to every project (e.g. hiring, communicating with the public) but some need a lot of attention…

> I worked at a place where we had a timebox of 2 hours for planning but really after that we were nowhere near a realistic plan for the sprint and it would take another 2 or 3 days of knock-down, drag-out meetings that would leave us all exhausted to understand what we had to do. Wow! Sounds like decision-making processes needed tweaking even aside from Agile practice.

We might not have been so exhausted if the process itself was not in the way of makign realistic plans.

Re: Agile Lite: Agile without all the burnout

#82

Post by phillc73 » Thu, Apr 04, 2019, 2:49 PM UTC

sailfast wrote: 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…

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 this sentence is overstated:

> It is an intentionally light week and many people may simply take the time off to paint or surf or whatever.

People should perhaps take SOME time off to relax, but likely not the whole week.

Re: Agile Lite: Agile without all the burnout

#83

Post by matthewmacleod » Thu, Apr 04, 2019, 2:50 PM UTC

RandallBrown wrote: post #59

Scarblac wrote: post #48

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.

Nobody should make estimates. They're always wrong. Do your best to break tasks up so that all tasks are the same size. Then work on tasks. You'll find a stable average of tasks per amount of time and that will let you forecast how long things will take, how much they'll cost, etc. That's how you figure out when things will be done.

Do your best to break tasks up so that all tasks are the same size

That is estimation, in the Scrum sense.

Re: Agile Lite: Agile without all the burnout

#84

Post by jrockway » Thu, Apr 04, 2019, 2:51 PM UTC

sailfast wrote: 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…

Yeah, I kind of agree. If you want 12 weeks of vacation a year, you have to plan spectacularly. I am not sure 2 hours a month is enough.

Re: Agile Lite: Agile without all the burnout

#85

Post by tudelo » Thu, Apr 04, 2019, 2:51 PM UTC

aboutruby wrote: post #12

> Issues may not be added to the sprint I don't see this happening, even if that's a good rule, because issues come up that take higher priority than existing issues.

I don't even think it's a good rule because if something critical/high priority comes up it could be because of planning or it could be because of multiple external forces and or a bug.

Maybe it's a good general workflow but as a hard rule it seems rather silly... but I would love to work somewhere where there wasn't a flipflop on priorities every week or so :)

Re: Agile Lite: Agile without all the burnout

#86

Post by gnome_chomsky » Thu, Apr 04, 2019, 2:51 PM UTC

ryanSrich wrote: post #75

RandallBrown wrote: post #59

Earlier quoted context omitted.

Nobody should make estimates. They're always wrong. Do your best to break tasks up so that all tasks are the same size. Then work on tasks. You'll find a stable average of tasks per amount of time and that will let you forecast how long things will take, how much they'll cost, etc. That's how you figure out when things will be done.

This is the perfect recipe for never delivering anything. Without release dates developers will continue building and gold plating and building and gold plating. Create your tasks, estimate your tasks, put a date out there, and hit the date. If the product has bugs, unfinished features, then so be it. Users understand flaws. They don't understand missed dates.

Not all developers are gold platers. That seems to be a more common behavior among inexperienced developers.

Re: Agile Lite: Agile without all the burnout

#87

Post by jgust » Thu, Apr 04, 2019, 2:52 PM UTC

EngineerBetter wrote: post #24

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…

> Always do the simplest thing.

Can you clarify? If you meant "always search for the simplest solution" I agree. If you meant, "always do the easiest tasks" I don't.

Re: Agile Lite: Agile without all the burnout

#88

Post by jgust » Thu, Apr 04, 2019, 2:53 PM UTC

jaequery wrote: post #63

chrismeller wrote: post #53

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…

I was once a project manager on a team that does daily standups. What eventually happened was that the team would usually re-iterate what I say, or vice versa. It made me question what was the point of doing standups.

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.

Re: Agile Lite: Agile without all the burnout

#89

Post by [deleted] » Thu, Apr 04, 2019, 2:55 PM UTC

chrismeller wrote: post #53

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…

[deleted]

Re: Agile Lite: Agile without all the burnout

#90

Post by LifeLiverTransp » Thu, Apr 04, 2019, 2:55 PM UTC

EngineerBetter wrote: post #24

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…

Its never the wrong socialism. Maybe actual agile as imagined is incompatible with captialsim and human nature?