Creating something brand new is hard. No matter if it’s a painting, a system architecture, or a conference talk, the creative effort of conjuring up something from nothing is difficult. Take me for example, staring at a text editor, trying to figure out what to type next and think up a clever title.
Writers know this as the Blank Page, painters as the Blank Canvas Problem. Regardless of the name, we’ve all encountered the phenomenon at some point. It’s that anxiety that comes from having an infinite number of choices for the next step.
A colleague of mine is kicking off a new software project with a new team. We got to talking about what the team needs to do in this situation and I had to sit down and really think about it for a few minutes. I’ve been doing this for a while now and I’m used to just doing it, not articulating the why of it, thus this blog post.
Just as a baby’s first years have a huge impact on their development, a team’s first steps have a huge impact on its long-term growth. It’s the most critical time for a nascent team. I’m not just talking about a Project Kickoff meeting, I’m talking about the first few weeks of a team.
A new team has two immediate goals - there’s a feedback loop between the two so it can be hard to separate them:
Getting work to flow is Agile in the purest sense. Get work flowing through the process, check it with the customer, figure out what needs to change, and then change it.
Why is building a team out of individuals equally important? Delivering working software is all that matters, right?
Fully half of the Agile Manifesto’s Principles are about people, because that’s how we get long-term success. To really “figure out what needs to change” and “then change it” requires more than just a collection of individuals, it requires a team. That doesn’t happen by accident.
The researchers found that what really mattered was less about who is on the team, and more about how the team worked together.
Just like Scrum is a process for implementing the Principles of Agile, this is the Process for the above Principles (the what, not how).
First, when getting work to flow, do the simplest thing that could possibly work. Rinse and repeat. It’s not easy, but it is straightforward. The most important thing is to break the “Blank Canvas” effect, deliver something, and show progress.
In Dual Track Development and a project starting up, your demos might be a prototype, and not working code. That’s ok. The point is to show progress.
Second, make it safe for teammates to talk to each other. Psychological safety, trust, vulnerability, and shared vocabulary are the keywords here. As a team lead with a team of excellent engineers, I consider that my primary job responsibility. If I can help the team be safe, they’ll self-organize and do things better than I could have imagined. If someone is feeling that “paradox of choice” anxiety, my job is to give them confidence that things will get better in time.
Third, create an intelligence system - one in which accurate, real-time information is distributed broadly and quickly, and presented in detail. The key point is that team members can see and react to patterns and decide what to do. If you’ve read the book Nine Lies About Work (which I highly recommend) this should sound familiar.
Each practice I’m going to talk about has worked for me in the past. Not every one is right for every team, they are simply tools in my toolbox. If you don’t like unsolicited advice, feel free to skip to the end.
I’m a big fan of visualizing everything, so I start with a Kanban board. My default board has only three columns: “To-do”, “Doing”, and “Done”. Nothing fancy. If you’ve got a physical board, make it as impermanent as possible, since that makes it more likely people will change it.
What about code reviews? Pull requests? Squash or rebase or merge? Doesn’t matter yet. Avoid long drawn-out conversations - find a starting point and move on. Remember, everything can be changed. It’s all an experiment. We’re just finding a starting point to iterate on later. This is a good time to introduce the concept of disagree and commit. Just don’t let that be an excuse for someone to dominate decision-making.
The roles & responsibilities activity is multi-purpose. It can:
Pick a team name. I’ve never met anyone strongly against the practice (at worst is mild apathy). Some people really get into it. It’s a short activity which gets the team focused on the same task. It’s low risk since the name can always be changed later. And at the end, the team has a name around which it can establish a team identity.
Psychological safety means individuals feel confident they won’t be embarrassed or punished for admitting a mistake, asking a question, or offering a new idea.
Shared vocabulary is necessary to make sure what people are saying is what others are hearing.
Be deliberate about building communication norms. It’s likely that some of these people have never worked together before.
Shake up the team rituals
Here is my take on chapter 2 from Nine Lies About Work, how a team lead can create an intelligence system:
So, what’s your approach? What principles, processes, and practices have you found effective? Drop me a line and let’s chat.