Title Goes Here

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.

Ok Rob, where are you going with this?

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. 

Start with the Principles

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; and
• Building a team out of individuals

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.

– re:Work

Principles beget a Process

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.

– Poppe Guthrie

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.

Getting work to flow

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:

• Set expectations amongst the team for who is responsible for what
• Make sure there are no gaps (e.g. a responsibility which is missing an owner)
• Surface conversations that weren’t being had (I’ve heard this called “unstated conflict”)
• Identify places in which people are looking to try new things on the project (growth opportunities)

Building a team out of individuals

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.

• Watch carefully for those to happen and treat them as a learning opportunity. Have a meta-conversation (i.e. “let’s talk about how we talk”) or an impromptu retrospective on the interaction.
• The Personal Histories Exercise is great for learning more about your teammates and reminding yourself that they, too, are human.
• Have some paid-for team meals. This encourages participation in the exercises and activities. If you don’t have an agenda, I like to get out of the office. Think of the cost of the meal as an investment in the long-term health of the team. 

Shared vocabulary is necessary to make sure what people are saying is what others are hearing.

• I like The Five Dysfunctions of a Team as a starting point for a shared mental model for our goals as a team. It doesn’t take long to describe and I haven’t met anyone yet that strongly disagreed with it. The goal here is not a perfect prescriptive model, it’s to establish shared concepts.
• The Tuckman model of group development resonates with many teams. It sets the team’s expectations for how it will change over time. Progression between stages is often described as linear, when in reality a team may move back-and-forth between stages.
• Talking about the fundamental attribution error gives the team a way to hold each other accountable.
• If yours is a team which likes feedback, consider the Motivating by Appreciation Inventory. It helps people understand how to give & show appreciation and deliver & receive feedback.

Be deliberate about building communication norms. It’s likely that some of these people have never worked together before.

• I like to start with a “no interruptions” rule based on re:Work and Google’s Project Aristotle. This is the first step to ensuring everyone has a chance to talk and for approximately equal time. It’s not an excuse for one person to dominate the conversation by speaking for too long.
• I’ve been on several teams which adopted the above practice. Another that goes well with it (to assist with “conversational turn-taking”) is holding up your index finger to show you would like to speak next. “Jim, what you have to say is important. Jane raised her finger first. Jane, please go ahead and Jim will talk next.” and everyone nods!
• I was on a team once in which we were spending a lot of time arguing over minutiae. Asking “on a scale of one-to-ten, how many cares do you have to give about this topic?” was extremely effective at focusing our discussions.

Shake up the team rituals

• Let standup run long. Bear with me here, I know this is heresy to some. I’m not saying spend an hour on standup. I am saying that new teammates have different experiences and are used to different styles of standup. Let some friction build up, lean into it, bring it up for conversation, and focus on outcomes. Remind people that what worked on past teams may not work here.
• One Scrum team decided to start with two Retrospectives per Sprint. One was the typical Sprint Retrospective, the other was mid-Sprint and focused team cohesion and long-term growth. When the team felt they were Performing (to use Tuckman’s term) they scaled back to one Retrospective per Sprint.

Building an intelligence system

Here is my take on chapter 2 from Nine Lies About Work, how a team lead can create an intelligence system:

1. Liberate information. Think about all of the sources of information you have and make them available to the team, on demand. Don’t constrain information to those who “need to know”. Don’t worry about whether the team will understand the data or be able to make use of it.
2. Ensure accuracy of data. Don’t worry about making the data simple or easy to consume. The biggest challenge isn’t making sense of data - we deal with complexity all the time and are good at it. It’s accuracy. Clean data is essential.
3. Trust the team to make sense of the data. We are not the best sense makers. The team is.
4. Watch carefully to see which data the team finds useful. Over time, increase the volume, depth, and speed of that sort of data.

Conclusion

Let’s recap:

• Get work to flow with the simplest process that could possibly work
• Be deliberate about moving from a group of individuals to a team
• Surface accurate data to the team and let the team make decisions

So, what’s your approach? What principles, processes, and practices have you found effective? Drop me a line and let’s chat.