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

201–210 of 292 posts

Re: Agile Lite: Agile without all the burnout

#201

Post by e12e »

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…

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, obviously - reality is a bit more nuanced.

Re: Agile Lite: Agile without all the burnout

#202

Post by wool_gather »

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…

Ironically, such clients also seem to expect that whatever additions/changes they dream up should be able to be folded in to the plan willy-nilly. Whereas if they accepted an iterative process that would come naturally, without constant re-negotiation or ill will.

Re: Agile Lite: Agile without all the burnout

#203

Post by eikenberry »

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…

> 1. You're not breaking down the work into small enough chunks to properly think about how long it will take

This usually means prototyping, which means actual coding, which means you couldn't do it as you already had to give your estimation. To put it another way, places who require estimates for planning want them during planning and don't allow time for doing this. On the up side, when they do let you take the time to prototype they take your prototype and put it right into production because then the estimate is 0.

> 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

This is a common trick but it really just means you are not really estimating, but guessing that it will take less than this amount of time. This would be more apparent if you gave an estimation range, what you actually estimated to your estimate times the 3X padding.

Re: Agile Lite: Agile without all the burnout

#204

Post by Scarblac »

chrismeller wrote: post #144
Scarblac wrote: post #133

Earlier quoted context omitted.

But if something is blocking you, you should not wait for the standup to bring it up, what a strange way of working is that. Just ask someone who can help you. That's one thing that works well in my company. Still people also want standups, basically to hear what others are doing and feel like a team.

And so we circle back around to the pointlessness of all meetings. If it is as-needed to hash out an idea or determine the best way to fix something or to scope and point... that’s fine. If it’s every day, twice a week, every MWF, etc. there is absolutely no way it’s actually necessary every one of those times and everyone is going to eventually defer to human nature and wait for the meeting to bring things up. Part…

I know. I wanted to get rid of our standup as it has no real point. The rest of the team wanted to hear what people were doing, so it stayed.

Re: Agile Lite: Agile without all the burnout

#205

Post by otaviokz »

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?

Sure, just throw some marketing style word play at it. Who knows, maybe this time it will stick?

Re: Agile Lite: Agile without all the burnout

#206

Post by gridspy »

beat wrote: post #174
tootie wrote: post #163

Earlier quoted context omitted.

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.

Yes, this is also worded as "Slow is smooth, smooth is fast" - used for instance when following emergency checklists.

It's a good mantra when under serious pressure.

Re: Agile Lite: Agile without all the burnout

#207

Post by e12e »

beat wrote: post #174
tootie wrote: post #163

Earlier quoted context omitted.

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.

"slow is smooth, and smooth is fast"

Ed: see also: "practice makes permanent".

Re: Agile Lite: Agile without all the burnout

#208

Post by eikenberry »

justjash wrote: post #65
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…

I agree with most of it minus the "Don't make esitmates" part. Without making some sort of estimate things just don't work. I guess maybe it could work assuming you fully control a single product. Everywhere I have worked we need the estimates simply for coordination of all the moving parts.

Maybe you could rephrase it to "Don't make estimates before work is well underway". The main problem with estimates is that they are usually just wild guesses and pretty useless. But once you've got going on something, have had time to think it through and test your ideas, you can usually give at least a very rough estimate at that point.

Re: Agile Lite: Agile without all the burnout

#209

Post by MrBuddyCasino »

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

Thats only if that feature is optional. Often it isn't, and then it is pointless to estimate. Absolutely pointless.

Re: Agile Lite: Agile without all the burnout

#210

Post by dragonwriter »

MrBuddyCasino wrote: post #209
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.

> They need to know that, because they need to decide if it's worth it in the first place Thats only if that feature is optional. Often it isn't, and then it is pointless to estimate. Absolutely pointless.

> Thats only if that feature is optional.

If it's optional, they need to know to make a decision to include or exclude it.

If it's not optional for the project, but the project itself is optional, they need to know to make a decision to kill or keep the project.

If it's not optional to the project , and the project is not optional to the business, they need to know to decide whether they keep or fold the business.

In any case, if they might choose to keep the business, project, and feature, they need to know because they have to budget for the cost if they do so.

So, essentially, business always needs to know the cost.

Post reply on HN