> the date is _always_ more important than the actual deliverable. Always.
Hah! You just gave me an idea for a new methodology. Date-bound delivery.
- The business tells you what they want, as they do
- The business tells you when they want it, as they do
- The team does not say how long it will take. Instead, they say what they think they can deliver in the time allotted.
- As the date nears, more edge features get trimmed
- As the date arrives, something is always ready to deliver, no matter how miniscule
Such a methodology would ensure delivery, but not necessarily the contents of that delivery. Post mortems would no longer discuss why something took so long, and instead would focus on why features were cut.
If, as you say, the date is always more important, wouldn't such a methodology be worth trying?
A startup I worked for twenty years ago used that approach: we shipped an update once a quarter, every quarter, no matter what. We'd begin with a week of planning, build as much of the plan as we could, then cut anything we hadn't finished and release whatever was left. Of course the trick was to build the high-priority items first.
I loved it and I think it was one of the more productive development methodologies I've ever seen. It made sense, it was honest, it required no heroics, and it improved our long-term design work by forcing us to break every grand plan down into a series of incremental deliverables.
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.
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.
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.
Yep I agree. Iterations are still good, demos are still good, ever-evolving scope discussions are still good, regardless of the overarching methodology.
As others have said, this methodology exists in various forms already.
It has a major practical problem:
> The team does not say how long it will take. Instead, they say what they think they can deliver in the time allotted.
If the team doesn't think they can deliver something that the business feels is non-negotiable, the two are at an impasse. The methodology gives no way to resolve this impasse.
And this problem is exacerbated because the business will frequently be wrong about what they want and when they want it by, and the team will frequently be wrong about what's achievable by the given date. And both parties know this, and it starts to affect how they interact with one another when discussing dates and deliverables.
And to make things even more confusing there's often some amount of unacknowledged deception. Sometimes when the date arrives everyone collectively just pretends that the thing has been delivered in full. Because it doesn't actually matter whether it has.
> Such a methodology would ensure delivery, but not necessarily the contents of that delivery.
But sometimes/often it doesn't matter that you delivered 70% by the agreed date, since less than say 90% is useless.
We have an upcoming deadline. By a given date, some government system shuts off and another must be used. By then the customers must run functionality tests to prove their software handles the new system.
If all of those tests don't pass it doesn't matter that we got most of them by the shutdown date. Customers won't get access to new system and their production halts, not acceptable.
Hah! You just gave me an idea for a new methodology. Date-bound delivery.
- The business tells you what they want, as they do
- The business tells you when they want it, as they do
- The team does not say how long it will take. Instead, they say what they think they can deliver in the time allotted.
- As the date nears, more edge features get trimmed
- As the date arrives, something is always ready to deliver, no matter how miniscule
Such a methodology would ensure delivery, but not necessarily the contents of that delivery. Post mortems would no longer discuss why something took so long, and instead would focus on why features were cut.
If, as you say, the date is always more important, wouldn't such a methodology be worth trying?