“A strong foundation is invisible, but it holds everything together.”
(Richard Seidl)
Today I want to look at the unsung heroes of project work: processes, and the process models we build them from. Yes, you read that right. Deadly dull, isn’t it? But without processes that actually work, every project is a house of cards. One little nudge and the whole thing comes down.
That doesn’t mean we need lots of heavyweight processes. Quite the opposite. I’m no fan of bloated process models that get rolled out blindly, without anyone thinking them through. That’s how you end up doing things without ever asking whether they make sense.
I don’t believe high process quality means regulating everything down to the last detail. It’s about setting up a frame that lets us work creatively and efficiently inside it. Processes aren’t there to box us in. They’re there to give us room to do our best work.
And this is where courage comes in. It takes courage to break old habits and try new paths. Courage to say, “Let’s do this differently for once.” To run experiments. But also to say, “No, we’re keeping it the way it is.” Because changing everything all the time creates more frustration than enthusiasm. It’s a balancing act.
Process Models as a Buffet: Combining Scrum, PRINCE2 and the V-Model
So how do you get to processes that work? This is where the process models come back in. Instead of simply adopting one, I like to think of all these models as a big buffet. I take what I like, what suits the team and what helps us work well together. And the rest stays on the buffet. Plenty of people do this intuitively anyway. I hardly know a company that runs Scrum, PRINCE2 or the V-model in its pure form. More often it’s a mix of several models.
The catch: what’s written down is something else. Teams and companies like to adopt complete models as their official process framework, and then nobody actually lives them. Wouldn’t it be much better if the written rules matched what people really do?
Building Your Own Processes With the Retrospective
Getting there is actually simple. We’ve had the tool in our kit for years: the retrospective. With it, I can bring to the surface what the team needs and wants in order to work well together and reach the outcome. I can find weak spots in the processes and fix them, drop old ones and create new ones. The result is a process foundation made for this team, so it can perform. Run regularly, the retrospective keeps the processes adapting. They become more stable and more familiar, and they give the project a solid frame.
So here’s to a good foundation!
