Process > plans

When training for any sport, consistency is key.

Amateur judoka will count their wins. Professionals will focus rigorously on their technique. A beginning football player goes home disappointed that he didn’t score. A pro checks another training off the list, regardless of the outcome.

By focussing on the routines of improvement, the professional surpasses the amateur in the long run.

We can extend this metaphor to software. Too many amateurs focus on the immediate results. Why run laps around the field if you can try and score? Why work on fundamentals if you can churn out features from day one?
The process, however, is more important than the immediate outcome. A good software development team might seem slower at first. They might train on activities that you don’t think add value. But make no mistake: they will outpace the feature factory teams.

Great teams set up a delivery pipeline before they start defining a backlog. They work on quality before they think about features. They try to focus on the core of the problem and say no to the fluff.
There is a big difference between a plan and a process. A plan is an assumption about a future that might never happen. A process is a system that grows over time but that is active in the now. One is a result you hope for, the other is the work you put in.

A plan is enlisting for the London marathon next April. A process is the schedule of actually putting on your running shoes and going for that run. Three times a week.

It’s easier to enlist than to train for a marathon. Plans are cheap.

A process without a plan will pay off. A plan without a process is a lazy daydream.