Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Agile Lite: Agile without all the burnout

github.com

Post reply on HN
Print view View original

211–220 of 292 posts

Re: Agile Lite: Agile without all the burnout

#211

Post by brenschluss »

mLuby wrote: post #184
mattmanser wrote: post #161

Earlier quoted context omitted.

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…

I've seen Agile™ estimation break down when the task is either 1. something nobody has done before (or has no close analog), or 2. is so interconnected that it can't be broken down. The former is just a matter of hiring more experienced engineers _or_ allocating exploratory/prototyping time. Still high uncertainty but these kinds of tasks become rarer over a time. For the latter, the common refrain is "break it down"…

> Builders can construct a house, then add a garage, go work on another house, then return and add a guest bedroom, then remodel the kitchen, all with relatively minimal pausing or switching cost.

Have you worked with contractors? This is so so so so not true.

Re: Agile Lite: Agile without all the burnout

#212

Post by mamon »

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.

My take on that is that any standup attended by project manager is not a Scrum standup anymore, it's a status update. What I've seen in few companies is that after such morning meeting with PM, the development team, would hold their own, smaller scale meeting, the real stand-up :)

One pathological case I've seen is the Scrum meeting that would run for an hour, because it was attended by 25 people, every day.

Re: Agile Lite: Agile without all the burnout

#213

Post by dragonwriter »

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…

> The traditional way to manage this impossibility is that engineering lies about it (they have to lie, because they can't know either)

Honest estimates with uncertainty are not lies, and not having certainty doesn't prevent estimation.

But, yes, people seem to often decide that being uncertain justifies self-serving lies instead of honesty (and sometimes the environment encourages that by punishing honest estimates.)

Re: Agile Lite: Agile without all the burnout

#215

Post by tybit »

Scarblac wrote: post #48
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 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.

I think this is totally reasonable at certain times. E.g how long will it take to add feature x with scope y to our existing product is a decent thing to estimate (and estimate only) for stakeholders to prioritise appropriately.

I think most problems people have with estimates is when they are applied to things too large, or too small, to reasonably estimate. E.g How long will it take to build this product from scratch with a laundry list of features. Or more commonly, to micromanage. Why does anyone care whether this task will take 2 days as opposed to 3? That’s not meanginful information unless you’re mistakently expecting the individual user story estimates to add up to a reliable assembly line of work.

I’m happy to estimate when it has some business purpose. If not, it’s meaningless busy work or worse.

Re: Agile Lite: Agile without all the burnout

#216

Post by gregmac »

Scarblac wrote: post #48
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 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.

> They need to know that, because they need to decide if it's worth it in the first place

If this is the case, they should also be able to state the threshold above which the item would be "not worth it", and I would assume this is significantly easier to figure out than it takes developers to build a decent estimate.

From a developer point-of-view, the first high-level estimate is then much, much simpler: "Is it going to take more or less than $not_worth_it to build?"

If the answer is "more", then it gets dropped -- at least in its current state. It could be re-scoped later as a new item with a smaller MVP, for example.

If the answer is "less", then the developer can put in the time to get a proper estimate. I think there might also be an argument that if the backlog is properly ranked the detailed estimate also becomes pointless -- just work on it until it's done. No one should be doing detailed estimates on items that are more than a few weeks/sprints away in the first place.

Disclaimer: I've only recently been thinking about this abstractly, and have not yet tested this in practice, though I'd love to have this discussion with anyone that has.

Re: Agile Lite: Agile without all the burnout

#217

Post by ozim »

Please don't read it literally.

Seems like author did not really meant that to be specific advice or exact manual. It seems more like talking piece and maybe some distant idea we could strive for.

I was also at first thinking "what kind of company has those kind of resources, and what kind of ideal world is that where you can plan 3 weeks of work in 1 week without adding stuff to sprint".

Re: Agile Lite: Agile without all the burnout

#218

Post by fwip »

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…

The only thing consistent about Agile is that everyone is doing it wrong.

Re: Agile Lite: Agile without all the burnout

#219

Post by abernard1 »

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…

> 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

This is exactly what waterfall was. It pre-planned all the small tasks beforehand and required stopping the world and replanning everything when something changed.

Agile was an attempt to move away from that and create a feedback loop where you do some limited work, learn something from it, and then do another thing after you've internalized what you learned. (Original "sprints" were a coordination mechanism between departments that was applied in the automotive industry: there was lots of dead space in-between them). The whole point was the iteration was small enough that it didn't actually matter if your estimate was correct or not.

This bastardization where Agile has become synonymous with estimation accuracy is completely against its original spirit. People have started to care about estimates because Software Project Managers wouldn't have a job if there wasn't a need for heavy-handed planning sessions.

Re: Agile Lite: Agile without all the burnout

#220

Post by alanthedev »

PaulHoule wrote: post #79
erikstarck wrote: post #30

Earlier quoted context omitted.

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…

I would say that retrospectives are the biggest waste in agile in my experience. For one thing, retrospectives often come at a time when everyone has been busting ass for a long time and they just want to go home. If you put it off till next week then it seems like another distraction. Like the planning meetings, the timebox for a retrospective is often wrong. In some cases things went smoothly and there is a little…

> when everyone has been busting ass for a long time and they just want to go home

This sounds like a smell. You should not be busting ass and have everyone feel like they just want to go home at the end of the sprint. You should be working productively every day without burning out. Perhaps the team is forced to make too many commitments? Kind of sounds like it from your other comments.

Post reply on HN