Hacker News Reader

Comment by JamesBarney | Hacker News Reader

This is why I hate Agile. It's much harder to convince management that they won't be getting a pre-determined set of functionality by a certain date (we will have feature x,y and z developed by October 13th) than to convince a team to stop doing upfront planning and design. So almost every project I've been on that was "Agile" was actually waterfall sans upfront planning and design.

View on HN

My understanding about Agile is planning ahead for the next step instead of planning the whole project before starting and then hoping all your assumptions turns out true.

The product owner will create and prioritize the stories in the backlog(plan), the team will discuss and break down a story into actionable and weighted tasks(more planning), then they will fit those tasks into the sprint based on their previous performance(even more planning!)

I think the business concept missing from Agile is investment/ROI and risk. Until budgeting processes are also Agile, everyone will be operating on the idea that "we paid $x to get 'y', and now you aren't giving us 'y'. What the hell?"

Agile works (when it works) because it treats software as a complex system that is best studied and modified through experimentation after accepting a high initial degree of uncertainty (which is slowly reduced through the creation of knowledge). The only comparable things in business terminology are investment and risk. Each iteration (I hate "sprint") needs to be treated as an investment with some risk percentage of failing completely. Until the money is handled that way, business people will keep expecting to get exactly what they think they're paying for, exactly when they feel they were promised they'd get it.

> I hate "sprint"

Me too. It sounds exhausting.

Uncle Bob has the best quote on this subject (in Clean Agile): "A software project is a marathon, and in a marathon you don't want to sprint."

What if the term "sprint" only applied to the final integration, testing, deployment, and validation phases of feature development?

Right and the fundamental issue is that the next step in agile is an iteration which occurs over 1-4 weeks. But most companies "iterations" are quarterly or yearly. So every quarter or year the business plans and discusses what money they want to spend and what they want to spend it on. And quite reasonably executives are going to want to know what they are purchasing with that budget allocation.

I think this is where the "beyond budgeting" movement comes in.

See: https://bbrt.org/what-is-beyond-budgeting/

The key in communicating is that you give a roadmap, but not put the date into the sand.

Following the idea of the iron triangle, with Agile we fix budget and time, but we keep the scope flexible, however, we estimate a scope and refine that along the way.

If you follow an iterative Agile approach like Scrum, given you know your velocity and you have a backlog in good shape, you can work from one milestone to the other.

I'm sure some upper management is fine with "we will work on these features and some of them will be done by December."

But in a lot of organizations upper management asks middle management when those features will be delivered so they can plan client communications or internal teams around that.

IMO, the core principle of agile is “early feedback means smaller corrective action”. Everything else is just process to achieve that without running afoul of the evil twin “noisy feedback means constant corrections hunting for the solution.”

Agile goes wrong when you don’t get and use good feedback.

You do upfront planning and design, but you only do enough to establish your general course of action. Because good feedback requires context about your goals. If you don’t care where you’re going, then any direction will get you there.

who said to skip upfront planning?

I don't know many agile teams that plan and design and estimate the next 3-6 months of work.

It's my understand that would not be considered agile.

I think I just realized the crux of why some folks dislike agile but weren't able to express it and it has to do with the idea of what-is and what-isn't and how much dominance the "isn't" has over the owner of the belief.

If someone tries to get you to believe something and part of that belief is the active suppression of certain types of thought, and those types of thought are what actually make us intelligent. Then in some regards, agile is trying to make us less intelligent. It might be accidental, it might be unintended, but it is there. Agile attempts to create a social norm where certain thoughts are banned. Yet our ability to anticipate and predict the future is one of our largest defining traits.

There are some aspects of agile that have cult like qualities. I think agile has _improved_ many software teams and projects, esp with how those teams approach planning, but it is still important to be cognizant of thoughts that have been removed from view.

Reply on news.ycombinator.com