Early in my career, I was a leadership development conference (through Lockheed’s great Engineering Leadership Development Program), where we played a game called Gold of the Desert Kings — it was a group game, in a big event space ballroom packed with engineers from all over the country. I don’t remember the rules of the game, but I do remember that it was a powerful reminder of how important it is to plan before you start working.
It’s easy to say we should plan before we start doing work — people say things like that all the time:
- Look before you leap
- Measure twice, cut once
- Cal Newport made this point on Ramit Sethi’s blog a while back
- Agile Scrum “forces” people, every few weeks, to stop and assess where they’ve been (sprint demo), where they’re going (sprint planning), and how they could improve (sprint retrospective)
But while we talk about this often, most people often regress back to a tendency of “jumping in” under pressure, instead of taking a breath and investing the energy of actually building a plan.
At the individual level, people are very quick to start working, trying to “make progress” and “feel productive” without investing the time to validate that they’re working on the most valuable thing. When groups of people (teams) are involved, we’re even worse at this — not only does the team want to jump in to avoid the plan of group planning and not feeling productive, everyone wants everyone else on the team to be productive (busy) so they feel they’re not the only one working hard. This creates this nasty culture where the team is trying to keep everyone busy (Instead, Goldratt’s The Goal teaches that we need to optimize the entire system, not at the individual person or machine level).
Yes the plan will change, but it’s not the first version of the plan is not the valuable part — it’s the exercise of pulling together all the different pieces of a project and thinking about them together that is valuable.
While making progress on some new task feels more rewarding and productive than building a plan, whether it’s an Agile backlog; a resource-leveled Microsoft Project file; and/or a few quick PowerPoint slides summarizing major activities, schedule, resources, and budget; INVEST the time to make a plan — make sure before you start sprinting in some direction that you’ve actually checked to see if that’s where you should be running.