We may think the toughest challenges in an Agile project are domain-specific — how to use our distinct engineering, design and product skills to create something that’s desirable, viable and feasible. We focus on improving our process, frameworks and tools.

But the toughest challenges are often personal and relational. We’ve spent our careers collaborating. It's often fulfilling. Even so, it can take people out of their comfort zone: Fear of being wrong or not knowing what to do; resentment that someone is overstepping their role; anger that our work was unfairly criticized. 

This breakdown of trust causes teams to lose momentum and talent, waste resources, and put project objectives at risk.

If you dig into the source of these emotions, you’ll find individuals are surprisingly mis-aligned on the project’s goals and how they expect to collaborate. When your team kicks off a new project, help team members understand where they need to align or agree to disagree. Three key areas we focus on are goals, roles and norms.

Goals

Goals are the customer and business outcomes the team will aim to achieve. They’re measurable evidence that the team’s work achieved its purpose.

When the team doesn’t feel responsible for these outcomes, their goals tend to become domain-specific. This can lead to disputes over how to prioritize work and balance value and effort. The designer crafts an ideal experience that takes too long to implement. An engineer elegantly abstracts code for a feature that satisfies a narrow use case. A product manager achieves a high velocity by ignoring user research.

Co-creating outcomes encourages the team to put their priorities in perspective, to be willing to compromise for the sake of big-picture goals.

We use a format called a Speclet to capture and refine project outcomes. You can find a Speclet template and playbook at Lab Zero’s Guides repo.

Roles

Roles and responsibilities identify the type of role each team member plays in the project’s main activities. We define roles using a framework such as DACI ( Drives, Assists, Consulted, Informed). For example, the team might agree that the designer drives customer interviews, the product manager assists, and the engineer is informed.

Why is this necessary, when each team member’s responsibilities are defined in their job description? In reality, it isn’t that obvious. There’s a lot of variability in the skills required for jobs in our industry. A ‘designer’ might be highly skilled at interaction and visual design, but lack experience in user research. Or, the designer may be spread across multiple projects, and needs to rely on the product manager or an analyst to conduct research.

The collaborative nature of Agile projects also means that skills and responsibilities often overlap. It’s better to decide together how people will share responsibility than for each individual to make their own assumptions. 

Finally, defining roles and responsibilities in this way reinforces the importance of supporting players and communication. For example, while the PM and designer are the main contributors to user research, it's important for the engineer to be informed, so they can assist with finding feasible solutions to address user needs.

We co-create roles & responsibilities as part of a team charter we workshop at the beginning of a project. You can find a template of our charter on Lab Zero’s GitHub Repo.

Norms

Norms are the team’s values, working styles and expectations. 

It's especially relevant to align on norms when starting with a new team. People don’t know each other professionally or personally. The team’s character is a blank slate. 

Norms can be simple and procedural. For example, agreeing that everyone’s camera should be on during video conferences. Or more complex, such as agreeing on a set of standards for the Definition of Done.

They can also expose areas where there’s likely to be conflict. Imagine a design review where the presenter values community and calm, and a reviewer values competition and individuality. The reviewer thinks they had a stimulating debate; the presenter feels the review was hostile.  

Norming doesn’t require individuals to conform to something they’re not comfortable with. But it does show the team where they have common ground, and where they differ. They can then develop norms for how they collaborate. In the example above, the team might adopt a two-phased design process where the initial exploration is generative and individualistic, but the team agrees to protocols for giving and receiving feedback. 

Product Managers usually lead our norming workshops centered around a whiteboard or remote collaboration tool like Miro.

Staying on track

These kickoff activities get the team off on the right track. But the effort is wasted if goals, roles and norms are set and forgotten. As projects progress, goals evolve; team members come and go, and learn more about each other. How do you make the outcomes usable, and keep them relevant? One way is to incorporate them into periodic retros. Our teams retro at the end of each sprint to reflect on what we should keep doing, stop doing and start doing. This is a great time to review the team’s goals, roles and norms.

We'd love to hear how your teams stay aligned and in their comfort zone.

Suggested reading...

• Christina Wodke, The Team That Managed Itself, Cucina Media, 2019. 
• Dan M. Brown, Designing Together, New Riders Publishing, 2013.

 

Cover photo by Clay Banks on Unsplash