3 ms·

> saying "when implemented correctly" that Agile, seemingly by definition, cannot fail Poor choice of words, you are correct. And I actually agree with what yo

> saying "when implemented correctly" that Agile, seemingly by definition, cannot fail Poor choice of words, you are correct. And I actually agree with what you're saying in the rest of that response. Allowing scrum teams the ability to decide how to work together is huge, and I think correct as you point out some of the benefits of that. Rigid inflexible systems are horrible. One thing that I know puts me generally in conflict with most agile purists is that a sprint should only have a time estimate component, and not a firm end date. Shoot for two weeks,but if it's three so be it.

p4wnc6 11y ago
Sometimes things need to be on a different order of magnitude than a few weeks. Sometimes a single sprint should be months, especially when the subtasks involved require novel research and pilots / prototypes (which is way more often, I find, than what typical "Agile thinkers" believe is true about business projects). You just cannot know what will be hard or what reasonable time estimates or how to divide up the work until you begin trying things for a significant amount of time and hitting the unanticipatable failure cases. Agile is great in small, well-controlled cases where the path to a solution is easily seen by everyone to consist of commoditized, been-done-a-million-times-before tasks. But the issue is that once you use the Agile hammer, now everything looks like a we-must-solve-it-in-only-the-been-done-a-million-times-before-and-fits-into-sprints nail. The other big thing is that so, so few Agile implementations are remotely like the Agile ideal that we should probably stop pretending there even is an Agile ideal. If everyone using a given tool consistently messes it up in the same ways, we should just stop trying to defend the tool and admit it's the tool's fault for being intrinsically easy to misuse/abuse, and seek to invent better tools that make it very hard to misuse/abuse them.
- bluejekyll 11y ago
  I don't think I can agree that things should be months long. You build in discovery at different points in the project, aka spikes. It should be possible to come up with tasks that can be accomplished in roughly two weeks. If you break it down, you probably already do this: 1) get build for project going, 2) get initial config/entrypoint for system up, 3) implement stubs for API, etc... you can break it down, but each of those is a constrained set of work. It might be part of a very large project that can't "ship" at the end of two weeks, but you can verify different components along the way. It also is a helpful exercise to allow for multiple people to collaborate on different portions of the problem.
  - p4wnc6 11y ago
    The trouble with this is that it assumes very particular kinds of projects. For example, I once worked on a user-facing mobile and web application that did forecasting and prediction to dynamically steer students through online college course materials. The portions of the app that were very "customer facing" were exactly as you describe -- things like the user interface, APIs for educators who made use of the tool, etc. But the statistical modeling and "science" code at the core of it was completely different. You could not propose a series of step-wise changes that could be pre-planned over short-term horizons. You might propose something and after 12 days of working you might discover it was mathematically not going to work, regardless of engineering effort, and you could not have foreseen this (or at least our experienced team of stats people could not). If you say something like "solve this hard cryptography problem" or "find a way to forecast X with Y% accuracy" or "determine an architecture that will boost performance by Z%" -- these questions are hilariously ill-suited to someone just pre-specifying a set of steps for a 2-week period. There's nothing magical about 2-weeks that implies you can always make meaningful progress on every problem in that time frame. Sometimes you can't, and the extra constraints of trying to pretend like you can and structure work like you can act as significant hindrances to the real processes of discovery underneath. I agree this is somewhat rarer than the types of work that do fit neatly into 2-week chunks. But a lot of Agile evangelists want to politically recast the engineering efforts as if it's always that way, and that any request for more of a research approach to a problem must just be coming from whiny engineers who don't want to deal with real-world deadlines. And, predictably, this leads people to try to solve totally non-Agile-suited problems in rigid Agile-only ways, which ends up bad for everyone.
    - bluejekyll 11y ago
      > You might propose something and after 12 days of working you might discover it was mathematically not going to work This is perfect though! In two weeks, you discovered the wrong thing. That's as valuable, IMO, as finding the right thing. The goal I find in my work is to try and fail fast... in other words, discover as quickly as possible whether or not a particular solution is feasible or not. For truly complex issues, I have found that it often can take upwards of three failures before you discover the 'right' way to solve complex problems. You might have worked in an environment that didn't allow for failure and/or changing of dates. That definitely sucks.

p4wnc6 11y ago

Sometimes things need to be on a different order of magnitude than a few weeks. Sometimes a single sprint should be months, especially when the subtasks involved require novel research and pilots / prototypes (which is way more often, I find, than what typical "Agile thinkers" believe is true about business projects). You just cannot know what will be hard or what reasonable time estimates or how to divide up the work until you begin trying things for a significant amount of time and hitting the unanticipatable failure cases. Agile is great in small, well-controlled cases where the path to a solution is easily seen by everyone to consist of commoditized, been-done-a-million-times-before tasks. But the issue is that once you use the Agile hammer, now everything looks like a we-must-solve-it-in-only-the-been-done-a-million-times-before-and-fits-into-sprints nail. The other big thing is that so, so few Agile implementations are remotely like the Agile ideal that we should probably stop pretending there even is an Agile ideal. If everyone using a given tool consistently messes it up in the same ways, we should just stop trying to defend the tool and admit it's the tool's fault for being intrinsically easy to misuse/abuse, and seek to invent better tools that make it very hard to misuse/abuse them.

bluejekyll 11y ago
I don't think I can agree that things should be months long. You build in discovery at different points in the project, aka spikes. It should be possible to come up with tasks that can be accomplished in roughly two weeks. If you break it down, you probably already do this: 1) get build for project going, 2) get initial config/entrypoint for system up, 3) implement stubs for API, etc... you can break it down, but each of those is a constrained set of work. It might be part of a very large project that can't "ship" at the end of two weeks, but you can verify different components along the way. It also is a helpful exercise to allow for multiple people to collaborate on different portions of the problem.
- p4wnc6 11y ago
  The trouble with this is that it assumes very particular kinds of projects. For example, I once worked on a user-facing mobile and web application that did forecasting and prediction to dynamically steer students through online college course materials. The portions of the app that were very "customer facing" were exactly as you describe -- things like the user interface, APIs for educators who made use of the tool, etc. But the statistical modeling and "science" code at the core of it was completely different. You could not propose a series of step-wise changes that could be pre-planned over short-term horizons. You might propose something and after 12 days of working you might discover it was mathematically not going to work, regardless of engineering effort, and you could not have foreseen this (or at least our experienced team of stats people could not). If you say something like "solve this hard cryptography problem" or "find a way to forecast X with Y% accuracy" or "determine an architecture that will boost performance by Z%" -- these questions are hilariously ill-suited to someone just pre-specifying a set of steps for a 2-week period. There's nothing magical about 2-weeks that implies you can always make meaningful progress on every problem in that time frame. Sometimes you can't, and the extra constraints of trying to pretend like you can and structure work like you can act as significant hindrances to the real processes of discovery underneath. I agree this is somewhat rarer than the types of work that do fit neatly into 2-week chunks. But a lot of Agile evangelists want to politically recast the engineering efforts as if it's always that way, and that any request for more of a research approach to a problem must just be coming from whiny engineers who don't want to deal with real-world deadlines. And, predictably, this leads people to try to solve totally non-Agile-suited problems in rigid Agile-only ways, which ends up bad for everyone.
  - bluejekyll 11y ago
    > You might propose something and after 12 days of working you might discover it was mathematically not going to work This is perfect though! In two weeks, you discovered the wrong thing. That's as valuable, IMO, as finding the right thing. The goal I find in my work is to try and fail fast... in other words, discover as quickly as possible whether or not a particular solution is feasible or not. For truly complex issues, I have found that it often can take upwards of three failures before you discover the 'right' way to solve complex problems. You might have worked in an environment that didn't allow for failure and/or changing of dates. That definitely sucks.