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

Re: Agile Lite: Agile without all the burnout

#71

Post by aplummer » Thu, Apr 04, 2019, 2:43 PM UTC

RandallBrown wrote: post #59

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.

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?

Re: Agile Lite: Agile without all the burnout

#72

Post by [deleted] » Thu, Apr 04, 2019, 2:44 PM UTC

RandallBrown wrote: post #59

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.

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.

[deleted]

Re: Agile Lite: Agile without all the burnout

#73

Post by numbsafari » Thu, Apr 04, 2019, 2:44 PM UTC

beat wrote: post #50

numbsafari wrote: post #38

Earlier quoted context omitted.

I've seen this handled a few different ways. What you do is going to depend on the size of your team and your current business context. Like the rest of engineering, there are few hard and fast rules, you have to weigh the trade-offs. One approach is to prioritize all bugs before all features. This is the Joel Spolsky approach. In a typical sprint-based environment, this basically means that available work effort is…

Yes, small releases are a huge part of making this work. "We can't do short iterations because iterations are so much work!" is the core of resistance. Something's going to go wrong, and we have this heavy bloated religious "deployment" ceremony with ten people on a call for six hours and how on Earth could we do that once a week? Yeah. We can't do short iterations because of all the crap we do because we do long ite…

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 some or all of its resources in fixing that. You probably can't do it over night, but you gotta chip away at it over time at the very least.

If you are looking for justification backed up by real world numbers, I highly recommend the book "Accelerate" by Nicole Forsgren, et.al.[2]

[1] https://a16z.com/2014/04/16/shipping-is-a-feature-some-guidi...

[2] https://www.amazon.com/Accelerate-Software-Performing-Techno...

Re: Agile Lite: Agile without all the burnout

#74

Post by Scarblac » Thu, Apr 04, 2019, 2:45 PM UTC

RandallBrown wrote: post #59

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.

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.

That's making estimates.

Re: Agile Lite: Agile without all the burnout

#75

Post by ryanSrich » Thu, Apr 04, 2019, 2:45 PM UTC

RandallBrown wrote: post #59

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.

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.

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.

Re: Agile Lite: Agile without all the burnout

#76

Post by sidlls » Thu, Apr 04, 2019, 2:47 PM UTC

golergka wrote: post #8

How do you deal with a sudden bug in released version then? Or even bugs in the curent dev branch? All developers time is allocated to new features, there are no openings – so all the bugs are moved to the next spring automatically and we release with criticals? Edit: everyeone's answering with very good advice on how to handle it, but my intention was not to ask for advice for any situation I encountered personally,…

Here's how to handle the situation you are in right now:

1. Work with the team to identify what item in the current sprint will be delayed.

2. The EM and Scrum Master should communicate the delayed issue to their leadership.

3. Identify any long-term objective that will be delayed and communicate that as well.

If there's a question about why a delay will occur be honest: either the critical issue affecting customers gets fixed now, or the new thing customers don't yet have gets attention.

Going forward, allocate 1 day per person in each sprint as capacity to address bugs. Do this explicitly if you have mature leadership who understand how development works, or implicitly by padding other estimates if you haven't. Addressing bugs should be an implied task every sprint. When there are no important and urgent bugs, that capacity should be used to address tech debt instead.

Re: Agile Lite: Agile without all the burnout

#77

Post by viach » Thu, Apr 04, 2019, 2:48 PM UTC

>> It is an intentionally light week and many people may simply take the time off to paint or surf or whatever.

And the next week will be spend on meetings where management is trying to explain to the returned (hopefully) surfers what was decided to implement on the previous week meetings?

And it will turn out something was missed out and needs re-planning?

Another week, another iteration of planning and surfing?

Re: Agile Lite: Agile without all the burnout

#78

Post by beat » Thu, Apr 04, 2019, 2:48 PM UTC

numbsafari wrote: post #73

beat wrote: post #50

Earlier quoted context omitted.

Yes, small releases are a huge part of making this work. "We can't do short iterations because iterations are so much work!" is the core of resistance. Something's going to go wrong, and we have this heavy bloated religious "deployment" ceremony with ten people on a call for six hours and how on Earth could we do that once a week? Yeah. We can't do short iterations because of all the crap we do because we do long ite…

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.

Re: Agile Lite: Agile without all the burnout

#79

Post by PaulHoule » Thu, Apr 04, 2019, 2:48 PM UTC

erikstarck wrote: post #30

PaulHoule wrote: post #5

The key thing people miss about agile (and project management in general) is that you have to tune the process to the situation. If you look at the PMBOK (Project Management Book Of Knowledge) it is really a comprehensive list of all the things you might have to think about while running a project. All of them are relevant to every project (e.g. hiring, communicating with the public) but some need a lot of attention…

This. That is why the retrospective meeting is at the heart of agile. A truly "agile light" setup would be: Every other week, do a retrospective. That's it! On the retro, ask yourself 3 questions (or work with these 3 themes): 1. Is the way we are working helping us, and the rest of the organization, make the right decisions and reach our goals in an efficient way? If not, what needs to change? 2. Is our understandin…

I would say that retrospectives are the biggest waste in agile in my experience.

For one thing, retrospectives often come at a time when everyone has been busting ass for a long time and they just want to go home. If you put it off till next week then it seems like another distraction.

Like the planning meetings, the timebox for a retrospective is often wrong. In some cases things went smoothly and there is a little to say. That is where you should be. In some places you budgeted 45 minutes but there really is a day worth of material.

On top of that in many (most?) firms there is no sense of psychological safety. Often the real message is that the process is 99% bull but you can't say that in a meeting which is claimed to be about continuous improvement but is really about how to rearrange the deck chairs on the titanic.

In his book "Good to Great", Jim Collins points out the use of the word "alignment" is a bad smell. In a healthy organization there is alignment, naturally, built into it. If you feel like you have to paint alignment onto it after the fact you are just causing more misalignment.

Re: Agile Lite: Agile without all the burnout

#80

Post by clavalle » Thu, Apr 04, 2019, 2:48 PM UTC

RandallBrown wrote: post #59

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.

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.

Estimates are always wrong only if they are concrete estimates as if they were certain.

If, instead, they are 90% ranges (I am 90% sure that this will be done between x and y) then it is much easier to estimate accurately. It is also easier to spot bullshit (if the spread doesn't go up as your time to completion moves further from now, it is probably a bullshit estimate).