4 ms·
> 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 c
by 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 agoAt 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.
- p4wnc6 11y agoI agree with this, except that I think in the presence of Agile what you are calling "poor management" is the norm, largely because of Agile and the way it structures thought and planning. I think it's very important to make that distinction, so that people stop defending Agile as if it wasn't to blame. When a tool is politically subverted by management and results in this problem over and over almost everywhere it is used, it's time to just admit it's mostly the tool's fault for not having codified ways of avoiding that management subversion. Basically, what I'm looking for in an engineering process is one that raises engineering concerns above manager and executive political concerns. In any organization you always have a struggle over who gets to use the phrase "business priority" -- do engineers get to say that the engineering work is the priority, or do managers get to say that political circumstances are the priority? Agile makes it easier for managers to promote political concerns while at the same time acting and talking as if they promote engineering concerns more. I'm perfectly happy being shown real business evidence about the cases when the engineering concerns are not primary -- but Agile offers ways for managers to never provide such evidence, to keep people busy generating more and more progress metrics that give them more political surface area with which to manipulate. I guess you could say this is just "poor management" but then I think we'd have to agree that 99.9%+ of management is "poor management" because this all repeats itself constantly in organizations of all ages, sizes, and stripes. And Agile is a hallmark indicator of such a dysfunctional engineering culture.
- bluejekyll 11y agoPolitics... is there anything that prevents that other than working at a company that is too small for them to exist? For me Agile is the least bad solution, it's definitely not ideal, and it's a million times better than Waterfall. > agree that 99.9%+ of management is "poor management" I'm not sure about the percentage, but good managers are rare.