Elliot Morris

Stop me if this sounds familiar. The powers have be have decided that there shalt be a feature. You get an invite to a planning session.

This planning session includes anywhere from 5 to 20 people, none of which have done any preparatory work for it, and consists mostly of people giving their most basic, immediate opinions, and PM’s trying to remind everyone that they need action items and tickets as an output of this meeting.

It’s baffling. The attendees are at fault right? They should have done the preparation. These are often the same people complaining about how the organization doesn’t ever plan ahead or “think things through.” What hypocrites.

There is however a niggle, and that niggle is Scrum. The very same Agilists who schedule these meetings and design these processes must know that there is no room in anyone’s schedule to do any sort of long form conceptualization on these topics. They run the holy Scrum, so they should have really in-depth views into what anyone is doing on any given day, and to what tasks their time is assigned to.

The only conclusions I can reach on this are:

a. The Agilists have simply not thought about this contradiction, or

b. They believe that an organization can do up front technical planning in just a couple of sessions of brainstorming.

Obviously you can’t. Technical planning is real work, I’d argue it’s more time consuming than implementation. You cannot pull technical plans out of peoples heads if they have not yet thought about it properly, and by properly, I mean more than just idle musing. An architect could not design a significant building without putting a draft to paper, and engineers can’t plan significant technical implementation without writing something down. You can try to tell me that you’re not looking for an in-depth plan, but I’ve been down that road before. Loose plans are great in teams and orgs setup correctly for them, but the very fact that we’re in a top-down feature meeting being scheduled and run by people with manager in their title tells me that this isn’t one of those times.

You can do this planning in a few ways, if you insist on it. Prototyping is probably best, but that doesn’t fit into meeting theatre very well. It is in no way ridiculous to spend more than 50% of the time allocated to any given project on the prototype, or to put it more loosely, on the conceptualization. I think you’ll only disagree with this if you think writing the code is the hard part, which is obviously wrong. Software is conceptualization, that’s what people want from you. If people just wanted data shunted about they could get scripts from anywhere, especially nowadays.

This is of course not to mention that if you choose to perform Agile, particularly Scrum, this sort of top down feature development is anathema to the whole point, but shush let’s not mention that as it only tends to upset people.

It is doubtful there will ever be consequences for this absurd planning theatre being allowed to happen. I suspect most engineers and PMs have never been exposed to what competent technical planning looks like so can’t identify it’s absence. Heck, I couldn’t teach it. It’s like asking a painter how they do it, the answer is to practice every single day for more than ten years, there’s no shortcut.

The only salve to existing in an environment like this is to do what anyone sensible does when stuck in a dysfunctional process, ignore it and get things done off-books. This can have downsides however. If you’re the only one willing to go outside the lines to get things done, you have no recourse if this overloads you, since you shouldn’t have been doing it anyway. You will probably resort to doing it on your own time, as I often do. It also creates what I can only imagine is a confounding effect to PMs and the org at large, where some projects seem functional and some projects don’t, even though they run the exact same process. This is because some projects happen to include people who are willing to do the necessary work outside of the process. Inevitably this is the same type of person who would do stupid things like write and maintain the worlds technical foundations in open source repositories and give them away for free. These silly people, maybe one day they will start doing something useful with their lives, maybe they should look into Scrum.

This leads us to our final point, advice. The only process that works is one that focuses exclusively on identifying the people capable of running projects, just do that and you’ll be a top percentile org in terms of project management.

There may a scale at which the importance of process overtakes the importance of people, but you probably don’t work at that scale, and if you do you are definitely not doing Agile, the manifesto itself says so.

p.s. Please don’t come away from this post thinking the solve to this is to “carve out” explicit tasks in peoples sprint allocation for them to do technical planning. That won’t work.