3 ms·

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 fore

by 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
  > This is perfect though! In two weeks, you discovered the wrong thing. Maybe I didn't describe it very well. 12 days was perhaps a poor choice because it is convenient to a sprint cycle, but in my comment it was meant to function as a random placeholder. This type of work happens like Poisson shocks, or like lightning strikes. You work and work and it seems like you don't get a single thing done, zero story points completed, etc., and then boom, in one fell swoop you figure out a huge advancement in the problem. That's the defining aspect of the work I am talking about. The burndown graphs will look like (and should look like) a flat line that suddenly drops to zero near the end. It has nothing to do with "failing fast" because it's not "failing." It is the process of discovering what the actual problem is. This is very different than a situation where you, say, try out a MVC architecture but later realize it's not optimal for a business use case and need to change it to MVVM or something. You can always make measured progress on the first attempt, and if it doesn't work, that would constitute valuable failure-case knowledge. But with more abstract questions it's more like you are saying this: we tried to solve it, and we are not even sure whether or not we've made any progress yet, and we won't be sure until right at the moment we've either solved the problem completely or demonstrated why our whole approach cannot be used to solve it. That's perhaps a very idealized version; most problems don't fall that far on the research spectrum. But the point is that many problems still do fall pretty far on that spectrum, and if you set up your approach to them based on doing Step A then doing Step B then reporting about metric C, etc., it actually hinders your ability to solve it, since the very nature of the problem is not amenable to that sort of thing.
  - bluejekyll 11y ago
    At this point we should probably agree to disagree on some of these finer points. But I do think that you are tending to blame agile for what really sounds like poor management. Management wants to see what progress is being made, so they use burndown graphs. Development, as you point out goes through spurts, except for the most basic tasks. So to management it can look like there is no progress being made. What I'm trying to point out is that trying to divide the problems into as small of a set of isolated components as possible may help get to a solution. But that doesn't say your wrong. It might take months of time to find that solution, the problem is you need to explain to someone over that time what you're doing, otherwise the money and project will be cut. This is where it can be good to try things out and show what you've learned over that time, this is important for managing up.

by p4wnc6 11y ago

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
> This is perfect though! In two weeks, you discovered the wrong thing. Maybe I didn't describe it very well. 12 days was perhaps a poor choice because it is convenient to a sprint cycle, but in my comment it was meant to function as a random placeholder. This type of work happens like Poisson shocks, or like lightning strikes. You work and work and it seems like you don't get a single thing done, zero story points completed, etc., and then boom, in one fell swoop you figure out a huge advancement in the problem. That's the defining aspect of the work I am talking about. The burndown graphs will look like (and should look like) a flat line that suddenly drops to zero near the end. It has nothing to do with "failing fast" because it's not "failing." It is the process of discovering what the actual problem is. This is very different than a situation where you, say, try out a MVC architecture but later realize it's not optimal for a business use case and need to change it to MVVM or something. You can always make measured progress on the first attempt, and if it doesn't work, that would constitute valuable failure-case knowledge. But with more abstract questions it's more like you are saying this: we tried to solve it, and we are not even sure whether or not we've made any progress yet, and we won't be sure until right at the moment we've either solved the problem completely or demonstrated why our whole approach cannot be used to solve it. That's perhaps a very idealized version; most problems don't fall that far on the research spectrum. But the point is that many problems still do fall pretty far on that spectrum, and if you set up your approach to them based on doing Step A then doing Step B then reporting about metric C, etc., it actually hinders your ability to solve it, since the very nature of the problem is not amenable to that sort of thing.
- bluejekyll 11y ago
  At this point we should probably agree to disagree on some of these finer points. But I do think that you are tending to blame agile for what really sounds like poor management. Management wants to see what progress is being made, so they use burndown graphs. Development, as you point out goes through spurts, except for the most basic tasks. So to management it can look like there is no progress being made. What I'm trying to point out is that trying to divide the problems into as small of a set of isolated components as possible may help get to a solution. But that doesn't say your wrong. It might take months of time to find that solution, the problem is you need to explain to someone over that time what you're doing, otherwise the money and project will be cut. This is where it can be good to try things out and show what you've learned over that time, this is important for managing up.