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

101–110 of 292 posts

Re: Agile Lite: Agile without all the burnout

#101

Post by noxToken »

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. It only applies to certain offerings, and the stakeholders only want the verbiage the be applied after a certain step in the application. This is still a relatively simple change, but when factoring in all the other "simple" requests that involve complex logic, changing displayed text becomes relatively complex.

We do sprints because it's our time box to see how close we are to hitting the mark. A sprint isn't a hard deadline in which the team must kill themselves to get everything finished. It's an arbitrary passage of time for setting goal to keep on track with what is going to be released. If you have something that's releasing two months into the future, it's easy to say that you can still make time although your first two weeks were riddled with unexpected complications and stoppages. A sprint forces us to focus on what should have already been completed to re-prioritize if necessary. And you can't feasibly do that without an estimation.

The two biggest problems with estimations are underestimating and treating estimations as promises. It's hard to estimate. So the best course of action is to make stories as small as possible. Probably smaller than someone would consider rational. If not, at least have the stories divided into individual tasks or chunks. Then once you have estimations, treat them as goals rather than deadlines. Use your sprint review as a time to honestly reflect on why the estimation was missed. Then, and this is critical to successfully estimating in the future, use the notes of reflection to make better estimates.

Re: Agile Lite: Agile without all the burnout

#102

Post by hopler »

ramraj07 wrote: post #60
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.

Only issue being that the estimates one gets from poorly planned sprints are probably less reliable than just asking the devs how long the project will take and going with it.

Good estimates come from watching people deliver over time and scientifically comparing empirical performance to subjective estimates, not asking them to predict. Joel Spolsky has a great blog post on Painless Software Schedules.

Re: Agile Lite: Agile without all the burnout

#103

Post by ako »

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.

And agility in this case being Business Agility: the business being able to change course, not being hold hostage to a years long plan which cannot be changed.

Agility has nothing to do with software development, and everything with business.

Re: Agile Lite: Agile without all the burnout

#104

Post by systematical »

Pretty much what we do except our sprints are two weeks with two of those days devoted to planning. If it's a bigger project then planning may be a sprint task of is own.

We release on Tuesdays so every other Friday and Monday end up being pretty light assuming the Thursday QA went well.

Re: Agile Lite: Agile without all the burnout

#105

Post by chrismeller »

jgust wrote: post #88
jaequery wrote: post #63

Earlier quoted context omitted.

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.

The point of standups is to help teams to learn to communicate and to steer the team to a habit of working on the most important things. Once that's a behavior, standups can be less frequent or dropped all together. This is especially useful for new teams or when the team changes.

No, the point of standups is to go around in a circle and make sure that everyone has everything they need to keep working (that there are no “blockers” in the parlance of agile). That’s why they’re called standups - you’re supposed to stand so that everyone gets annoyed if it takes more than a handful of minutes.

If you’re discussing what you did yesterday, what you’re going to do today, when you think x is going to be completed, what is blocking you (other than that so-and-so owes you such-and-such), or anything else other than nodding that you’re good you’re missing the point and that’s where the slippery slope of pointlessness begins.

Re: Agile Lite: Agile without all the burnout

#106

Post by numbsafari »

beat wrote: post #78
numbsafari wrote: post #73

Earlier quoted context omitted.

If we can all agree that "shipping" is a feature[1] and that "shipping faster" is a competitive advantage, then "shipping fast" is probably one of the first features we should invest in as a team, from leadership to private chef. If it takes 10 people and six hours to accomplish the release of even the smallest of features, then it sounds like there's a bug with your "ship fast" feature and the team should invest som…

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?

Re: Agile Lite: Agile without all the burnout

#107

Post by BurningFrog »

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.

> 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 agile concept of "velocity" is the best way I know of managing this. It's not very good, and it's often a victim of Goodhart's law.

Re: Agile Lite: Agile without all the burnout

#108

Post by jeletonskelly »

LifeLiverTransp wrote: post #90
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…

Its never the wrong socialism. Maybe actual agile as imagined is incompatible with captialsim and human nature?

Would you prefer the centralized planning model of waterfall? Of course none of these systems are perfect, but it's been a major step in a better direction for everyone involved.

Re: Agile Lite: Agile without all the burnout

#109

Post by reallydontask »

gnome_chomsky wrote: post #86
ryanSrich wrote: post #75

Earlier quoted context omitted.

This is the perfect recipe for never delivering anything. Without release dates developers will continue building and gold plating and building and gold plating. Create your tasks, estimate your tasks, put a date out there, and hit the date. If the product has bugs, unfinished features, then so be it. Users understand flaws. They don't understand missed dates.

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

Re: Agile Lite: Agile without all the burnout

#110

Post by reallydontask »

EngineerBetter wrote: post #39
fatnoah wrote: post #29

Earlier quoted context omitted.

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

Indeed, and the Scrum-Industrial Complex has vested interests in codifying a certain format that it can sell.

not heard that term before (Scrum Industrial Complex) but it's pretty good, going to use it from now on :)
Post reply on HN