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

121–130 of 292 posts

Re: Agile Lite: Agile without all the burnout

#121

Post by shay_ker »

plutonorm wrote: post #114
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.

The company I currently work at respects developers immensely.

Re: Agile Lite: Agile without all the burnout

#122

Post by steve76 »

It's wrong to assume your client is good, doing good things, and not hiding anything, like they are taking all the credit, and putting all the blame on you.

It helps if the client is another programmer so they actually know what they are asking for.

Too often clients ask for way too much. Ask for one thing, do it right, make money, and come back for more features.

The big trend I am seeing with designs are "time bombs". You get deep into what they want, and find out they hid something that makes it 100x more complicated. Why? !!!

Re: Agile Lite: Agile without all the burnout

#123

Post by beat »

numbsafari wrote: post #106
beat wrote: post #78

Earlier quoted context omitted.

Yeah, I know. And I've read the book. But I work in enterprise devops. This is the reality of many, many teams. Which means there's a lot of unnecessary process that needs to get tossed and a lot of automation that needs to be built in order to do short iterations and get out of the 3-6 month window.

Me too! I feel your pain. Have you considered giving it as a gift to your peers and leadership? I really think it's a great read and resource for anyone trying to sell organizational change. I wonder if any of those "automation needs" could be turned into startup ideas?

Done that, too.

I actually tried a startup in the monitoring space, but sadly failed (it was great fun losing $100k or so, tho... well worth the experience!). But the automation needs problem is more a consultancy thing than a product thing. There are lots of products. Teams buy them, with the best of intentions. Lots of management wants to believe they can buy their way out of the hard problems of not having any discipline. Sigh.

Re: Agile Lite: Agile without all the burnout

#124

Post by JustSomeNobody »

hopler wrote: post #98
matwood wrote: post #22

Earlier quoted context omitted.

I agree. The team (which includes developers) should be the ones pulling issues into the sprint. Leads and stakeholders can prioritize on their own, but again developers need some say in that process because technical issues my drive some prioritization. I get the concept, but a week off seems a bit extreme and a hard sell. The team should already be working in some slack time in the sprint. The reason for slack time…

No no no! Agile has never been about predicting what you will do during a spent and then having slack or crunch time. Agile is about ranking your work by priority and dependency, setting meaningful milestones, and then adjusting your estimates frequently to avoid false promises and react to changes in the environment. If you don't finish planned work in a sprint, that is a planning success because after only a brief…

> If you don't finish planned work in a sprint, that is a planning success...

In practice, most companies don't do this. They mark it as a failure and put it in red on the the big screen for all to see. Too many reds and there's disciplinary action.

Re: Agile Lite: Agile without all the burnout

#125

Post by Scarblac »

fatnoah wrote: post #29
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…

Scrum is a framework to achieve "agility" and people forget that. The point is agility, not scrum.

The point is making valuable software in reasonable time.

Agility is a way to deal with the fact that the idea of what "valuable" is changes constantly.

Re: Agile Lite: Agile without all the burnout

#126

Post by LandR »

bunderbunder wrote: post #43

It seems like you could solve this problem in an even more dev-friendly way by sticking to one of the most fundamental principles in scrum (and possibly others): Don't schedule 100% of your developers' time, and definitely don't fill them up to 100% on coding work. Not even close. Devs are supposed to work at a sustainable pace. A sustainable pace leaves plenty of time for kicking your feet up on the desk in order to…

>It seems like you could solve this problem in an even more dev-friendly way by sticking to one of the most fundamental principles in scrum (and possibly others): Don't schedule 100% of your developers' time, and definitely don't fill them up to 100% on coding work. Not even close. Devs are supposed to work at a sustainable pace.

This sounds great until you work someplace where you need to allocate 7.5 hours every day to a billable project.

If you don't allocate 7.5 hours you are asked what you were doing the rest of the day...

I've seen where someone won't have a conversation at work because they can't allocate a project to 10 mins chatting with work colleagues.

Or when you get asked a coding question from a junior and so you help them, but then need to get their project code they were working on so you can allocate that 10 minute chatting /giving advice to that project.

Or helping a junior with something they are stuck on, management sees and questions why two devs are sitting at one machine...

Re: Agile Lite: Agile without all the burnout

#127

Post by mongol »

plutonorm wrote: post #114
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.

What does that mean, really? What is a sign of respect that you find missing?

Re: Agile Lite: Agile without all the burnout

#128

Post by watwut »

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.

Theoretically. Practicaly they don't do that kind of planning and high estimate leads to pressure to lower it down (or making you feel ashamed for it being to big etc), which most developers will do, because developers tend to sux at negotiation.

Re: Agile Lite: Agile without all the burnout

#129

Post by someone7x »

reallydontask wrote: post #109
gnome_chomsky wrote: post #86

Earlier quoted context omitted.

Not all developers are gold platers. That seems to be a more common behavior among inexperienced developers.

That's interesting as in my experience is exactly the other way about. It's the experienced developers that try to gold plate to avoid the issues that they had in the last project or two projects ago, whereas the juniors ship code quickly but unfortunately often incomplete and certainly lacking a reasonable amount of test coverage

> It's the experienced developers that try to gold plate to avoid the issues that they had in the last project

Literally learning from the past and applying it to the present is “gold plating”?

I’m stunned.

Re: Agile Lite: Agile without all the burnout

#130

Post by jboy55 »

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…

The idea that any process is the blame or can be a success in an environment with sociopathic management is absurd.

"Baseball sucks because my manager hits me frequently with baseball bats to make me work harder. Here is my blog against Baseball, I am pushing my org to switch to Soccer. I'm sure the lack of hitting weapons will stop my manager from abusing me."

Post reply on HN