> Does it work? Is it productive? Is it better than not doing that?
>> On average: yes, yes, and yes.
For what it's worth, I think it's more like: On average: no, no, and yes.
It doesn't really "work" in the sense that the plan turns out to be an accurate and useful reflection of the work; that is not the case on average in my experience (sometimes it is, but not usually). And for the same reason, it isn't usually a productive exercise; it usually costs more time up front than it earns in productivity.
But despite those two things I think it still turns out to be better on average, in a team / "you have a boss" environment. Because productivity is not the only thing that matters, legibility is also important to organizations, and worth some productivity cost. Though this will chafe me until I'm in my grave, I still think it's true.
> Having people assigned to tasks, a starting point, some initial steps to follow is something that increase delivery speed in the beginning a lot.
It's a balance of time spent planning against the value of the plan. Immediate-term "planning" is definitely valuable, IMO. Thinking through how some immediate work can be split up so that multiple people can make progress simultaneously, without stepping on each other's toes, that is definitely valuable. Having some discussion about what the next steps might be after those immediate steps are complete, that's also pretty much always valuable. Spending a small amount of time thinking about the next next steps can be valuable. But past that, in my experience, people often put more time into planning detailed steps than ends up being valuable. It's not that it has zero value, it's that it has a pretty high cost that, in my opinion, usually outweighs that value.
Also, just to note that I think spending time thinking about a "north star" vision of what a project is trying to achieve is also pretty much always strongly positive ROI.
It's time spent coming up with a detailed plan a few steps out from the immediate term that I find dubious. I don't mind other people spending that time if they want to, but I don't like spending my time in those planning meetings; I'd rather be getting to work on the immediate term tasks.
I think making plans/planning needs training to be good at - which in turn reduces "overplanning". Knowing what to include, discuss in which forum, what task or deliverable granularity, etc. is useful doesn't come naturally to most.
But actually, I kind of feel like people who have had training to get good at planning, are not the most likely people to be good at avoiding "overplanning". I think it's the same kind of incentives as how dentists have a natural bias toward recommending dental work, or chiropractors toward recommending adjustments, or programmers toward recommending writing software, or anyone toward doing a bit more of whatever it is they are trained at and good at than a totally unbiased third party might really need or want.
Maybe there's also a bit of a "midwit meme" to this (in all of these cases): inexperienced: don't do it!, some experience (midwit): do it!, extremely experienced: don't do it ... except in these cases where you really should, and include just the right amount, and be very thoughtful about the forum and who to include in the discussion, and calibrate the right level of granularity for this specific project, and ...
I think that happens typically when the planning and the execution are very divorced (someone good at/selling using the techniques of planning). I'd say a good operational planer doesn't overplan.
I agree, but I guess the point I was trying to make is that I think everybody is susceptible to over-biasing toward thinking the thing they know how to do is super important, to the point that they sometimes over-do it, despite their best intentions.
I would say that "a good programmer doesn't write more software than is necessary", but despite my best intentions, I'm certain that I write more software than is necessary, because writing software is my hammer and lots of things look like nails to me.
I think it requires more than just being "good" at something to overcome this tendency. I'm sure the very best operational planners, like the very best software engineers, consistently strike the perfect balance, but I suspect most "good" planners, like most "good" (even "great") software engineers I know, still struggle with this tendency.
>> On average: yes, yes, and yes.
For what it's worth, I think it's more like: On average: no, no, and yes.
It doesn't really "work" in the sense that the plan turns out to be an accurate and useful reflection of the work; that is not the case on average in my experience (sometimes it is, but not usually). And for the same reason, it isn't usually a productive exercise; it usually costs more time up front than it earns in productivity.
But despite those two things I think it still turns out to be better on average, in a team / "you have a boss" environment. Because productivity is not the only thing that matters, legibility is also important to organizations, and worth some productivity cost. Though this will chafe me until I'm in my grave, I still think it's true.