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

Re: Agile Lite: Agile without all the burnout

#161

Post by mattmanser » Thu, Apr 04, 2019, 4:11 PM UTC

BurningFrog wrote: post #107

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.

> 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 estimating is "impossible", when many of us do it absolutely fine, is ludicrous.

Separately, there's scope creep, but that's another matter and again can be managed (e.g. "if you want X extra functionality for the same cost, you're going to have to drop feature Y, which will take roughly the same time").

Re: Agile Lite: Agile without all the burnout

#162

Post by [deleted] » Thu, Apr 04, 2019, 4:12 PM UTC

foobar_ wrote: post #159

jrs235 wrote: post #145

Earlier quoted context omitted.

I feel like #NoEstimates has been a thing. I think #NoMethodology or #NoProcess is the next cool thing (Some might call it #GSD).

#NoProcess seems ideal for small competent teams. We need to get out of the estimation hell for normal projects.

[deleted]

Re: Agile Lite: Agile without all the burnout

#163

Post by tootie » Thu, Apr 04, 2019, 4:13 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…

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 and all the other stuff that is anathema to agile. If you client is able to set priorities effectively and allow a slower, quality-driven model then everything else becomes just so much easier.

Re: Agile Lite: Agile without all the burnout

#164

Post by 1337shadow » Thu, Apr 04, 2019, 4:13 PM UTC

Great guide that does what it says: assure defense to protect developer in weak positions, which as we know is a normal part of experience.

However, maybe it would be nice to add a guide for shadow operations that hackers may want to undertake to ensure project long term success, for when they have a strong position ("aggressive agile" if you want).

Re: Agile Lite: Agile without all the burnout

#165

Post by joncp » Thu, Apr 04, 2019, 4:17 PM UTC

noxToken wrote: post #101

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. The problem with this is that the stakeholder might not understand what simple means. It happens here all the time. We get "simple" requests for verbiage changes, but after reviewing the story, the verbiage request isn't universal. I…

> The problem with this is that the stakeholder might not understand what simple means. It happens here all the time.

"Do the simplest thing" means don't overengineer, not necessarily that the feature won't be complex. You only code up what helps fulfill that particular story's definition of "done."

As for complex features. when my stakeholder asks for some big complex change it's almost always decomposable into much simpler stories. Maybe those have to be hidden behind feature flags until the whole epic is done, but they're shippable individually. Doing that decomposition up front helps demonstrate the complexity to the stakeholder and takes some pressure off of me. It also makes them feel secure because they have more granular insight into progress; that they're not sending me off on some Lewis & Clark expedition.

Re: Agile Lite: Agile without all the burnout

#166

Post by scriptkiddy » Thu, Apr 04, 2019, 4:17 PM UTC

gfodor wrote: post #134

Any methodology where it takes more than a month to turn around a bugfix for a discovered issue in the first week of the month seems flawed. Unless I'm missing something, that's the case here.

The author did mention that some urgent issues don't fit inside the sprint window and should be tackled immediately. I can only assume he meant hotfixes for bugs and things of that nature.

Re: Agile Lite: Agile without all the burnout

#167

Post by EugeneOZ » Thu, Apr 04, 2019, 4:17 PM UTC

Whole week just for talking? Stopped reading after this.

Re: Agile Lite: Agile without all the burnout

#168

Post by eeZah7Ux » Thu, Apr 04, 2019, 4:19 PM UTC

pferde wrote: post #14

Interesting idea. All I've experienced so far was "Agile Enterprise Edition" - cargo-culting all the agile terms, wasting developer time in overly-long standups, yet having a fixed, set-in-stone schedule and delivery plan. Hilarious.

Spot on. Agile, scrum, standups are just tricks to enforce micromanagement and take agency away from engineers.

Re: Agile Lite: Agile without all the burnout

#169

Post by uhhhhhhh » Thu, Apr 04, 2019, 4: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 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 sprints, estimations, not only doing 1 thing/most important things are basic tenants of agile as most people see it.

Re: Agile Lite: Agile without all the burnout

#170

Post by pugworthy » Thu, Apr 04, 2019, 4:21 PM UTC

aplummer wrote: post #71

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.

Don’t make estimates, make... forecasts?

This kind of word game in agile drives me crazy.

It’s like points aren’t hours, but if I estimate (er, forecast) how many hours it will take, its pretty easy to turn that into points, and vice versa.

I suppose it’s like one of those, “There is no word for it in English, but it essentially means...”