Hacker News new | past | comments | ask | show | jobs | submit login

I was prepared for our weekly "I Hate Agile" post, but this one is actually really great. It's a lot of the arguments I make to Agile haters. The fundamental problem that drives most agile failures isn't in the team's execution, it's in the business' expectations. One side is signed up for incremental delivery, and one side is set up for a fixed scope and deadline and the result is misery. I think this article makes a lot of good points. Scrum isn't the complete answer, but it's a big step in an organizational transformation. I think it's suffered a lot from being oversold.



> One side is signed up for incremental delivery, and one side is set up for a fixed scope and deadline and the result is misery.

This is a brilliant summary, thank you.

The best 'agile' experiences I've had are situations where the 'clients' are directly involved, often within the same organization. Instead of a hard scope or deadline, there's just a shared interest in producing a valuable product efficiently, and the users are on-hand throughout the process for feedback and reevaluation.

The worst experiences have been waterfall contracts, developed by an internal simulation of agile. The software team does frequent "releases" to business or management, who provide feedback and feature requests, but the actual recipients are uninvolved outside of occasional demos, or contacted only indirectly by non-programmers. The result is almost always thrashing, with time and effort spent pointlessly satisfying the forms of agile even though the real timeline and customer feedback are unyielding.


In large enough orgs, internal clients can end up being just as bad as external clients, or even worse since they have a direct line to your PM, can track your feature board, etc. yet there is basically no sense of camaraderie or shared goals.

I'd say generally IME they are still preferable, but occasionally can be more painful.


> waterfall contracts, developed by an internal simulation of agile.

We call this wagile


I just call it agile. It’s the common form.


We call it scrummerfall.


We call it frAgile.


I agree entirely!

I often sit between the business and tech orgs, so the way I explain it to the business is this: I can get you detailed status reports and metrics, but they will slow progress and be expensive. So think about why you need that information: if there are legitimate business reasons with dollars attached, go for it. If it’s just to soothe your anxiety about the timeline, a therapist will be far cheaper and more effective.


“One side is signed up for incremental delivery, and one side is set up for a fixed scope and deadline and the result is misery.“

That's just one example of the general value I like to ascribe to "AINO": it gives you a useful mental model of the delta between what you have and a known good process, making it quite easy to name the missing pieces. This usually doesn't make it easier to actually fix their absence, but at least you know where to start with damage mitigation. When waterfall fails, you just throw your hands in the air and say "more of the same".


Actually, I think Scrum is just a first step to give the development team some autonomy to create a bubble in which it can play by its own rules. AFAIK, mediating between the development team and the expectations of the management is the job of the Scrum Master [1]:

> The Scrum Master serves the organization in several ways, including: > ... > - Helping employees and stakeholders understand and enact Scrum and empirical product development;

So, I am not saying that it is an easy job. Many managers just hear what they want to hear, so it can be quite difficult. But if your team has such issues, be sure to support your Scrum Master with good arguments to help him make managers understand what it means to use Scrum (and become Agile).

[1] https://www.scrumguides.org/scrum-guide.html#team-sm


The author (https://medium.com/@charles.lambdin) has a whole series of blog posts on this and similar topics, a very interesting read.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: