Live data from Hacker News

Agile Lite: Agile without all the burnout

github.com

241–250 of 292 posts

Re: Agile Lite: Agile without all the burnout

#241

Earlier quoted context omitted.

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 kn…

> If you could actually predict the future you should invest in the lottery, not in software.

Hear, hear!

Re: Agile Lite: Agile without all the burnout

#242
post #223

Earlier quoted context omitted.

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.

They can! That's exactly the point of agile and is how you get them onboard. When clients want a feature that is weird or complicated or whatever, the answer is never "no" the answer is "sure, now tell us where it fits in the priority list".

Totally, I get that. They don't seem to. ;)

Re: Agile Lite: Agile without all the burnout

#244

Earlier quoted context omitted.

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 stand ups - 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 t…

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.

The point of standup isn't to report status or get unblocked. Even in a large team or for x-team blockage, you can just talk to the PM.

The point is to keep social pressure on weak performers.

One of the main points of Agile (as implemented) is to push the team to perform. Otherwise natural habits of slack creep in. One or 2 people failing to deliver destroys all the good work of the strong performers. This is the real reason for standups.

Re: Agile Lite: Agile without all the burnout

#245
post #3

As a developer, seeing another developer suggest that they just take a vacation and leave the project leads and stakeholders to talk about what should be done in a month is really weird. That will not lead to the absence of a death march - it is a recipe for a death march. Not only will you not have an accurate assessment of the tasks but they will not be ordered correctly, and likely way overscoped for the timeframe…

It says that the sprint planning takes about 45 minutes. What I take that this means, is that there is a backlog with stories and tasks which was created and refined by the dev team. These stories include specifications, estimates and more. So what the project leads actually do, is to decide which of these backlog items will get into the sprint. That's all.

Yep. If everyone’s updating issues in the ITS, it’s easy to plan a sprint. Priorities are mostly already assigned and the sprint planning meeting should be more of a sanity check.

Engineers are only out of the loop insofar as they have fewer meetings where they’re sitting around waiting for their turn to speak. If they want to weigh in, they should, and nobody is stopping them.

Re: Agile Lite: Agile without all the burnout

#246

Earlier quoted context omitted.

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 stand ups - 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 t…

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.

The point of mentioning blockers at the meeting is to put pressure on the person who is the source of the blockage.

In an ideal world this isnt needed, but many people need public reminders or prodding to unblock.

Re: Agile Lite: Agile without all the burnout

#247
My experience of agile has been that it’s a justification for management to put a lot of pressure on their team while micromanaging them at the same time and always making everyone feel like they are failing. If you can get everyone to announce what they got done every day then one developer is thinking, I did ok, and the rest are panicking and thinking, I’m going to get fired if I can’t keep up with that person! Meanwhile there’s nothing in agile about team members having actual agency in determining their own priorities or making decisions. It’s just classic top down pressure cooker micromanagement. In my experience.

Re: Agile Lite: Agile without all the burnout

#248
post #201

Earlier quoted context omitted.

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.

It might be billable to comp B (they got the value add), but internally that should not have high cost (in hours, resources) attached.

Ed: that is to say the time is wasted - but might very well be able to charge a premium on the experience. In my original comment I was mostly talking about making feature x for customer a, then making feature y for customer a. Where x and y are pretty much the same.

Re: Agile Lite: Agile without all the burnout

#249
post #235

Earlier quoted context omitted.

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.

Maybe if you're building the nth monitoring dashboard or something. The work I find interesting is inherently uncertain, though.

Re: Agile Lite: Agile without all the burnout

#250

Earlier quoted context omitted.

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.

I find a good replacement for a traditional agile standup is a board based one. Rather than going through each person where it feels like you're being put on the spot individually, you go through each card on the board and ask what needs to happen for it to move to the next step. 90% of the time it's going to be one person putting their hand up and saying "I'm working on it" then you move on, and the other 10% of the time you might actually have a productive conversation in a meeting, which IMO never happens in a standard stand-up.

I'm surprised more companies haven't moved to this model. I don't really give a fuck what Jim is working on today, I just care whether his card that I have a dependency on is ready or not, or if we need to collaborate on it in some way. If the team is finding they don't know what's going on, or the board isn't being kept up to date, then this style stand-up will actually help with that, rather than just blowing 15 of my most productive minutes listening to everyone spin some bullshit story about how much work they crammed into 8 hours yesterday and why it didn't perfectly align with what they projected in standup the day before.

Post reply on HN