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

Re: Agile Lite: Agile without all the burnout

#171

Post by gumballhead » Thu, Apr 04, 2019, 4:23 PM UTC

I've never gotten burned out from working too hard. I get burned out by having no say or control over what we are working on or how it's done, and by getting stuck working on low-value tasks for prolonged periods of time. Those projects are the ones that make me not excited at all to come to work.

It's usually because the client / product owner has no idea what they're doing but still insists on making all of the decisions with no input from users / developers / designers. And it sure sounds ridiculous, but it is the norm. Developers are viewed as people who do not want to participate in meetings or planning, and who exist on streams of work to do. If the developers run out of work, they'll go crazy! As long as we "keep them unblocked" and have tasks ready for them, we're doing our jobs and they'll be happy!

Re: Agile Lite: Agile without all the burnout

#172

Post by silveroriole » Thu, Apr 04, 2019, 4:23 PM UTC

erikstarck wrote: post #30

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…

This. That is why the retrospective meeting is at the heart of agile. A truly "agile light" setup would be: Every other week, do a retrospective. That's it! On the retro, ask yourself 3 questions (or work with these 3 themes): 1. Is the way we are working helping us, and the rest of the organization, make the right decisions and reach our goals in an efficient way? If not, what needs to change? 2. Is our understandin…

Judging by my retros, I think other dev teams trying this will rapidly find that the answer to all 3 questions can be “no, but there’s nothing we can do about it!” Past a certain company size/amount of bureaucracy, simple agile seems nigh-on impossible.

Re: Agile Lite: Agile without all the burnout

#173

Post by andrewprock » Thu, Apr 04, 2019, 4:23 PM UTC

mattmanser wrote: post #161

BurningFrog wrote: post #107

Earlier quoted context omitted.

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

It's not impossible to estimate roughly how long something will take. If you consistently get it wrong, either: 1. You're not breaking down the work into small enough chunks to properly think about how long it will take 2. You are probably consistently under (or rarely over) estimating and should be able to fix that. For me, I have to triple my estimates, it always takes 3 times longer than I think it would To claim…

Advocating process solutions over people solutions is precisely non-agile. If people are burning out, then you need to address that.

Estimation is hard. Accurate estimation is even harder. Doing it in the face of noon stationary scope is a fools game.

Who is in charge of estimating how long it will take to correctly break down a problem into accurately estimable sizes?

Re: Agile Lite: Agile without all the burnout

#174

Post by beat » Thu, Apr 04, 2019, 4:23 PM UTC

tootie wrote: post #163

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…

The number one reason agile projects fail in my experience has absolutely nothing to do with planning session, sprint cadence or estimation. It's because the client was not properly prepared to accept iterative delivery or play their part as product owner. I see a lot of team organize themselves around a well-groomed backlog and set their priorities only to have clients come in and ask for deadlines and fixed scopes…

I just read a marvelous book called Handmade, by a fine furniture woodworker, and something he says over and over is "Go slow to go fast". The sales pitch to the business for a well-controlled agile process is that it maximizes productivity. Shifting priorities and poor planning undermine the productivity of the development team.

Re: Agile Lite: Agile without all the burnout

#175

Post by geofft » Thu, Apr 04, 2019, 4:25 PM UTC

My worry with a mandatory one-week vacation every month is that people won't take the vacation - they'll use the time to make progress on features or other work-related projects. Burnout isn't solved by a simple "You must spend this time away from your keyboard and this time at your keyboard," and some of the most difficult burnout for me to work through has been when a problem has seized hold of my mind and I've felt compelled to keep working on evenings even when I clearly wasn't making progress.

If you end up in a situation where the document on paper says everyone's taking time off to surf and paint and the actual practice is that some contributors are doing work during this time—and, almost certainly, not getting punished and in fact getting promoted for doing so (perhaps because they commit locally and rebase so nobody knows they were working during this time)—you're going to end up with way more frustration, burnout, and uncontrolled work schedules than you ever started with.

Re: Agile Lite: Agile without all the burnout

#176

Post by geofft » Thu, Apr 04, 2019, 4:28 PM UTC

ngngngng wrote: post #137

btbuildem wrote: post #32

You're suggesting giving devs 12 weeks vacation? I love it. Our management would murder you in cold blood for merely mentioning it.

I feel like our minds take at least 12 weeks off a year anyways, why not let our bodies leave the office as well?

My mind doesn't take 12 weeks off a year on a schedule dictated by management, and it certainly doesn't take the remaining 40 weeks on on a schedule dictated by management. I'll work a lot better doing 6 hours of work a day every week than 8 hours of work with no slack for three weeks straight.

Re: Agile Lite: Agile without all the burnout

#177

Post by andrewprock » Thu, Apr 04, 2019, 4:46 PM UTC

uhhhhhhh wrote: post #169

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…

>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. you just described doing agile wrong... You're advocating for a version of agile lite, not agile. Or alternative, agile is different to everyone you talk to and your agile isn't the same as someone elses agile. Take your pick, but sp…

You are describing Scrum, not Agile. Scrum is a subset of Agile. There are many other Agile methodologies, including what the go outlined.

Re: Agile Lite: Agile without all the burnout

#178

Post by gnome_chomsky » Thu, Apr 04, 2019, 4:57 PM UTC

reallydontask wrote: post #109

gnome_chomsky wrote: post #86

Earlier quoted context omitted.

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

That's interesting as in my experience is exactly the other way about. It's the experienced developers that try to gold plate to avoid the issues that they had in the last project or two projects ago, whereas the juniors ship code quickly but unfortunately often incomplete and certainly lacking a reasonable amount of test coverage

The second-system effect is definitely real and is a trap most developers will fall into. I think gold plating introduces liability and it would be better to ship early. I am, however, conflating my own behavior and anecdotal observations to paint broad strokes.

Re: Agile Lite: Agile without all the burnout

#179

Post by JohnFen » Thu, Apr 04, 2019, 4:59 PM UTC

hopler wrote: post #100

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…

"commitments" do not exist in Agile. Agile was created to remove commitments and insert collaboration in it's place. You don't have to make big promises when your client has ongoing clear visibility into your progress.

That is technically be true, but I've worked at four shops that have implemented Agile methodologies and it hasn't been true for any of them, nor for most of the engineers I personally know but don't work with. I do personally know one person who works on a team that this is true, but he's the only one.

This may be doing Agile wrong, but if something can be so easily done wrong that it's common, I count that as serious flaw in the methodology.

Re: Agile Lite: Agile without all the burnout

#180

Post by JohnFen » Thu, Apr 04, 2019, 5:05 PM UTC

jeletonskelly wrote: post #108

LifeLiverTransp wrote: post #90

Earlier quoted context omitted.

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

Would you prefer the centralized planning model of waterfall? Of course none of these systems are perfect, but it's been a major step in a better direction for everyone involved.

> it's been a major step in a better direction for everyone involved.

I am not convinced that this is true.