Agile Lite: Agile without all the burnout

Agile Lite: Agile without all the burnout
github.com

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, and you get no chance to say no. Technical minds / engineers in the room early and often is critical to success - otherwise you’re just told what to do instead of architecting it the “right” way.

Communicate when you need to but try it all for a sprint or two (really, Standup is a hardship? You may not be doing it quite right), then drop after the team finds a rhythm.

Edit; after reading the author’s other works the burnout seems to be centered on a big push from stakeholders to accelerate and keep going so a sprint is seen as a reset - kinda like a new day dawning in a news room. You can plan-in your work to avoid this and still continue to make progress but it does take some discussions with leadership, or at least a clear justification about why this week is exploratory instead of hands-on. Done it many times. I would not suggest changing the whole method just to accomplish this, however - a process fix for a problem like this won’t necessarily help.

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 for some projects and others don't.

I've worked on "A.I." projects where the sprint involves running a batch job that might take two days if it all works right. If it doesn't work right you might have to retry a few times.

When I was in charge of that batch job I would start it as soon as possible, sometimes with a week and a half to spare. Whenever somebody else was in charge of it they would start it with half a day or a day to run and we would blow the end of the sprint.

I blame the continuous stream of "urgent but not important" communicates generated by agile for that.

The timeboxing of planning is also a very bad idea. 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. After that the work was mostly downhill, at least the way I saw it, but one of the other team members would consistently burn the midnight oil at the end.

Often agile "teams" have a "normalization of deviance" situation where they have to do one thing (or say they are doing one thing) so they can say they are sticking to the process, but actually do something entirely different to get the job done.

That's sad.