Making Teams and DevOps Work, Atlassian’s Playbook: Our No BS Guide to Unleashing your Team’s Potential

In making the switch to a distributed technology of microservices, continuous integration and continuous delivery, one of the unexpected changes for most companies is how their company structure needs to change to mirror their new distributed stack. The move to DevOps requires functioning cross-functional teams.

Teamwork is a common buzzword but is not so easy to pull off in practice. So how, exactly, does a manager make their teams work as a cohesive unit?

Luckily, there’s a dynamic team-building program from Atlassian, the company behind Jira, BitBucket, and Trello, among other products. Called a Playbook after the sports playbook for getting the team to work together, and because it should be fun, after all, it is sub-titled “Our no bullshit guide to unleashing your team’s potential.”

How it Was Built

Dominic Price, the head of research and development and resident “work futurist” at Atlassian, ran their program management globally during three and a half years when they expanded from 450 people to over 1,700. The growth was not just in numbers of employees and the expansion of their product line. Customer expectation on the speed of the technology and refresh cycle has put pressure on all companies to go faster.

This Playbook, completely open source, was not developed by team building experts, but by teams themselves. Price realized early on that the speed of both growth and software distribution requires distribution of decision-making to the level of the teams.

The use of teams is a key tenant of DevOps practices. Teams are created with people from throughout the development lifecycle, and the teams are highly autonomous because decisions need to be made quickly. “We have highly motivated engineers because they have a lot of autonomy and they love what they’re doing,” Price said in a phone interview. “The key question became: ‘how does one keep engineers autonomous and powerful at scale?’”

Price started to look for solutions. He worked closely with the vice president of engineering who gave him a singular mission: “I never want to be famous for how big we are, I want to be famous for how awesome we are.” Awesomeness relies on happy engineering teams.

Price started by figuring out what was working, and what was not working. For this information, he went to the teams themselves. “It evolved naturally,” he said, “working with teams in R&D across the globe, finding sticking points, working through them, writing them down, then sharing them widely.” “It just became a thing,” Price stated.

The basis of the Team Playbooks is this: They are divided into “Plays” or team exercises, designed to root out our weaknesses in team dynamics.

“This ain’t your CEO’s management book,” says the Playbook page. “It’s by teams, for teams – any team.” The Plays are designed to help individual teams assess how they work together and provide team exercises they can use to improve, explained Price.

“These are not checklists, they are not extra work,” says the promo video, “they are conversations for the whole team to have, and a different way of looking at things.” Each play is a series of step-by-step guides to help your team be more efficient and more effective.

They are a way to practice continuous improvement.

Start with a Health Monitor

The recommended starting point is the Health Monitor, where your team creates a baseline of their current overall health. “Part cure, part preventative medicine, the Health Monitor is your team’s chance to listen to each other and take an honest look in the mirror,” says the Playbook. “You’ll assess against eight attributes common among healthy teams, and walk away with a better understanding of your strengths (plus plans to address your weak spots).”

For each of the eight attributes, the team members simultaneously rate how they think the team is doing. On each attribute, the team assigns a point with a thumbs up (green) thumbs sidewise (yellow) or thumbs down (red).

From there, they suggest you pick one or two of the red or yellow results and use the Play to work together to improve. The point of the Health Monitor is not to solve problems, but to identify areas that the team itself sees as needing improvement. The playbook recommends each team do a quick Health Monitor once a month.

There are different Health Monitors for different teams, Leadership, Project, Service teams, and tips for the person leading the Health Monitor.

For example, the Project Team’s eight attributes for a successful team are: Full-time owner, Balanced team, shared understanding, value and metrics, proof of concept, one-pager, managed dependencies and velocity.

Each of these attributes has up to three Plays that the team can work on to improve. For example, if your teams Health Monitor shows that Values and Metrics need work, you can choose to do the Plays “Empathy Mapping,” “Goals, Signals, and Measures,” and “Trade-off Sliders.”

Each Play starts with the focus; what the Play is working to accomplish, when best to run the Play, as well as the expected number of team members, prep time, play time & difficulty level, and materials needed. The Goals, Signals and Measures Play requires a whiteboard, sticky notes, markers, timer, rubber chicken and Magic 8 Ball (optional). The rubber chicken is explained on the About Page.

All of this sounds like work? Of course. Anything that is a new skill takes time and attention. The question to ask yourself is: Is the time spent in team building more or less than the time it takes for a dysfunctional team to get the work done? A well-running team pays dividends on many levels, not the least of which is a better product and happier engineers, who produce a better product.

Should your team use these plays all the time? “OMG, no,” says their website. “The plays are designed to contribute to your daily work, not distract from it. It’s all about running the right play(s) for your team when you need them.”