5 ms·
This meme that "Agile is evil", needs to die. No, people, you've just had really bad managers who don't know how to manage software engineering teams. SCRUM is
by PaulRobinson 2y ago
This meme that "Agile is evil", needs to die. No, people, you've just had really bad managers who don't know how to manage software engineering teams.
SCRUM isn't agile, it's SCRUM. Kanban isn't agile, it's Kanban. Doing something that has lots of process but that isn't waterfall isn't agile just because it isn't waterfall - it's a thing with lots of process.
Agile is about responding to the context of the team and the customer. You probably need a way to keep track of what needs to be done, and have regular updates about blockers and progress, but that's it.
The problem is if you ask people who have never been software engineers to manage a software engineering project, they're going to struggle to communicate, because they have no natural intuition of what the hell is going on. The project management industry is quite happy to serve these people by inventing big complex processes to keep them busy and sell them books, courses, certifications and conferences.
Most of big tech won't allow someone to manage an engineering team or project manage those projects without a good amount of hands-on engineering experience. The rest of industry needs to pick up on this.
People without that experience can learn. But they should adapt to software being what software is, not try and bring processes derived from those invented for other domains to software.
Agile done well is absolutely amazing, when its in the hands of teams who have all built software, understand their customer problem and the milestones they need to hit (yes, deadlines are unavoidable in any modern business environment, sorry), and each other.
Trust me, I remember when waterfall was the way. Waterfall is so bad, that even when you do 2-week long waterfall sprints (waves at SCRUM), it feels awful.
Go back to the Agile Manifesto [1]. It's all you need. Keep track of what was decided or discovered (bugs, features that are needed, and so on). If you have regular bottlenecks due to skill/knowledge imbalances, steal pairing from XP. Maybe explore Theory of Constraints but resist Kanban unless you understand exactly what it is doing and why. Have regular conversations as a group, and one-on-ones, not just between managers and reports, but between each other. Hold short but regular retros to understand systemic issues and then make sure the actions are actioned.
It's not that hard. It's just Agile.
[1] http://agilemanifesto.org http://agilemanifesto.org
- lucianbr 2y ago> This meme that "Agile is evil", needs to die. No, people, you've just had really bad managers If the bad managers are outliers, then fine. If the bad managers are the norm, then we need a way of working that fits the average manager, even if you call them "bad". Most people in most companies are necessarily going to be of average quality. Judging from years of talking to devs and reading books and articles and comments on the net, what you call "bad managers" are not exceptions, but rather the norm. > Agile done well is absolutely amazing If your team is made up of very competent people, any methodology is likely to work great. But most teams are not. We need something that works reasonably well even when the managers and devs are just average.
- PaulRobinson 2y agoAgile can work great for average people, it needs less skill than any other method I know. Can you explain to me your thinking - which I might be implying and you might not actually think - as to how heavy processes like SCRUM and Kanban turn average teams into productive ones?
- lucianbr 2y agoAll I said was that blaming "bad managers" is not a solution. The rest of "my thinking" is just imagination on your part.
- belter 2y agoTrying to reinvent the story of Agile is not going to fly. You have to look at who are the signers of the manifest and what they did with Agile, to understand what Agile really is.
- PaulRobinson 2y agoI'm not interested in the history. I'm interested in the practice of building software in changing contexts where everyone is constantly learning and discovering. It doesn't matter who signed it and what they did next, it only matters how you and your colleagues get good work done.
- belter 2y ago> I'm interested in the practice of building software in changing contexts where everyone is constantly learning and discovering. No. Not this please no. Where is that context where your team is constantly learning and discovering. ? Please tell me what Software is that? A real time control system for a high speed train, airplane or space ship, where lives are at stake? A hospital or ER patient management system where a library bug can mean the patient get's a fatal dose of 250 ml of something instead of the life saving 2,5 ml? Or a context where everyone is constantly "learning and discovering" the best color for the web page of your online shopping? I prefer Software for stuff that matters....
- PaulRobinson 2y agoSure, waterfall might work for very small fixed contexts. Control software for a spacecraft is a great example. I can sit down now and start designing software to do physical calculations for a system that won't ship for 7+ years, confident the laws of physics won't change in that time. In fact, NASA did this in the Apollo program. Most software is used by customers with changing needs and competitive pulls. I've built software in the last 2 years that we would have taken a radically different approach to if LLMs were available, because they're great at summarising natural language. But they weren't. Imagine if we'd been building something for 2 years and never learned anything about changing technology or customer expectations - instead we shipped something fast, and then looked back after we learned about new things and made it better. That's how the World should work, and why software is not like building a bridge or a house or basically anything else in the history of engineering. As to your specific exampleS: I have some detailed knowledge of hospital EHR systems, and they are so massively, hilariously broken in ways that modern software practices could easily help address. I suggest reading Accelerate [1] for data and examples of how agile applied to DevOps practice in particular means you can be more responsive and produce safer software, especially in that context. I, like you, also prefer software for stuff that matters. I've been trained in formal methods, I've done embedded systems development, I've worked in medical/healthcare contexts. Your statement that what I've written above does not apply to those environments (including the use of formal verification methods), doesn't make sense to me. [1] https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339/ref=sr_1_1 https://www.amazon.com/Accelerate-Software-Performing-Techno...
- senectus1 2y agothe reason its a meme, is because this is how its bloody used EVERYWHERE. There may be some outliers where its not... but this is the cult like bullshit i'm seeing everywhere. agile is the Ivermectin of business process. except it makes me WANT to inject bleach.
- dmvdoug 2y agoI’m pretty sure this has become an argumentative move bordering on fallacy: “That thing you’re criticizing is no true Agile.” See https://en.wikipedia.org/wiki/No_true_Scotsman https://en.wikipedia.org/wiki/No_true_Scotsman
- gsich 2y ago>This meme that "Agile is evil", needs to die. The meme that any critique of agile is not "true agile" should be first.