Hacker News Reader

Comment by CharlieDigital | Hacker News Reader

This document, I think, cuts right to the heart of it: if you're not talking to the actual users -- the ones with the pain point you're ostensibly solving with your software -- you're probably not agile because the feedback loop is too long. And because the feedback loop is too long, it becomes costly to make changes (because time is cost) so you end up back at waterfall to mitigate those costs and risks.

My conclusion: it's probably impossible for any sufficiently large organization to truly be agile.

There are too many fiefdoms obfuscating the product team from the users.

View on HN

I don't think it's the organization size at fault, I think it's a culture of controlling information. In defense contexts, the "customer" puts out a list of requirements they want satisfied and expect the bidders to stick their head in the sand and not ask further questions. How could you possibly be agile in that environment?

> How could you possibly be agile in that environment?

You couldn't. There are a lot of real-world scenarios where you can't be agile. For one, it suggests that it won't work if you don't have motivated individuals. There aren't enough motivated individual developers to go around, so someone is going to get stuck with unmotivated individuals and won't be able to be agile.

Such is life. It is not some kind of commandment. It's okay to not be agile.

Back when we weren't doing Agile, I was talking to my users.

I did watch their patterns and habits via the logs, especially when switching systems, because the question "How was this system actually used?" is dreadfully important. But sometimes I would see a student using something I had made and would point blank ask them about their experience. Is this reliable? Is this okay? Any problems?

And, you know, there are times when saying "I wrote this, I will come to your office and see what is going on" is very valuable when surveys aren't. "They" tried to stop me but I ignored them, because playing a game of telephone with errors is complete trash.

> This document, I think, cuts right to the heart of it

I think that's the big strength of this document: it identifies the top priorities for the project, and hard-and-fast rules to judge whether those priorities are met.

A lot of presentations about agile are vague and open-ended. I like a document that says "if you're not doing X, you're doing it wrong", I wish that writing style was more common.

I think a large organisation absolutely can be agile... but you will have to rethink what organisations are and how they work, dispense with things like orgcharts, and the way that power works and think about the underspecified parts of agile - i.e. strategy, team coordination and so on. The book Team Topologies outlines something that looks very much like it tbf...

Reply on news.ycombinator.com