undefined | Better HN

0 pointsparasubvert2d ago0 comments

that's really what agile was supposed to be. at least in the places where I saw it was successful.

every week, something is delivered, and is demoable, with approved tests from the business. That thing represents the most important thing to the business relative to the risk prioritization from engineering & usability prioritization from design.

every week, priorities can adjust, etc. and the cycle continues. hitting the actual 'release date' becomes much more knowable when you see the tangible date-driven progress on a regular cadence.

0 comments

MetaWhirledPeas2d ago

Yes, but expanded to the full deadline instead of only the short iterations.

The business does not care about week long deadlines. They need something on May 23 so they can achieve _______.

My understanding of Scrum (not representative of all agile, I know) is that the velocity is supposed to be tracked and used for better predictions. In my experience this takes a very dedicated core of people who are intent on making it happen. In other words, usually it doesn't happen.

But date-bound delivery is already our default mode of operation. We just don't like to admit it. We are going to deliver something on this date; we just don't know what, yet.

parasubvertOP2d ago

I completely am in favor of date-bound delivery.

However the point of the weekly cadence is that the business does care about adjusting scope and priority towards hitting that deadline on May 23, so that they know what they're going to get on May 23 and have the power to adjust it.

Especially if the goal of what is delivered on that date is not clearly defined. It almost never is.

Most projects can be summed as "give me $X, I'll come back in 6 months, and ask for more time and money". or "here you go"... "that's not what I wanted".

It's a key risk mitigation toward a hard date to know every week if you're still getting what you wanted.

Velocity is overblown as a metric. It's one metric among many that can signal a few things (e.g. quality problems because bug fixes are overtaking features) but isn't as much of a lever as some say.

MetaWhirledPeas2d ago

Yep I agree. Iterations are still good, demos are still good, ever-evolving scope discussions are still good, regardless of the overarching methodology.

j / k navigate · click thread line to collapse

0 pointsparasubvert2d ago0 comments

that's really what agile was supposed to be. at least in the places where I saw it was successful.

every week, priorities can adjust, etc. and the cycle continues. hitting the actual 'release date' becomes much more knowable when you see the tangible date-driven progress on a regular cadence.

0 comments

MetaWhirledPeas2d ago

Yes, but expanded to the full deadline instead of only the short iterations.

The business does not care about week long deadlines. They need something on May 23 so they can achieve _______.

But date-bound delivery is already our default mode of operation. We just don't like to admit it. We are going to deliver something on this date; we just don't know what, yet.

parasubvertOP2d ago

I completely am in favor of date-bound delivery.

Especially if the goal of what is delivered on that date is not clearly defined. It almost never is.

Most projects can be summed as "give me $X, I'll come back in 6 months, and ask for more time and money". or "here you go"... "that's not what I wanted".

It's a key risk mitigation toward a hard date to know every week if you're still getting what you wanted.

Velocity is overblown as a metric. It's one metric among many that can signal a few things (e.g. quality problems because bug fixes are overtaking features) but isn't as much of a lever as some say.

MetaWhirledPeas2d ago

Yep I agree. Iterations are still good, demos are still good, ever-evolving scope discussions are still good, regardless of the overarching methodology.

j / k navigate · click thread line to collapse