TL;DR

1. Do a team charter
2. Have a vision and mission workshop
3. Have a roles and responsibilities session
4. Work collaboratively on deciding your ways of working
5. Agree metrics for success

We’ve had a lot of experience in setting up new software delivery teams at Adadot. Having spent plenty of time in the developer kitchen cooking up different approaches, we now have our favorite five point recipe for new team success. Read on to learn how we race from forming to performing in a beat!

Run a team charter session

The idea can feel cheesy at first, but we’ve only ever had positive results from running team charter sessions. Set a few hours aside using the likes of Miro or Mural as your whiteboard tool. This session loosely covers four questions:

1. What is our team name?
   
2. Who are we as individuals?
   We highly recommend Atlassian’s ‘user manual’ approach here, getting each individual to present how they work best to the rest of the group.
   
3. What are our team values?
   Get the team to brainstorm what values are important to them, then discuss each and vote on the top five to call out as the team’s official values.
   
4. What are our team norms?
   Again get the team to brainstorm what norms they think they should have, such as communication methods, booking holidays in advance and remote working patterns. This isn’t a ‘deep ways of working’ session yet, so focus more on the practicals of running a team.

This charter should be pinned somewhere visible, be it in an office or on your team Slack channel.

Vision and Mission session

This session is key to ensuring a motivated and focused team, who understand the bigger picture rather than just their section of the production line. This session is typically run by a Product Owner, or whoever is the main owner of the vision and direction of your product or project. Some things that may be covered in this session are:

• What is our vision?
  A team vision should sit around a 12 month horizon. It should be aspirational and stretch the team, yet feel attainable. This vision is key to all the subsequent work the team does, as every feature and user story they work on should ideally ladder up to this wider vision. This might be articulated by the Product Owner and simply be them sharing that vision with the team. Conversely, a bottom-up approach to vision creation can be a useful way to take the team on the journey, following an approach such as this one.
  
  An example vision statement might be:
  
  “By 2024 we will have a analytics platform setup and actively being used by our users, that empowers developers to improve their wellbeing at work”
  
• What is our mission?
  A mission states the purpose for this team to exist. It defines the ‘why’ behind what the team does and its reason for doing it.
  
  An example mission might be:
  
  “To change the future of work by bringing more focus to wellbeing and collaboration metrics”
  
• What are our epics?
  What are the big epics or ‘rocks’ you want to deliver in the coming period? This is important and it helps the team understand the softer vision and mission in more tangible terms. These epics should link to both your vision and mission to ensure there’s a thread through everything you’re doing.
  
  

Roles and responsibilities session

The likelihood is that your team comprises individuals with diverse roles and responsibilities. If so, it’s just as likely that there will be some confusion around who does what, particularly in the early days of team formation. Having a roles and responsibilities session to work this out and agree it, collectively as a team, is critical to addressing this.

This template from Mural is a great place to start. You could either use the template directly in Mural, or follow a similar format in person. Running a session like this allows the full team to feed in what they expect of each other, whilst agreeing where the lines are drawn. Sometimes it pays to have blurry lines of responsibility, which is fine, as long as that’s purposeful.


Ways of working

Too often a team’s approach to how they execute work is dictated in a blanket manner from a wider organization or external party with no ‘skin in the game’. The best ways of working aren’t textbook frameworks (though they can be a helpful place to start), they’re bottom-up systems that are constructed together as a team.

Having a Delivery Manager or similar prepare for and run this session can help, bringing in ideas and options for different frameworks to stimulate the discussion, but don’t fall into the trap of being a Scrum or Kanban purist. Let the team tailor their ways of working to their needs, as no project or team of individuals is the same.

Agree metrics for success

You are what you measure!

Setting up a suite of metrics and KPIs so the team knows what good looks like can really help the team focus on pulling in the same direction. However, a classic trap is to turn this into a whipping exercise, focusing solely on productivity metrics like velocity, lines of code and commits per day – particularly if this is done on an individual level to monitor team members (hello, Big Brother!). These productivity metrics are useful when used at a team level (or revealed to individuals privately without management seeing that granular data), but you can take them to the next level by looking beyond just productivity.

Using Adadot you can get a host of different collaboration and wellbeing metrics for your team, using industry leading data science and models such as DORA and SPACE. This can empower your team to push productivity higher but at a sustainable level that gives you long term success, by keeping focus on team wellbeing and communication habits.

Over to you

There are many ways to take your team from forming to performing, and no one recipe will fit every team. Habits formed in team formation soon amplify and solidify, so it’s important to set yourselves up for success from day one.

Before you next bring together a new software development team, reflect on the above five approaches and think how you might alter your approach.