4 ms·
Why do I 'defend' agile? I guess... for one thing, I have, multiple times in my career, been part of technology organizations that have positively transformed
by jameshart 6y ago
Why do I 'defend' agile?
I guess... for one thing, I have, multiple times in my career, been part of technology organizations that have positively transformed their relationship with business stakeholders by getting the business to buy the underlying truth: building software is a learning exercise; the requirements can and will change.
And the frameworks you have to put in place to make that kind of relationship work, to replace the arbitrary deadlines and deathmarches? Turns out 'agile practice' has a bunch of useful ideas for those.
Teams have limited capacity for 'work in progress'. The upcoming work can be prioritized on a backlog. Loose sizing estimates can help us make decisions about trading off time and features. You can only have one top priority at a time. It helps to let teams understand what problem they are trying to solve, not just tell them to implement a piece of a solution.
That's what I value when I talk about 'agile'. A bunch of useful ideas stolen from scrum and kanban and lean and so on that actually help put developers in a position to solve the right problems in the right way, and get 'management' off their back.
I'm also a fan of daily planning meetings to facilitate collaboration inside teams. I like retrospectives as a way to identify ways for teams to improve how they work. I like short fixed-duration iterations which deliver working code. I like pairing on problems. I like continuous integration and deployment and automated tests written alongside the code. Those are good practices that we, as a small team of developers, can use to help one another do good work, and ship working software.
And those ideas are all also stolen from things like scrum and XP and TDD and devops, which are also all 'agile' practices.
If someone tells me they don't like agile I am confused because... I don't know why you wouldn't want to work on teams that follow those kinds of practices.
I do get that plenty of people have been subjected to environments that use things with the same names as these things in ways that aren't remotely agile. But throwing out the idea that daily standups are a good idea because you've been subjected to a bad implementation of them is like saying you never want to use a programming language that has strings because PHP's string coercion sucks.
I find these practices helpful, and better than not following them. I've been lucky to get to enjoy working in environments that use them, rather than have them badly forced upon me.
- ericbarrett 6y agoThanks for the detailed reply! I have to say, everything you wrote sounds great. We'd probably agree on more than we'd disagree. That said... > But throwing out the idea that daily standups are a good idea because you've been subjected to a bad implementation of them It's not that I've been subject to "a bad implementation." It's been multiple, across a decade, ever since Scrum became a thing, really. Disaster after disaster. I'd also add that most of the effective engineering I've seen (aside from the occasional uber-productive solo code artist) had clear priorities, effective intra- and inter-team communication, and certainly a disciplined retrospective process, all without Agile or Scrum. In the best cases it was self-organized, because we wanted to do good things for the sake of doing good things, and management understood we were trying to do the right thing, and got out of our way when we were being effective. When we weren't, it was a conversation, not school-time lockdown. I don't think that environment can be replicated by process or fiat, which is what the formalized Agile/Scrum of today seems to try (leaving aside the more cynical cases).
- jameshart 6y agoSo let me put it this way: Most businesses do not know how to manage software projects. That's not entirely special to software - most businesses don't really know how to manage anything. Agile tools offer a framework for technical teams for fighting off and thwarting crappy management that doesn't understand how to make software. But some crappy management organizations are really, really hard to thwart. Worse, some crappy management organizations have figured out how to neutralize agile tools, by co-opting them and trying to use them to continue crappily managing the software project. Sometimes they do this pre-emptively, neutering one of the only tools a technology organization has to fight back. I would love to know what else people have had success with as a way to fix crappy management other than setting up a properly agile 'safe space' for tech to happen in.
- ericbarrett 6y agoThis makes sense and puts it in a slightly new light for me—as a way of salvaging some productivity, when run by the developers, Agile/Scrum would certainly be better than many alternatives. I guess that’s what we did in my earlier reference, about 16 years ago. I wish it hadn’t become so coopted by the usual suspects.
- junon 6y agoThis reads exactly like someone who's never been on the development-end of an agile team. You could have said you copied this from some promotional material for an Agile consultant and I'd believe it. Really your only argument is "those companies didn't do it right", but the problem is that if agile is so hard to do correctly then doesn't that mean there's a problem with it?
- jameshart 6y agoWeird, because it was written by someone who's been a working software developer for 20 years and who has so far successfully resisted getting shoved into a hands-off-keyboard management role...
- junon 6y agoThen you've been lucky. Good for you!
- jameshart 6y agoWe’re hiring
- AnimalMuppet 6y agoContact info?