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

231–240 of 292 posts

Re: Agile Lite: Agile without all the burnout

#231

Post by cromulent »

ausjke wrote: post #62

Working with agile for the last half-year. while it does make people agile, i.e. stir things up with daily stand-ups etc, it also causes more chaos on the technical side. anyone can pick up any stories, after a while there is nobody that is an expert in any domain, everyone knows a little about everything but nobody knows any subject deeper, no more domain expert. Now bugs took forever to debug, the whole group is co…

Agile isn't standups, nor user stories, nor sprints. They have been attached to it, but you can be agile without any of those things.

My understanding of the "Working software over comprehensive documentation" is based on all the stupid documents that no-one ever read. You should still document the software for your colleagues, not for imaginary ISO9001 auditors.

There are so many charlatans in this area, it is frightening.

Re: Agile Lite: Agile without all the burnout

#232

Post by asark »

jayd16 wrote: post #148
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 overtime. Don't make estimates. Said another way, estimates are not promises. Don't crunch to meet them. I think it should be phrased as "no deadlines". The whole sprint structure is so you're constantly adjusting your plans and estimations at some predictable time. Without a sprint you can end up with randomization.

I've noticed some managers and project managers love to emphasize the that sprint plans are "commitments". "OK, is this what we're committing to for this sprint? Is everyone comfortable committing to this?". LOL. OK. Maybe that guilts the young bloods into doing free overtime or something. But no.

It's like when car salesmen try to get you to name a number you'd definitely buy the car for and sign it on some not-at-all-binding-or-official piece of paper, like that means something, before they go back and "ask their boss if they can make it work". Psychological trickery bullshit.

Re: Agile Lite: Agile without all the burnout

#233

Post by ashelmire »

e12e wrote: post #201
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 don't know. We see quite a few (civil) engineering project that are ~on budget. A few that are wildly over. But the thing is, in software engineering - if you ever need to do again, something you have done before, it should be just a copy away. So you'll never spend time on something you've done before. And if you do, that time is essentially wasted - something that shouldn't be billable. Now that's the ideal, obvi…

> And if you do, that time is essentially wasted - something that shouldn't be billable.

If I develop a feature for company A, then reuse it for company B, isn't A footing the bill for B? I mean, we all do that, but I think it's worth thinking about.

Re: Agile Lite: Agile without all the burnout

#235

Post by v-erne »

mattmanser wrote: post #200
andrewprock wrote: post #173

Earlier quoted context omitted.

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?

It doesn't have to be accurate it just has to be order-of-magnitude right. We're talking about a rough estimate of how much feature X costs. If something costs 15k instead of 10k, that's understandable, if you estimated 10k and it ultimately costs 1.5 million to develop, obviously not.

50% off is understandable ? Where can I find such forgiving clients? My clients lawyers would eat me alive if I would start to bill them in such manner. They dont want to hear about uncertainty - they are buying professionals and this kind of estimations looks to them like we dont know what we are doing.

Re: Agile Lite: Agile without all the burnout

#237

Post by EngineerBetter »

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…

Estimates seem to be a common topic in replies.

If you can accurately estimate how long a software task will take, you should have already made a reusable component or automation to generate that code.

Estimates are meaningless. I've seen PhDs waste endless hours faffing with estimate-calculating spreadsheets.

Fundamentally, the universe is unpredictable. Chaotic and complex systems require their starting conditions to be measured to an infinite level of precision to be predictable. The Heisenberg principle means this is, as far as physics can tell, impossible.

On a more practical macro level, a complex adaptive system becomes unpredictable once three feedback loops are present (the three body problem is related).

Modern computer systems are unpredictable because we cannot predict the interplay between levels of abstraction.

It does not matter how smart you are. Unless you have perfect knowledge of all levels of abstraction in the system below you, even in a macroscopic sense you cannot predict the future. Precise estimates will be inaccurate.

Confidence ranges and superprobabilities are of some use. Discrete and precise estimates are an utter waste of time at best, and are dangerous and misleading at worst.

EDIT

Written on a mobile waiting for plane take-off, hence lack of citations. For more on complex adaptive systems, I recommend the works of Murray Gell-Mann and the research output of the Santa Fe Institute, particularly Scott E. Page.

Re: Agile Lite: Agile without all the burnout

#238

Post by president »

I have always said that Agile methodology, as it is used by most companies, is just a way to squeeze every drop of efficiency from an engineer and ensure that people aren't goofing off. Agile works assuming that you are able to drop features or push deadlines if needed but in my experience in startups and enterprise tech companies, this NEVER happens.

Re: Agile Lite: Agile without all the burnout

#239

Post by chris11 »

beardedwizard wrote: post #2

I think agile has always suggested modifying to fit the team - so then do we need an agile light, or just critical thinkers doing whatever agile provides actual value?

Personally I think that asking how teams do agile differently and how team members change agile practices can be a good gut check to see what agile is like at a company. If some teams do scrum and some do kanban or some teams have daily standups and others don't, then agile is probably more developer driven. But if the answer is something small, like the time of the daily scrum then agile's probably management driven.

Re: Agile Lite: Agile without all the burnout

#240

Post by virtualized »

EngineerBetter wrote: post #237
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…

Estimates seem to be a common topic in replies. If you can accurately estimate how long a software task will take, you should have already made a reusable component or automation to generate that code. Estimates are meaningless. I've seen PhDs waste endless hours faffing with estimate-calculating spreadsheets. Fundamentally, the universe is unpredictable. Chaotic and complex systems require their starting conditions…

Another way to put it: If you know how long something will take in advance, you have a solution in mind. It is unlikely that this solution is (A) the best one and (B) the one you will actually implement. It would be stupid to ignore information you learned along the way. If you could actually predict the future you should invest in the lottery, not in software.

EDIT: Of course there are projects where you actually know exactly what to do. Happens a lot in consulting. That has nothing to do with Agile though.

Post reply on HN