Agile Lite: Agile without all the burnout • Hacker News Board

Re: Agile Lite: Agile without all the burnout

#271

Post by sailfast » Fri, Apr 05, 2019, 1:10 PM UTC

dave_sullivan wrote: post #245

andmarios wrote: post #228

Earlier quoted context omitted.

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.

So is the burnout because you’re just grinding all the time on tightly defined stories and you feel like there is no room to slow down? Legitimately curious and I appreciate you writing this up and putting it out there.

Re: Agile Lite: Agile without all the burnout

#272

Post by sailfast » Fri, Apr 05, 2019, 1:12 PM UTC

phillc73 wrote: post #82

sailfast wrote: 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…

I'm not sure the author is advocating for no developer presence during the planning period. > The first week of each month is spent with project leads and stakeholders defining the upcoming sprint At the very least, I'd suggest that developer leads or engineering managers are stakeholders and therefore involved. They should be liaising with their development team (also stakeholders) during the planning phase. Perhaps…

Ah! My initial read on this was “devs take the week off and the project leads and stakeholders do the work.” The “with” did some work that I interpreted differently. That makes sense.

Re: Agile Lite: Agile without all the burnout

#273

Post by pas » Fri, Apr 05, 2019, 2:10 PM UTC

abernard1 wrote: post #219

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…

> 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 This is exactly what waterfall was. It pre-planned all the small tasks beforehand and required stopping the world and replanning everything when something changed. Agile was an attempt to move away from that and create a feedback loop where you do some limited work,…

I think the estimation accuracy is not the main point nowadays, but instead the simple fact that the viability/rentability of every project matters, and even if there's an up front pile of money to spend (quarterly/yearly budget), there are probably multiple competing ideas on what to spend these - and of course these usually consist of and involve software and its development.

Of course this is why having a low-fluctuating empowered team (project ownership, refactors, etc) can usually deliver changes faster and with lower cost and with greater consistency, than every time doing a new project (which might involve new people who never saw the stack, nor the business domain) to modify something on a system.

Re: Agile Lite: Agile without all the burnout

#274

Post by pas » Fri, Apr 05, 2019, 2:12 PM UTC

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…

That's the problem. In theory every bridge is the same. Yet you need to plan each one of them.

Similarly every run of the mill business-as-usual boring-as-fuck CRUD corporate internal "app" is the same, yet they still need a lot of work, and they are still hard to "estimate".

Re: Agile Lite: Agile without all the burnout

#275

Post by dave_sullivan » Fri, Apr 05, 2019, 2:21 PM UTC

sailfast wrote: post #271

dave_sullivan wrote: post #245

Earlier quoted context omitted.

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.

So is the burnout because you’re just grinding all the time on tightly defined stories and you feel like there is no room to slow down? Legitimately curious and I appreciate you writing this up and putting it out there.

It's not even tightly defined stories, it's just teams working too much with no downtime, no time to slow down and catch your breath. There are always more things to do than time to do them, so unless lines are drawn the default is perpetual overwork.

Many seem to freak out at the concept of working less. Yet the 40 hour work week was considered radical at one point. Googles 80% time is by most accounts not a real thing, but it's a start. I'm at 75% time here. Then there's 996 if you want to go the opposite direction.

Re: Agile Lite: Agile without all the burnout

#276

Post by pas » Fri, Apr 05, 2019, 2:31 PM UTC

andrewprock wrote: post #173

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…

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?

Initial estimation (over many sprints, with either a greenfield project or with a new dev team) is always very hard, almost a completely foolish attempt.

After the first few sprints the uncertainty reduces.

And after the team gains experience with the system (business domain + codebase + infrastructure - if applicable), they are much better at scoring tickets (SCRUM poker), which then can be converted back to time from points.

Directly estimating time (asking for time estimate from programmers) is just something that never works (or if it does, then it means the programmers does the following adjustment internally), as humans get into the confusion of constantly having to recalculate their intuitive feeling of required time based on how long actually that took the last time they felt that.

Re: Agile Lite: Agile without all the burnout

#277

Post by pas » Fri, Apr 05, 2019, 2:43 PM UTC

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…

> To claim estimating is "impossible", when many of us do it absolutely fine, is ludicrous.

How do you do it? I mean, how do you know when you reached the necessary granularity? And even if you know, sometimes it just means more questions that the client might not be able to answer at that time. Do you come up with a worst and best case and carry that delta up the breakdown hierarchy of components? Are you able to do this for every kind of task that can come up in a project? (From frontend design to backend implementation and third party system integration and infrastructure setup and then product deployment.)

Re: Agile Lite: Agile without all the burnout

#278

Post by pas » Fri, Apr 05, 2019, 2:46 PM UTC

borski wrote: post #155

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…

Engineering does not have to lie. All this takes is design and specification upfront, a well-defined feature set, and room for error. Also, avoiding scope creep is paramount.

What's the usual processing speed of a software engineer when it comes to reading through and understanding design & specification?

We found that usually either the documentation/specification/requirements are too fine grained (and then they then change all the time, but then there's no real effort/bandwidth to do change management on the specs), or they are not detailed enough, which makes the estimation process a useless guessing game on what might they mean by this or that.

Re: Agile Lite: Agile without all the burnout

#279

Post by pas » Fri, Apr 05, 2019, 2:49 PM UTC

Drdrdrq wrote: post #225

beat wrote: post #131

Earlier quoted context omitted.

Another bit of wisdom I got from Kent Beck is that there are three basic controls to every project... schedule, scope, and resources. You can only control two of them. And resources are generally fixed at the beginning of the project(1), so most projects are either scope-bound (we must have all these features), or schedule-bound (we must hit this hard date). If you're feature-bound, estimation failure means you'll be…

There is a fourth control of course which comes into play when nothing else will give room: quality. You can take many shortcuts to deliver in time, full scope, with the resources available. But the result will be buggy and/or unmaintainable. Surprising amount of companies choose this path, I guess most without realizing it.

Quality is basically inherent in scope. Is testing the product in scope? Yes, then it will take up precious resources (time). Do you want to test it on every platform? Yes, even more time. (And of course the same goes for code review, writing unit tests, planning, writing and discussing a design document, etc.)

Re: Agile Lite: Agile without all the burnout

#280

Post by pas » Fri, Apr 05, 2019, 2:57 PM UTC

pugworthy wrote: post #170

aplummer wrote: post #71

Earlier quoted context omitted.

Don’t make estimates, make... forecasts?

This kind of word game in agile drives me crazy. It’s like points aren’t hours, but if I estimate (er, forecast) how many hours it will take, its pretty easy to turn that into points, and vice versa. I suppose it’s like one of those, “There is no word for it in English, but it essentially means...”

Points are a team-internal measure of a task. You can after the fact convert points to time, and then after a few sprints (when you have a fairly stable average velocity) then you can convert points to hours and do a forecast/estimation.

// In my mind you forecast the date of completion, but you estimate the amount of work. It's probably just mindless semantics, after all saying you can estimate the date of completion sounds just as natural, but saying you can forecast the amount of work sounds a bit unnatural.