4 ms·

Like so many rants against Agile, this one assumes that it's intended to provide everything you need to take software from a drawing on a napkin to a fully func

Like so many rants against Agile, this one assumes that it's intended to provide everything you need to take software from a drawing on a napkin to a fully functional, deployed product. The author goes even further and assumes that Agile is also supposed to provide a system of professional development, and all your R&D to boot. Why not blame it for not offering a guide to retirement investing while you're at it? Agile is a process for managing software implementation. Period. You have to bring your own software design process, and if your company's is terrible (or nonexistent), don't blame Agile. You also have to manage your own software R&D, though you could certainly use the process to manage projects within R&D. But the idea that Agile somehow precludes R&D itself is ludicrous, no more sensible than saying it precluded your company from spending enough on marketing. Even sillier is the idea that it should provide some kind of career advancement plan. Agile is a software development process, not a personal development process. It doesn't (and shouldn't) offer a career roadmap any more than your build system does.

beckler 11y ago
So I don't really agree with your opinion, but I don't think you're entirely wrong. I've been doing scrum for about a year, and while I think agile is excellent because of the feedback look, I also think scrum is the worst agile method. Mainly because non-technical management will turn it from managing software implementation, into managing employees. But it's worse because you have to tell everyone your progress, and god forbid you actually have a problem and fuck up that sprints velocity. I was almost fired once because my velocity was half of what it normally was one sprint, due to basically dropping development work and doing devops for a week. I've been on a project where we had marketers join our sprints, and we're even assigned stories. Timeboxing genuinely difficult problems into two weeks is extremely stressful, and most product owners don't care about complexity, only results. I've had to make some super nasty hacks just to help get a "win" to make a client happy. True scrum is just too rigid for applications with complex problems, which is why you'll have a hard time finding two places that do scrum the same way, or keep processes consistent sprint after sprint. In my opinion, I find kanban to be a much more effective way in managing development, as it allows your engineers to actually solve problems. So I agree that agile is effective, but I don't think scrum is always the answer. Sorry about the word vomit.
- vannevar 11y ago
  These are really good observations. If there's a common thread, I would say it's the intolerance for failure exhibited by managers who don't understand software development. I'm not sure that intolerance would be lessened by another system, whether it be waterfall or kanban, or ad hoc. Prior to agile, when failure happened, it tended to happen in a big way near the end of the project. But if a project were two or three years long, as is common in software, everyone could move on to other jobs after having spent two or three years without having to report progress every day or demo features every two weeks. A couple years in one job is pretty typical nowadays. So in some ways it was a more comfortable environment for engineers. Agile was introduced so that failure could be amortized and tracked. It makes the development process more transparent so that mid-course management corrections can be made and the corporate ship can be steered around the icebergs instead of running blindly dead into them. But in order for it to work, management must be tolerant of small failures. If it's not, then scrum will become theater with failure swept under the rug, and you'll be right back where we were, with failure becoming apparent only near product launch, when the iceberg suddenly appears out of the fog too late to avoid it. Now, it may be a valid criticism that agile expects too much from management, that most software company managers aren't competent enough to use it. But that pretty much says we're all doomed anyway, regardless of what system (if any) is employed. I'd be interested in your thoughts on why you feel kanban is better, since my impression is that it is essentially the same process but without sprint intervals.
  - beckler 11y ago
    So kanban and scrum are fairly similar, but the difference is that with kanban, you don't have to estimate a point value to it, as time isn't the priority. I view this as an advantage for two reasons: - 1. Most non-technical clients view point estimates as absolute expectations. They can't comprehend an estimation in any other way. So if I can do 5 points a day, and I give a story 13 points, it's expected to be accomplished in ~2.5 days. If I exceed that amount of time, I've missed their expectations, and now I have a client who considers that work behind schedule. - 2. Large complex problems can be solved without the pressure of accomplishing it within a finite deadline. I think this leads to more robust implementations, and helps prevent large amounts of technical debt. To compare, I have never seen a scrum project that didn't have a runaway amount of technical debt that lead to some insane scope creep in stories later on. It has a downside of potentially hiding some problems, but I think it helps with individual responsibility when it comes to tasks. Every time I've used kanban, it's usually been for pretty short periods, but those periods were extremely productive and way less stressful. I mean, this is just all my opinion, so take it with a grain of salt, but this is what my agile experience has been so far.
deleted 11y ago
[deleted]
- deleted 11y ago
  [deleted]

beckler 11y ago

So I don't really agree with your opinion, but I don't think you're entirely wrong. I've been doing scrum for about a year, and while I think agile is excellent because of the feedback look, I also think scrum is the worst agile method. Mainly because non-technical management will turn it from managing software implementation, into managing employees. But it's worse because you have to tell everyone your progress, and god forbid you actually have a problem and fuck up that sprints velocity. I was almost fired once because my velocity was half of what it normally was one sprint, due to basically dropping development work and doing devops for a week. I've been on a project where we had marketers join our sprints, and we're even assigned stories. Timeboxing genuinely difficult problems into two weeks is extremely stressful, and most product owners don't care about complexity, only results. I've had to make some super nasty hacks just to help get a "win" to make a client happy. True scrum is just too rigid for applications with complex problems, which is why you'll have a hard time finding two places that do scrum the same way, or keep processes consistent sprint after sprint. In my opinion, I find kanban to be a much more effective way in managing development, as it allows your engineers to actually solve problems. So I agree that agile is effective, but I don't think scrum is always the answer. Sorry about the word vomit.

vannevar 11y ago
These are really good observations. If there's a common thread, I would say it's the intolerance for failure exhibited by managers who don't understand software development. I'm not sure that intolerance would be lessened by another system, whether it be waterfall or kanban, or ad hoc. Prior to agile, when failure happened, it tended to happen in a big way near the end of the project. But if a project were two or three years long, as is common in software, everyone could move on to other jobs after having spent two or three years without having to report progress every day or demo features every two weeks. A couple years in one job is pretty typical nowadays. So in some ways it was a more comfortable environment for engineers. Agile was introduced so that failure could be amortized and tracked. It makes the development process more transparent so that mid-course management corrections can be made and the corporate ship can be steered around the icebergs instead of running blindly dead into them. But in order for it to work, management must be tolerant of small failures. If it's not, then scrum will become theater with failure swept under the rug, and you'll be right back where we were, with failure becoming apparent only near product launch, when the iceberg suddenly appears out of the fog too late to avoid it. Now, it may be a valid criticism that agile expects too much from management, that most software company managers aren't competent enough to use it. But that pretty much says we're all doomed anyway, regardless of what system (if any) is employed. I'd be interested in your thoughts on why you feel kanban is better, since my impression is that it is essentially the same process but without sprint intervals.
- beckler 11y ago
  So kanban and scrum are fairly similar, but the difference is that with kanban, you don't have to estimate a point value to it, as time isn't the priority. I view this as an advantage for two reasons: - 1. Most non-technical clients view point estimates as absolute expectations. They can't comprehend an estimation in any other way. So if I can do 5 points a day, and I give a story 13 points, it's expected to be accomplished in ~2.5 days. If I exceed that amount of time, I've missed their expectations, and now I have a client who considers that work behind schedule. - 2. Large complex problems can be solved without the pressure of accomplishing it within a finite deadline. I think this leads to more robust implementations, and helps prevent large amounts of technical debt. To compare, I have never seen a scrum project that didn't have a runaway amount of technical debt that lead to some insane scope creep in stories later on. It has a downside of potentially hiding some problems, but I think it helps with individual responsibility when it comes to tasks. Every time I've used kanban, it's usually been for pretty short periods, but those periods were extremely productive and way less stressful. I mean, this is just all my opinion, so take it with a grain of salt, but this is what my agile experience has been so far.

deleted 11y ago

[deleted]

deleted 11y ago
[deleted]