5 ms·

There's definitely lots of people who don't think critically about agile, and just accept whatever agile dogma handed down to them without giving much thought a

There's definitely lots of people who don't think critically about agile, and just accept whatever agile dogma handed down to them without giving much thought about how it applies to their team, and their business. But I think you're vastly underestimating how much of an effect a good process, or a bad process can have on a development team. The good process doesn't need to be textbook scrum (In fact, "textbook" scrum is usually not a great idea), but it's a bit laughable that you're criticizing Agile advocates for not having critical thinking, while in the same breath minimizing process to "Well, there's good people and bad people, and the good people will get things done better." What do you think makes a good project manager a good product manager? Do they just magically add +5 to development speed to a project? Of course not, they build and adapt a process that makes sense for that team. That doesn't necessarily need to be Scrum, or even Agile, but in my experience those methodologies seem to work better. The only caveat is that they need to be built and adapted for a companies particular needs. In regards to proving Agile works, I can give plenty of anecdotes: I could talk about when my startup had pressure from upper management to commit to a fixed roadmap several months out, moving from our "Scrum-like" agile process to something much more akin to Waterfall. I can talk about how it led to overly defensive estimates, projects taking roughly double the time they used to, and inevitable "death marches" at the end of the project, when we were faced with the prospect of integrating huge projects into our main codebase, with the QA nightmare that resulted from that. I could talk about how, in the many tech companies I've worked for, there's an almost perfect correlation between "agility" (which I'm defining as the ability to re-evaluate project plans and iteratively develop software) and quality, ease of deployment, developer productivity, and satisfaction with the dev team. Finally, I can talk about a recent example. We recently experimented with moving to larger, pre-planned projects. One interesting thing about the way we did the transition is that we packaged up stories that we had already broken down into stories appropriate for Scrum, and moved them into a larger project. We ran two projects using this approach. One project that was estimated (in terms of story points) at about 1.5 weeks ended up taking 5 weeks to deploy. One project that was estimated around 5 weeks took 12. I wish I could give you more evidence, but this transition was such an abject failure that we moved back to Scrum before we did any more damage.

tomelders 14y ago
There it is again, that 'Agile is better than waterfall'. I can take any two turds, draw up a criteria by which to measure their quality (consistency, length, brownness) and arrive a valid conclusion that proves one turd is measurably better than the other. But they're still both turds, and you shouldn't eat them. Agile does not have a monopoly on process. But Agile apologists repeatedly offer up that concept. That somehow, a world without Agile is a world without process. That's an absurd thing to think. If you want process, tell me what you want to do first, and we'll work together from there. Agile supporters tell you how you're going to do something, then ask what you want to do, then tell you what you want to do is wrong. As for what makes someone 'good' or 'bad', you offer up a straw man argument that tells me more about how you think than how I think. And anecdotes aren't evidence. They're anecdotes. You may have had just as much success with those projects if you'd made everyone wear cowboy hats on Thursdays. You can't prove that you wouldn't, just as much as you can't prove that Agile works. And your final point is ludicrous, bordering on delusional. If I understand you correctly, you estimated how long something would take to build using Agile methodologies, then moved that stuff into an environment where Agile wasn't implemented, and it took longer than you estimated. All that tells me is: - You're terrible at estimating - or unable "re-evaluate project plans" (your own words) - or both. I might say I can cook a chicken in half an hour with prayer. Then I put the chicken in the oven where it takes 1 hour too cook, and then I claim that prayer is a better way to cook a chicken "because, look! the oven took an hour, and prayer would only have taken half an hour!"
- ryanbrunner 14y ago
  I don't know how I can constructively with you. I'm aware that there are things other than Agile and Waterfall. I'm also reasonably sure that you don't think good project managers magically make teams more productive. But you've done nothing other than trash Agile, dismiss Waterfall, and offer no alternatives of your own. How do you like to develop software? I get what you're saying about "tell me what you want to do first, and we'll work together from there". I mentioned a few times in my post that it's always important to not blindly implement Scrum, but to see what works well from you. But having Scrum defined is still useful for a lot of people, since: - It gives you a starting point to work from. Every project is different, but there's certainly common elements to projects as well. It's a bit like design patterns in software - applied blindly and religiously, they're impractical and can lead to pitfalls, but that doesn't they can't serve a purpose. - It takes a lot of time to learn what works and what doesn't in regards to project management. Telling new managers and developers to figure out what works for them with no guideposts is just going to lead to a whole lot of inefficiency as everyone stumbles towards a (mostly) shared goal. In regards to projects taking longer under a waterfall approach vs. an agile approach, there's a lot of different reasons for this sort of thing happening. - Working on small sprints (or whatever you want to call them) instead of month-long projects saves you a tremendous amount of integration time. Show me a project under active development that's existed outside the production branch of a codebase for more than a month that isn't going to be a nightmare to integrate. - Forcing yourself to make decisions up front, especially when you have a strong product management component to your team, can result in drastically more time working on requirements instead of starting with some unknowns and letting them work themselves out. - I can probably point to several bits of these projects that we would have avoided doing or would have done differently with Agile, but the requirements said otherwise. It's amazing how much power requirements documents have, and how much inertia they can add to a project. - Stuff generally gets done close to the due date on a project. This is as close to a universal truth as I've ever seen in project management. By keeping everything in tight iterations, you can control the flow somewhat by putting pressure to complete releasable software every week, rather than one massive due date that everyone scrambles for at the end of a project. - Being able to "re-evaluate project plans" is a hallmark of Agile, not Waterfall. I agree, being able to re-evaluate and iteratively arrive at a solution outside of rigourously documenting things up front would make things a lot more efficient. That, far more than planning meetings and retrospectives, is what Agile is all about, so I'm not sure why you're so intent on trashing it. I'm not sure why my example is ludicrous. If the process used doesn't have any effect on how long it takes to develop a project, what's the point of any process in the first place? Of course using different methodologies will have different results - even if you aren't an Agile fan, that's completely obvious.

tomelders 14y ago

There it is again, that 'Agile is better than waterfall'. I can take any two turds, draw up a criteria by which to measure their quality (consistency, length, brownness) and arrive a valid conclusion that proves one turd is measurably better than the other. But they're still both turds, and you shouldn't eat them. Agile does not have a monopoly on process. But Agile apologists repeatedly offer up that concept. That somehow, a world without Agile is a world without process. That's an absurd thing to think. If you want process, tell me what you want to do first, and we'll work together from there. Agile supporters tell you how you're going to do something, then ask what you want to do, then tell you what you want to do is wrong. As for what makes someone 'good' or 'bad', you offer up a straw man argument that tells me more about how you think than how I think. And anecdotes aren't evidence. They're anecdotes. You may have had just as much success with those projects if you'd made everyone wear cowboy hats on Thursdays. You can't prove that you wouldn't, just as much as you can't prove that Agile works. And your final point is ludicrous, bordering on delusional. If I understand you correctly, you estimated how long something would take to build using Agile methodologies, then moved that stuff into an environment where Agile wasn't implemented, and it took longer than you estimated. All that tells me is: - You're terrible at estimating - or unable "re-evaluate project plans" (your own words) - or both. I might say I can cook a chicken in half an hour with prayer. Then I put the chicken in the oven where it takes 1 hour too cook, and then I claim that prayer is a better way to cook a chicken "because, look! the oven took an hour, and prayer would only have taken half an hour!"

ryanbrunner 14y ago
I don't know how I can constructively with you. I'm aware that there are things other than Agile and Waterfall. I'm also reasonably sure that you don't think good project managers magically make teams more productive. But you've done nothing other than trash Agile, dismiss Waterfall, and offer no alternatives of your own. How do you like to develop software? I get what you're saying about "tell me what you want to do first, and we'll work together from there". I mentioned a few times in my post that it's always important to not blindly implement Scrum, but to see what works well from you. But having Scrum defined is still useful for a lot of people, since: - It gives you a starting point to work from. Every project is different, but there's certainly common elements to projects as well. It's a bit like design patterns in software - applied blindly and religiously, they're impractical and can lead to pitfalls, but that doesn't they can't serve a purpose. - It takes a lot of time to learn what works and what doesn't in regards to project management. Telling new managers and developers to figure out what works for them with no guideposts is just going to lead to a whole lot of inefficiency as everyone stumbles towards a (mostly) shared goal. In regards to projects taking longer under a waterfall approach vs. an agile approach, there's a lot of different reasons for this sort of thing happening. - Working on small sprints (or whatever you want to call them) instead of month-long projects saves you a tremendous amount of integration time. Show me a project under active development that's existed outside the production branch of a codebase for more than a month that isn't going to be a nightmare to integrate. - Forcing yourself to make decisions up front, especially when you have a strong product management component to your team, can result in drastically more time working on requirements instead of starting with some unknowns and letting them work themselves out. - I can probably point to several bits of these projects that we would have avoided doing or would have done differently with Agile, but the requirements said otherwise. It's amazing how much power requirements documents have, and how much inertia they can add to a project. - Stuff generally gets done close to the due date on a project. This is as close to a universal truth as I've ever seen in project management. By keeping everything in tight iterations, you can control the flow somewhat by putting pressure to complete releasable software every week, rather than one massive due date that everyone scrambles for at the end of a project. - Being able to "re-evaluate project plans" is a hallmark of Agile, not Waterfall. I agree, being able to re-evaluate and iteratively arrive at a solution outside of rigourously documenting things up front would make things a lot more efficient. That, far more than planning meetings and retrospectives, is what Agile is all about, so I'm not sure why you're so intent on trashing it. I'm not sure why my example is ludicrous. If the process used doesn't have any effect on how long it takes to develop a project, what's the point of any process in the first place? Of course using different methodologies will have different results - even if you aren't an Agile fan, that's completely obvious.