Happy People Make for High Performing Teams

Written by David van Rees

Happy People Make for High Performing Teams

Building high-performing teams is hard. It’s even harder with a professional services company, as creating new teams working on new projects is something we do on a regular basis. This means we are often in the position of learning about the client, their product and business on top of learning about ourselves and how we will work together.

How do we form project teams to ensure success? How do we minimize the time going through the Tuckman stages of group development? There are a number of important things we consider when staffing. It starts with simple things like finding the right mix of primary skills sets, ensuring we provide the right tools and automation, through to ensuring we provide lots of coaching and support.

Once a team has been formed, our Rangle Flow delivery process (based on Agile/Scrum principles), enables it to become high performing quickly. Some of the key principles are limiting work in progress, collaborating closely, peer review of all work, relentless prioritization of scope, etc. Each team is empowered to apply those principles in the way that works for the client and for themselves.

Creating a Team

Selective hiring is obviously the first step in ensuring the foundation of any team is as strong as possible. But looking for strength through functional skills only (regardless of whether they are JavaScript Developers, Product Designers or Business Quality Analysts) is only half the battle.

It’s very important for us to find people who love to learn, who provide a balance to the team (through differences in experience, personality and diversity), who are collaborative and who love challenges and doing great work. We also ensure that our teams work with sustainable development practices. All these things make for happy people.

When it’s time to build a team for a client, having a group of people who fit this description makes everything else a lot easier. That starts with the basic structure of an Agile Rangle team (Product Owner, Developer and/or Product Designer, Business Quality Analyst, Scrum Master) but the delivery part of the team may also include people with special skills (some examples: vertical expertise, accessibility, analytics, CSS/HTML, payment integration).

Strong teams are flat, autonomous, and cross-functional, so spending the time upfront considering primary and secondary skillsets will be rewarded by having a high-functioning team right out of the gate.

As part of working on a project, we ask our clients to provide us with a Product Owner (PO) to complete the team. Both sides benefit by having an engaged, knowledgeable and empowered PO who wants to sit with us and collaborate everyday. We also understand this person can be very hard to find, and will support and coach whomever is assigned to the project. The PO is a key person on our teams and having this team format helps break down any ‘us vs them’ dynamics.

Supporting the Team

Once the team is in place, we provide everybody with the tools they need to build the right software.

The first thing we look for is automation. A deeply important idea to us is continuous delivery, so that as little valuable developer time as possible is spent on things other than the client’s software. By having automated builds with unit tests, linting, etc, to all environments, we help ensure that the pull request contains high quality, maintainable code.

We also provide an automated way to deploy test environments (through Heroku for web applications, or Buddy Build or HockeyApp for mobile applications), so that for every pull request the team has an environment up and ready for peer review in a couple of minutes.

Rangle also uses open source starter projects, which set up the tooling and frameworks for some of our common project types in minutes. Whether we are starting greenfield projects with Angular 2 with TypeScript or using Facebook’s Create React App, our teams can start collaborating with the client on high value work rather than tooling.

We provide a lot of other support to our teams from management, and a set of peers assigned for project support in our ‘support squad’, so team members are not blocked from developing software.

Without this level of automation and support, the team won’t get focused on client needs fast enough, and deep focus is what produces quality software for our clients.

Moving to High Performance

Once the team is in place and working, we have a number of techniques to ensure everyone moves into the ‘performing’ state as quickly as possible. One very important way to allow team members to get to know each other, and for everyone to understand the context of the project, is our Clarity Canvas.

Our Scrum Masters are true leaders and provide coaching on Agile thinking to the teams. The Scrum Master helps set team working agreements, and facilitates ceremonies and meetings so they are as short and valuable as possible. Cross-functional teams also coach and mentor each other. We limit our work in progress so that the team can deliver user stories as a team, not work individually. User stories are small (done in less than three days on average) to promote lots of working software after each weekly sprint.

We strongly believe in having honest, transparent retrospectives each week to ensure we are gathering feedback on the team so we can celebrate successes and find actions that will improve the team dynamics. Using the Retrospective Prime Directive helps ensure the team is in a safe place and can be honest with each other.

[Sidebar] Retrospective Prime Directive: Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available and the situation at hand.

Happy People Make the Foundation for High-Performing Teams

To create a high-performing team, it’s important to start with people with the right mix of skills, enable them to make the best use of their skillsets, have autonomy and feel safe and supported. These teams then need access to a set of tools that will allow them to start fast and have deep focus on building up a relationship with the Product Owner and creating valuable software. Provide folks with coaches, and other support mechanisms to minimize slowdowns and blocks to the team.

Teams who are empathetic, curious, problem solvers and are receptive to feedback make for the most successful projects. Teams that exhibit these qualities create better software overall.