3 ms·
Two situations that Agile is great for: 1. You're a contracting house, your clients are hopeless, and you just want to start billing hours, and keep billing ho
by neilv 2y ago
Two situations that Agile is great for:
1. You're a contracting house, your clients are hopeless, and you just want to start billing hours, and keep billing hours every 1-2 uninterrupted weeks of peace. Clients saying something different every 1-2 weeks is no significant harm done, since you don't have to care, you just want to keep billing hours.
2. Possibly in-house rather than contracting, stakeholders and developers collectively have little idea what they're doing, whether in the problem/system domain or in process, so planning is mostly pretend and counterproductive, and best minimized. Just do something now, and everyone will quickly see whether it looks in the right direction. And where this model breaks down, you can duct tape it with firefighting meetings that have some people looking like heroic decisive leaders with a bias for action (win).
That's fine, but these people should quietly enjoy their Agile, keep their heads down, and stop trying to evangelize Agile to people who don't have (or are getting rid of) either of the above two dynamics. Also, if they find themself saying "Waterfall", that's probably a reminder that they've accidentally started evangelizing, and in a parroting way.
- badgersnake 2y agoI think what you're trying to say is that there is no one development process that fits every situation because all situations are different and thus what you need to do to have a successful software project is adapt the process to the business and do what works.
- deleted 2y ago[deleted]
- pyrale 2y ago> these people should quietly enjoy their Agile, keep their heads down, and stop trying to evangelize Agile to people who don't have (or are getting rid of) either of the above two dynamics. I disagree. I've seen more than my fair share of people signing on "big" IT contracts that promise nothing except specifications before Y+2 or Y+3, and these people need to see the light. To date, I have never seen any multi-year software project that doesn't start delivering early land softly. And whenever they crash, it's the teams that suffer.
- neilv 2y agoOK, they should limit themselves to evangelizing to dynamics #1 and #2. Something like: 1. "You people only care about billing hours, and Agile is how you do it nicely." 2. "This/these organizations are systemically incapable of coordinating effectively on something like this, so Agile is probably your best bet for eventually reaching a passable solution, and reassuring people in the meantime."
- tboyd47 2y ago3. Hot shot VP in non-software company starts a small in-house software team that immediately has to manage multiple small/intermittent software projects where the product owners are half not paying attention / half don't care, and the team just wants them in the room at least once or twice a week. This drama has played out in almost every company over a certain size in America I'm sure