Hacker News Reader

Comment by vegetablepotpie | Hacker News Reader

The reason agile came to prominence 20 years ago was that responding to change was more valuable than sticking to a plan.

And yet, this feels more relevant than ever. Agile has been thoroughly taken over by management and consultants. We might have some new tools and phrases, but behind the facade it’s all waterfall. And that comes with sticking to the plan with the caveat that certain special people absolutely can change the plan, in some cases very quickly and dramatically. Having something empirical to point to that maybe that reduces productivity is absolutely a positive.

View on HN

> but behind the facade it’s all waterfall.

That is to be expected, because "waterfall" or pipeline is the general structure of work. At the very least you have design, production and verification steps.

Agile is not about removal of waterfall, but rather applying 1. waterfalls to small chunks of work 2. multiple "tiers" of waterfall. The mythical waterfall that many pseudo-agile proponents argue against is simply one giant waterfall applied to the whole project. If you start building image manipulation software you generally do not pivot to building a presentation software without redefining or scrapping the "master" waterfall. Stages of the whole project generally do have dependencies on other stages, there is no way around that.

As long as you have at least some visibility into the project you are going to have stages and checkpoints and in the end a "waterfall" will surface somewhere. Waterfall is at the core a way to represent staged/checkpointed work.

> 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.

I've done agile projects where the client was a big corporation. There was a fixed budget and deadline, but we specifically reserved some of that time/money for unspecified work at the start of the project. In the latter parts of the project we could then prioritise the work that was deemed most important by the client once they'd already seen the work in progress.

I suspect it took quite a bit of work by our project team to convince them to work this way. But it's really great if you make it happen.

> I suspect it took quite a bit of work by our project team to convince them to work this way.

It probably did. I've seen a couple of organizations that did this well, but the majority did not, unfortunately. In the end the sales guy will usually have received their bonus far before the project is over. I'm mostly amazed that companies like this can keep running for decades, but they do.

> "predefined scopes, deadlines and budgets"

That's all 3 legs of the "iron triangle" (https://en.m.wikipedia.org/wiki/Project_management_triangle). At least one too many.

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.

In my many years of software, I've come to the following conclusion: The "worst" process followed consistently across all levels of a company will always outperform the "best" process followed haphazardly with no real buy-in.

The reason agile fails at so many companies is that Product and Leadership don't want to do the hard work of keeping an up to date rank ordered list of groomed and deconstructed work that provides the greatest value to the business. Agile is about progress and learning and using that new information to decide what to do next.

At my current company we are using SAFe, where you plan 3 months of work at a time which is the complete opposite of being agile. Again, it asks the wrong questions. It asks "What are we committing to during this PI?" instead of "What is the most important and business value adding tasks we should be working on?" Leadership only wants the answer to when it will be done but that is up to them. It will get done as soon as they make it the highest priority thing.

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.

Managers with half knowledge and semi sincere attitudes have tried to pull "agile means you need to be flexible" on my team. To force a scope change and brand new stories in the middle of a 2-week sprint. The same folks would not accept any explanation whatsoever on why some stories didn't make the sprint delivery -- even if the blockers were completely in their court.

These buzz words just become intimidation tools at times. A junior team member cannot say it to their face that Agile doesnt mean what they think it means and should learn things before they speak.

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.

> 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.

Sprint duraration is supposed to be flexible and adjusted to each project type and yet everywhere I’ve been workint at it’s always 2 weeks

It's very true, but to get agile to work well, I found you need quality senior people at every levels. Otherwise, gateways come in place to make up for the lack of experience... and you wind back in the waterfall hell scape.

Also a lot of people have taken in agile and bastardised it. They kept the keywords and love it in business speak, but won't let a sprint run without putting their hands on everything and everyone, destroying the actual velocity of the said team. And that is I think why so many people now hate agile. We went from increased engagement and transparency to impossibility to concentrate.

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.

I had one assignment where we had a Scrum Manager. He was a project manager who was also the scrum master. Luckily he was aware of the conflict in these roles, so he took my criticism well and was later replaced by an actual scrum master.

An amazing comment about the difference between agile and waterfall: https://news.ycombinator.com/item?id=29458652

Still the best comment I've seen on the topic.

Thanks for sharing. Loved it.

It's hard to create something innovative or new using agile. Things always seem to turn into a feature factory.

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!"

Plenty of managers do lack vision and direction (often feels like the norm) so it's not surprising that they lack creativity when it comes to assigning work to be completed within a single sprint. If they were free of that self-imposed creative barrier, they may be better positioned to develop an overall strategy.

Reply on news.ycombinator.com