Hacker News Reader

"But most teams aren't great"

Most teams work hard enough to become great. Most teams work long enough hours to become great. Most teams are smart enough to become great. Most teams even have the desire to become great.

So what is stopping them?

At the developer level: Lack of autonomy, lack of purpose, and lack of mastery. These issues aren't fixed by Agile.

At the management level: High turnover. Lack of attention/focus on things that aren't easily measurable. Lack of leadership. Constant arbitrary deadlines. A short term focus. Politics. Again, none of it fixed by Agile.

This is a great insight, and describes some of the projects I've worked on exactly. I think a fix to these two problems is to hire great developers that you can trust, and give them much bigger tasks. I find that the management breaks things up into too small of tasks so that they can measure it, which creates a bottom up approach, and that's just not how good software works. I prefer the top down approach, which means design the code from a high level (architecture, components, overall structure) then drill down and build the different parts.

I'm not sure what your argument is here. Because the classical model failed agile can't fail too?

I think you're also misunderstanding "great teams". I at least do not mean a team of great developers, but a team that works well together. It's a great team, not a great group of developers. You can have the best developers in the world, it won't work if they can't stand each other.

The "argument" is that making software is an ugly, brutish affairs in virtually every case, with virtually every approach. There are extraordinarily few cases throughout history where a team converged, looked at the problem, built a solution, and voila, everyone emerged happy. In the real world there is always a discord between requirements and reality, skillsets and the problem space, change management and the need for rapid change, scope creep, and on and on.

It is the story of every software project everywhere throughout time.

But invariably the comments will fill with tales of woe with agile (usually with people betraying a complete lack of understanding of it, as an aside, such as seen with most uses of the term "scrum" throughout these discussions. It serves as the canary in the coal mine when noxious gases are afoot), as if troubled projects are some unique reality of agile. They're a reality of every single methodology. Agile merely tries to help reduce a few of the bigger and most deadly issues, which are friction with the business (the ability to adapt to change), and enormous investments of time and money to a project that ends up being a solution to the wrong problem. It doesn't suddenly make everyone cooperative and great.

As to my "misunderstand", so the solution as you see it is just to have developers that work well together. Easy peasie solution.

Once again.

> Because the classical model failed agile can't fail too?

> so the solution as you see it is just to have developers that work well together. Easy peasie solution.

No one said it's easy. No one said you can just have it. No one claims it's the solution to how we build software.

> usually with people betraying a complete lack of understanding of it, as an aside, such as seen with most uses of the term "scrum" throughout these discussions

Why don't you just tell me you think I completely lack understanding of the subject matter?

The beauty of Agile is: if you question or criticize it, you don't understand it; if it didn't work for you, you didn't apply it properly; if you applied it rigorously and it failed, you didn't have a deep understanding of it. Was it Sartre who said "it is what it is not"?

Agile is not an "it", agile is not static. Application of agile principals means guiding and improving development processes. This is not a damned if you do damned if you don't scenario. As the article suggested, you have to "inspect and adapt". If something did not work for you, then capture the results, perform a lesson's learned, and try again.

To say "apply agile methods", is to apply a nimbleness of the mind. This is where not everyone "gets it" right away. If someone suggests a paradigm shift from what you as a developer are accustomed to, you may very well fall flat on your face. But to apply agile methods means to be able to get back up and try a different approach.

The very definition of agile seems itself to be very "agile" and constantly changing depending on the discussion.

You've created a strawman to attack by citing waterfall.

Stop citing waterfall as the reason for agile methodologies. It's like citing the lack of evidence for a christian God as the reason Science exists instead of pointing out how effective science has been in helping us control our environment.

And if you can't describe how effective Agile has been, then have you no reason for your opinion outside of religious views. Which is ok if it works for you, but don't attack a strawman as a way of dismissing other people's experiences.

Speaking of strawmen, where did I cite waterfall? The entire foundation of your post is a fiction.

Software is tough. It is always, and has always been tough. The same flexibility that is the great benefit of the domain is also its curse. This is true across any methodology, so try not to project your own hangups into that statement.

Agile is something that some shops try to do, imperfectly, against that reality. Every one of these angry anti-agile comments seem to opine that agile is terrible versus some mythical alternative that is shapeless and amorphous, boiled down to "have a great team". That is, quite simply, nonsense. It is the pat solution of the bottom feeder.

Religious views? Again, the entire foundation of the anti-agile screed, which is generally by people with a chip on their shoulder (and they probably had a chip on their shoulder about everything that people with more influence over them got adopted) is that it is deficient compared with an unspoken, unstated alternative.

And I'm the one bringing religion in this? Christ.

I may have responded to the wrong person (or you've edited your post) as the post I meant to respond to was most definitely comparing waterfall to agile.

It's very common for agile proponents to push Waterfall as the necessary alternative to agile, but that's a logical fallacy.

> In the real world there is always a discord between requirements and reality, skillsets and the problem space, change management and the need for rapid change, scope creep, and on and on.

We follow Agile. At the beginning of iteration planning, the dev-team, has to task-out the items and score the complexity, and then decide the cut-off point as to what can and cannot be achieved within the 2 week iteration.

It's taken us several years, but this ruthless cycle of feedback, and responsibility has led us to a point, where we scope it right about 75% of the time.

Having also been involved in projects that have overrun deliverable dates by years - I wouldn't have believed it possible for a software-management process to work so well.

Of course it helps, that there is genuine philosophical buy-in, and that our revenue is derived from our software (eg. we're not a cost-centre).

None of the people who complain about agile offer any viable alternatives. I get the impression that these are developers who simply hate being managed period, and would prefer that management never spoke to them at all.

I certainly wouldn't mind if the middle manager that had an hour long meeting today never spoke to me again. The first slide was MLK with "I have a dream" which then continued onwards with 15 minutes talking about how to move post-it stickers on a whiteboard and 15 minutes spent doing a failed analogy between a GPS and continuous reevaluation of when the next release will be done.

At the same time, management has decided to have a release cycle that is 10 months (or in reality after the inevitable delays: 12)..

Because there isnt a one size fits all approach that works well. The most effective project I have worked on had ~15 hours of meetings every week.