[root-z]

I worked at a big tech for many years and my team never managed to get Scrum working properly. Every year my team commits a delivering certain product/features at a very specific date (some sort of launch event), so we have to know very early in the year what's all the work required and report periodically whether project is on track. The deadlines are also always on the tighter end. The flexibility of Scrum becomes an issue in that case, because not everyone can deliver the same tasks at the same speed and without careful planning you can easily miss important deadlines.

[lbriner]

You cannot get management buy-in to Scrum or most agile processes unless they can accept the agile manifesto principles.

The whole idea that you can be agile while having delivery dates for things several months in advance is a nonsense. Agile is about doing what is important now, not doing what we thought was important a few months ago.

The best you could probably hope for is Kanban or the never-ending backlog but some people struggle when there is no finish line, just an endless sea of work!

[yyyk]

>The whole idea that you can be agile while having delivery dates for things several months in advance is a nonsense

If Agile truly rejects even the possibility of an estimation (something I'm sure many proponents will disagree with), that would be a problem with Agile and not a problem with the idea of estimation. Companies will de facto pivot away to methods that will give an estimation, even if they're 'bad Agile' and even if software engineers are unhappy about it.

Because there are more useful things to optimize for than efficiency of software delivery or what software engineers like. People really need to know when the works on their street will be done, companies and countries need to plan ahead, and so on.

[convolvatron]

the idea that you can deliver a multi-month or multi-year project without ever looking past the next two week sprint is really misguided.

[sethammons]

We just delivered a multi-year project under Scrum (edit: point of clarification, we did not have a due date). You still have a guiding vision and some idea of the major milestones you need to reach, you still define what the next set of milestones are. You will want several sprints worth of work lined up ready to be more concretely planned. You just do concrete planning for the next sprint or so and work to minimize disruption of that sprint. Learnings being incorporated and plans updated as needed. Work that will yield more understanding should be prioritized.

Not sure where the idea of "only look one sprint into the future thing" came from.

[convolvatron]

the parent -

"The whole idea that you can be agile while having delivery dates for things several months in advance is a nonsense. Agile is about doing what is important now, not doing what we thought was important a few months ago."

I agree with you - i dont think its worth trying to set a date a year out in stone. but you have to do exactly what you say. keep the trajectory in your mind and update it with new information. and and some point turn down the rate of change so you can get some cook time.

maybe I reacted too strongly - but I've certainly been in shops where I try to talk about overall project arc and am firmly told to keep my gaze fixed at exactly two weeks.

[ryathal]

If you have a set date and a set scope you can't be agile. Agile needs to be ale to radically change scope or even cancel projects outright. You can get lucky sometimes that a feature takes less or about the same time as you have and make things look agile.

The flexibility of scrum is being able to say what is done represents a working though not fully featured product. You can generally send red flags a lot faster in scrum, but you still need management that believes and understands those flags.

[dragonwriter]

> If you have a set date and a set scope you can't be agile. Agile needs to be ale to radically change scope or even cancel projects outright.

The thing I think that fails to be recognized about Agile (though there is a lot adjacent to it, without outright calling it out, in the central documents) too often is that Agile has fundamental tension with the project-oriented, and even to a lesser extend product-orient d, mindset, and really calls for a mindset in which technology is an integral component of continuous end-to-end business process improvement. It can be adapted to product- or project-oriented environments, but only with compromise.

> The flexibility of scrum is being able to say what is done represents a working though not fully featured product.

The flexibility of Agile in general comes in rejecting products as a goal to themselves, and recognizing that technology is part of a broader system of delivering value and any improvement in value delivery is worthwhile according to the value delivered compared to the cost of delivering it.