DEV Community

Cover image for We Already Figured it Out
Frank Font
Frank Font

Posted on • Updated on


We Already Figured it Out

Have you worked in a setting where there are people that figure out what needs to be done and there are other people, different people, responsible for doing that work?

Are some people exclusively in charge of planning and breaking down the work so that it's neatly packaged for others to do that work?

This is not an uncommon workplace practice.

This separation of planning from doing even exists in places that are trying to deliver high quality innovations quickly.

And Dwight D. Eisenhower would not have approved of such an approach in the constantly evolving landscape which is software development.

How is Dwight relevant to any of this?

Dwight died in 1969 and perhaps never even touched a computer. He was a soldier and later an American president; not a high tech guy. So, what could he possibly have said of any relevance? He said this:

Plans are worthless, but planning is everything

For those that are curious, Dwight did not coin the idea. It was older than he was!

So why should such an old idea have any bearing on all the cool stuff smart people are doing today? Because many technology delivery teams, the ones that are pushing the envelope and seeking consistently better than normal results, find themselves in a battle with challenging timelines, unexpected bugs, unexpected re-prioritizations, and other challenges all the while working with incomplete information. This is like fighting a war.

And General Dwight was instrumental in winning World War II so he knew something about winning wars.

Let's break his planning mindset down.

Plans are worthless

This is a false statement. Plans are very important; good plans especially. Having a good plan is always an advantage.

However, when plans are put together by people that do not have perfect and complete information available at the time of planning, and also perfect minds that make no mistakes; those plans will prove to be wrong or at least incomplete at battle time.

  • Do you create plans only after all variables are known? (e.g., no guesses anywhere?)
  • Is every planner in your team perfect?

Planning is everything

If plans are worthless why bother planning? Could it be that plans capture only a fraction of the details that come out of the planning process? Could it be that everyone involved in the planning process, everyone truly engaged and active in it, is gaining insights into possibilities some or many of which will never be captured in the plan?

Could it be that many people get more from being there than reading about being there?

Could it be that participating in the creation of a plan engages something more in our minds, maybe a bit of the Ikea effect, so that it sticks better? And a plan that sticks better is perhaps more actionable?

In the heat of battle when people are under stress, what will they do? Will they do something that is consistent with the plan and thus in some rough alignment with what others in the team will do?

Of course you want the people in the battle to make adjustment decisions that are coordinated in some way through a shared understanding of key factors. And all key factors are not captured in a plan; they can't be. However, they could be generated during the planning process. Sometimes key factors are unspoken insights. And everyone in the room had an opportunity to internalize them. You had to be there.

Is your organization reserving planning for planners?

Your organization is fragile if roles are so fixed that plans are lobbed from planners to doers. The resilience of having developers really know the plans is just not going to happen. And the organization is weaker for it.

Battlefield adjustments will be less coordinated, or slower to make, or poorer, or all of these things.

Are your tools discouraging battlefield adjustments?

I've used tools that make it onerous to change a story or the break-down organization/relationships of tasks required to deliver a completed story. This is bad! Why? Because tools that create roadblocks to doing the right thing encourage losing mindsets. Examples of the wrong things these tools encourage:

  • Wasting valuable battle time "politicgenering" stories so the inevitable plan changes don't require changes in the tool, or
  • wasting valuable battle time cumbersomely refactoring work-breakdown structures in the tool so the tool is not telling a lie, or
  • everyone getting comfortable with ignoring what the tool says because in the heat of battle it contains lies.

Two of the above bullets make the content captured in such a tool somewhat damaged for reliable historical records that can be used in future planning.

Where has the time gone?!

Time can be an enemy when you don't have much. And if your organization is challenging itself to deliver amazing results in short periods of time then equip everyone to be holistically engaged. And that means everyone owns the plan. And everyone should expect the plan to fail. And that's okay. That's normal when your team is doing cool things faster than other teams.

And use tools and techniques that align with the mindset that plans will fail. And don't be okay with wasting time on capturing useless details up front and ending up with useless details at the end because that's how your tools expect you to work. Stop using tools that discourage you from doing the right things at the right times.

And do plan.

And have everyone going into battle go into it having contributed to the plan. Because plans are worthless.

Top comments (0)

Timeless DEV post...

Git Concepts I Wish I Knew Years Ago

The most used technology by developers is not Javascript.

It's not Python or HTML.

It hardly even gets mentioned in interviews or listed as a pre-requisite for jobs.

I'm talking about Git and version control of course.

One does not simply learn git