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

Re: Agile Lite: Agile without all the burnout

#111

Post by tonyarkles » Thu, Apr 04, 2019, 3:13 PM UTC

clavalle wrote: post #80

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.

Estimates are always wrong only if they are concrete estimates as if they were certain. If, instead, they are 90% ranges (I am 90% sure that this will be done between x and y) then it is much easier to estimate accurately. It is also easier to spot bullshit (if the spread doesn't go up as your time to completion moves further from now, it is probably a bullshit estimate).

I really love the method from The Clean Coder, where you make best/median/worst estimates for tasks and then add them up to a mean and standard deviation. This helps capture the truth of “we don’t know how long it’s going to take, but it’s likely between x and y”.

Where this still falls apart, for me, is knowing how many hours per day I’ll be able to spend on each project. I have multiple clients, and things come up. This method has gotten me very good at the budget aspect of project estimation, but the scheduling aspect still slips some (it’s rare that more hours in a day become available)

Re: Agile Lite: Agile without all the burnout

#112

Post by devin » Thu, Apr 04, 2019, 3:13 PM UTC

Stakeholder: "So, just so I understand, your team went surfing for a week, and the reason we didn't finish everything in scope for the sprint is what again?"

Re: Agile Lite: Agile without all the burnout

#113

Post by chrisweekly » Thu, Apr 04, 2019, 3:15 PM UTC

jgust wrote: post #87

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.

Simple != Easy

I highly recommend this Rich Hickey talk (transcription):

https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

Re: Agile Lite: Agile without all the burnout

#114

Post by plutonorm » Thu, Apr 04, 2019, 3:18 PM UTC

shay_ker wrote: post #94

No matter what you do, or what process you implement, if the organization does not _respect_ engineers, your life will categorically suck. As others have noted, the amount of process involved with "Agile" these days is not in the spirit of the original Agile Manifesto. Additionally, how is it that _some_ organizations do it well, vs. others that make life hell? This fundamentally comes down to how much the organizati…

I can honestly say that in 15 years and 8 companies I have never seen one that respects developers.

Re: Agile Lite: Agile without all the burnout

#115

Post by everdev » Thu, Apr 04, 2019, 3:20 PM UTC

I work mostly with startups and I don't know any that could survive with a plan like this:

> 3 weeks on/1 week off development cycle

Unless you're lucky enough to have no competitors and a ton of runway and no major support issues ever, there's no way you can give your engineering team 12 weeks of vacation a year all at the same time.

> Once a sprint has begun, Issues may not be added to the sprint, but they can be removed. This reduces context switching and that is a good thing.

Yes, minimizing context switching is a great thing, but for 4-8 weeks you can't adapt to changing business conditions? A change that comes in on day 2 will have to wait 8 weeks to go live as it won't be put into a sprint for 4 more weeks and then launched another 4 after that.

I'm a developer and totally understand the desire to have every requirement up front and peace and quiet to implement it. The goal should be to get as close to that as possible but still being open to business needs.

Unfortunately I've seen first a dev team sink a multi-million dollar business through a lack of flexibility and turnaround time.

I don't think you'll find many managers rushing to implement this, which is basically inflexible agile with a week of vacation every month. I think the experience of managing a dev team while trying to balance a budget would be invaluable for anyone thinking that this process makes sense.

Re: Agile Lite: Agile without all the burnout

#116

Post by snarfy » Thu, Apr 04, 2019, 3:21 PM UTC

Agile is the Agile Manifesto. Anything else is not. All I see are references to Scrum. Maybe this should be called Scrum Lite?

Re: Agile Lite: Agile without all the burnout

#117

Post by potta_coffee » Thu, Apr 04, 2019, 3:21 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…

"Don't make estimates."

Very few managers / CEOs are going to let you get away with this.

Re: Agile Lite: Agile without all the burnout

#118

Post by carlmr » Thu, Apr 04, 2019, 3:23 PM UTC

PaulHoule wrote: post #69

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.

That is bull. Some tasks have a high degree of uncertainty. Others don't. Back when I was using a ruby-on-rails style framework (in PHP) I would frequently get 20 hours of work estimated properly down to 15 minutes when it came to adding simple features to a web application. If on the other hand you are trying to figure out the gap between what the documentation says should work and what actually works, that is hard…

And nevermind the technical issues. If you need to work with others, that's where estimating gets hard.

Re: Agile Lite: Agile without all the burnout

#119

Post by addicted » Thu, Apr 04, 2019, 3:24 PM UTC

phillc73 wrote: post #82

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…

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.

Re: Agile Lite: Agile without all the burnout

#120

Post by myth2018 » Thu, Apr 04, 2019, 3:25 PM UTC

ajmurmann wrote: post #41

myth2018 wrote: post #11

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…

Sorry, there is no "faster" button. The only lever you have is cutting scope as you go. Fixed scope just makes no sense. Otherwise you get one of three outcomes: 1. We underestimated how much we can get done. People now start gold playing stuff and wasting time that would be better spent on future backlog items. 2. You estimated just right and are done Friday at 5pm. Obviously this doesn't happen frequently. 3. You o…

Experience shows that this is not the way things work.

Real-world team members present varying levels of maturity and, therefore, commitment levels to the aimed results.

Some will work at their natural pace and deliver the thing, provided the estimates were accurate; some will relax and leverage the fact that it's always OK to say that there was not enough time; some will work hard at the beginning and get contaminated over time; and so on.

It is sad to work without a 100% mutual trust, but we have to be realistic. Building trust takes time.