The emotional roller coaster of changing requirements

> you generally do not pivot

I'm just going to grab this tiny part and focus on it. I've seen Agile fail many times for this exact reason. In start-up land, one might pivot and massively change an end goal. In corporate land that's a lot less off a thing.

I've worked on some big projects in government and fortune 500, all of them pretended to be Agile and all of them had predefined scopes, deadlines and budgets. In all of those projects, Agile was more of a disturbing factor than anything else. The only flexible part was the scope of work, because of renewed insights or lack of specification while planning. This always ends with teams getting pressured to make deadlines (because those are never flexible), so they cut corners and work extra long hours.

I think it would be much better for these types of projects (and the sanity of devs) not to pretend to be doing Agile, but just admit they want a more Prince2 led Waterfall approach. This won't happen though, because that puts the pressure with management in stead of the dev teams.

My argument is that the things that waterfall specializes in, which is managing stages of work and dependencies between work is actually insignificant to the success of projects people care about.

Waterfall is good when you are building structures. But value exclusively comes from the integration, verification, validation, and deployment of structures. With these types of tasks, the variance in estimates exceeds the mean of those estimates. Effective workers constantly probe different pathways to success and this makes your project network, with its delineated stages and strict dependencies, totally divorced from reality.

The outcome of knowledge work, is knowledge. Not story points allocated, not dollars spent, not time used. The best hope of having a project management approach with valid predictive power is to track knowledge earned and not EVMS metrics satisfied.

>The mythical waterfall that many pseudo-agile proponents argue against is simply one giant waterfall applied to the whole project.

It's much rarer than it used to be but it is far from mythical.

Companies that are used to planning projects like this (e.g. construction) often have managers who apply the same mindset to software and are frequently almost incapable of considering that there is another way.

SAFe doesn't require planning in 3-month program increments. The methodology is flexible and allows much shorter planning horizons when appropriate such as when the team is small and requirements are in rapid flux.

I think everyone understands that running long program increments isn't ideal from an agile development perspective. However, sometimes it is the least bad option for the enterprise as a whole. There are often a variety of program stakeholders outside the core team who can provide valuable input but aren't always available. It's a lot more practical to pull in everyone for two days of focused PI planning than to try to chase them down and schedule meetings on demand.

Back when I was a software manager, I had to sequence work into sprints or everyone (up and down) would freak out. The part I relaxed the team on: I didn't care at all if work spilled over into the next sprint. This alone removed the stress of adding mid-sprint activities (which obviously needs to be done from time to time for at minimum reactionary purposes) and allowed more thoughtful medium-term analysis and execution. I was still on-time for delivery (at least above par on delivery timelines compared to sister teams), but with much less burn-out and generally more favorable ratings and well-constructed systems.

The thought that any meaningful work (including components of meaningful work) would naturally fall within a 2 week period of time has always baffled me. That said, I have always been very good at identifying critical paths, minimal requirements, and estimated effort; I'm not sure if this strategy would work well without sufficient planning.

Whenever I join a new company, I encounter this phrase sooner or later:

> This is X, project manager. But we actually call her/him product owner because we do agile.

Thanks for sharing. Loved it.

Agile has nothing to do with it. That just sounds like lack of general vision and direction. Or complete misunderstanding of Agile. "We have only two weeks, so we can't undertake anything big that spans multiple sprints!"

That attitude can help. (In fact, I think it's pretty close to essential for maintaining your mental health.)

But I still prefer that my code be used, not just thrown away. I want my work to matter for something, for someone, not be just a paycheck. In the short run, sure, things get thrown away. Over a long time, I'll gravitate to situations where my work is used.

> At the end of the day you should shrug, warn of missing deadlines (if that doesn't change their mind) and start again on the new requirements.

Be sure you warn in a way that leaves a paper trail. You're going to need it to protect you from the higher-ups trying to blame you for missing the deadlines.

^^^ This.

If I do a weeks work on getting a feature ready, and then product decide to change all the requirements around and it needs redone. Why do I care ? I still get paid for that weeks work...

Next week I'll rework the requirements, and I'll get paid for that weeks work too!

Hot-take: Agile is for service work, where the customer can't explain the problem very well yet, and you can take the reputation damage of showing half-work. Product work should have some amount of discovery, but derisked by user research (and thus is more waterfall) and thus will be released polished.

> Trying to 'kill the old ways' without understanding them is how we get junk such as Scrum.

You can hardly do better in understanding the "old ways" than reading Royce's paper. And the difference between Waterfall and Agile is not just iteration, it's rapid feedback. As noted in Royce's paper, Waterfall is inherently one way, hence the name. You don't see water flowing uphill, at least not without a lot of external force. Agility means feedback comes at every step of the way, not just at the end, when testing.

This is also the difference between what's been called "the Toyota way" vs prior automobile manufacturing. In the traditional automobile factory, the car was put together and completed, then a team of engineers would exercise it to find and fix defects. The Toyota was was to find and fix defects along the assembly line, and perhaps more importantly, learn from defects found during assembly to prevent or reduce defects before they appear.

The same applies to Waterfall vs. Agile. Instead of completing the entire system and then testing it and fixing defects, as waterfall would have, even when done iteratively, agility works out the defects in every aspect and uses what's found to reduce the rate of defect creation.