Scaffolds and Ladders, or: Making the case for frameworks.
Imagine you're building or rennovating a house. Maybe repair the roof, or add some solar panels to it. If you think about how you can reach the spot you need to work on, two things come to mind:
You can grab a ladder, walk up there, do the thing you want to do, and then swiftly walk down again, put the ladder to some other place, and climb up again to reach the other spot you need to work on. And you can continue to move and climb, move and climb, move and climb until you are done.
The other approach would be to create some scaffolding before starting to do the "actual work". Cover all of the area in gantries, catwalks and frameworks. Once this is done, you can move freely around the place, without needing to reposition your climbing helps.
This image was crated by Daniel C. Dennet in his excellent book "Intuition Pumps and Other Tools for Thinking" and shows the benefits and drawbacks of working in a reactive mode.
The benefits of all this ladder-moving are clear: You can start working on your project pretty immediately. But the drawbacks are also pretty obvious: The larger the project, the more time you need to invest for moving the ladder, and sometimes you might do a sloppy job because you can just so reach the spot you want to work on without moving the ladder (therefore, you don't).
The drawback of creating a solid framework is obvious, too: You invest a lot of time and energy up front, without actually doing what you set out to do: You wanted to repair the roof, not build a scaffold. So it's tempting to skip this step and just use a ladder, especially since the benefits of the scaffold come to light only later in the project.
I see this mentality in teams all the time: Let's be "Agile" and start working on the project immediately! We'll figure everything out on the go, and can decide on things when we come into the situation where we need to make such a call. And of course, that situation comes, and it will create a crisis, because the team isn't prepared for it. And there will be no time, and lots of emotions, and nobody will be in the mood for a well laid-out, deep discussion. Instead, everybody will rush to conclusions, and move on.
Teams practicing Scrum know this, and have at least a minimum set of scaffolding before getting to work. Things like a Definition of Done, or a Definition of Ready. Starting a sprint without a Definition of Ready is the recipe for a lengthy, tedious, exhausting sprint planning. And ending a sprint without a Definition of Done is the recipe for disappointment and embarassment.
But there are a couple more things that are part of your projects scaffold, and that need to be defined and agreed upon.
At the start of every new team (or an existing team taking over a new function in the organisation), I like to take them through a couple of sessions to create clarity on a couple of questions:
- What are we doing here? What is our purpose?
- What is our long-term goal and vision?
- What activities will we perform to reach that goal?
- Who are our stakeholders, and what are their needs?
- How do we define success, how do we spot and measure it?
- How would our stakeholders define success?
- How do we communicate?
- How do we make decisions?
- How to we want to give and receive feedback?
This list moves from "What" to "Who" to "How", and it does so for a reason. It defines the identity and purpose, the culture and the rituals of the group.
It will help the group to find firm ground when everything else is shaking in a time of crisis.