Brian Burson

ESTABLISHING TEAM CULTURE

summary

Team culture is a key predictor of overall team performance. Based on Spotify’s published culture and interviews with my recent teams, I feel the most important foundational elements of a development team’s culture are: transparency, empowerment, business awareness, and promoting a lean mindset. If these are consistently practiced on a day-to-day basis in goal setting, task creation and decision making situations, overall team productivity and retention will be high.

issue

Team culture, and ultimately its measure, team morale, is perhaps the key predictor of overall team performance and being identified as a great place to work. When I arrived at my last employer, the existing development team had lost any semblance of team purpose and understanding and why the current software was being written. Morale was at a low point and there was no sense of empowerment to suggest or make changes.

Spotify is a good starting Point

Personally, I believe Spotify did us all a huge favor when they published their engineering culture learnings as two animated videos. I have borrowed from their learnings multiple times as I setup or expand teams. If you’ve never seen them, it’s worth watching them at Spotify Culture - Part 1 and Spotify Culture - Part 2.

Below is the summary from the first video to illustrate why their perspective can be so helpful. I find their concepts can be applied directly, but if not, they are certainly thought provoking and help get ideas and discussions flowing.

Assessment

After several months of observations my leadership team scheduled meetings with the team, both individually and collectively. From these meetings, the following Spotify culture areas were obvious gaps that warranted more discussion and likely changes:

• People are greater than Anything / Trust is more important than Control / Community is more important than Structure - all of these focus on roughly the same thing - basically the team was not empowered or consulted for key business and technological decisions.

• Minimize the need for large projects / Small and frequent releases - in the world of agile development this is usually not even contemplated. However, in this case, the complexity of inter-connected legacy systems prompted the previous management team to plan large semi-annual releases. One of the first things the team decided to do was to re-institute releases every two weeks.

• Impact is more important than Velocity - it’s tempting to measure everything or nothing when it comes to agile development. In truth, the best answer is somewhere in the middle. When the focus is only on velocity, Dev teams usually over-estimate and under deliver so that they hit their “commitment”. This tendency has to be short-circuited to get the most out of a team. Instead of just commitment, we started to focus more on what we were delivering and whether it resulted in a) happy customers and b) sales.

• Waste repellent culture - once agile ceremonies (e.g. daily scrum, release planning, story elaboration and estimation, retrospectives) are in place they are rarely questioned or tuned. While all of these ceremonies are designed to enhance the process of software development, they often become rote and actually provide little to no value. We were at that state, so we discontinued most meetings and added them back in when they were missed.

• Focus on motivation / Definition of awesome - this is likely the most important exercise a team can initially do! Figuring out what “awesome” looks like becomes a great motivator in and of itself—especially if the team gets to define it and how to achieve it.

Coalescing all the feedback

From all the discussions we decided to implement the following four “pillars.” The development team (and me) needed to:

• Understand the business value of everything we were doing so that we could appropriately review requirements and come up with an optimal design.

• Be as efficient as possible by questioning all aspects of our agile process.

• Be as transparent as possible on all decisions.

• Pass as much as possible down to the team, including all hiring decisions.

Was it successful?

Yes! Here are some of the things we all noticed over the 3 years this was in place:

• Overall team productivity increased by reducing the importance of estimates and release commitments as well as letting work cross releases where necessary - this let work begin late in sprints, but not impact the actual release. This is essentially a “scrum-ban” approach.

• As the team felt empowered they were more likely to take on difficult tasks - letting us address things like legacy/tech debt reduction.

• Our retention was incredibly high - over a three year period, we lost a total of three people from a eighteen person team.

Ongoing measurement

The only way to determine success is to measure it! All changes should be monitored and measured and then adjusted as necessary. Below is a chart that shows how the 13 team members felt we were doing 6 months after initiating our four-point culture. The value of measurement? I felt we were consistently doing all four pillars—that simply wasn’t the case according to the team. Good input. Based on this survey, we again questioned all our process/agile ceremonies and meetings that the team didn’t feel provided value. We also involved more of the Dev team (open to everyone) in story/requirements writing so they better understood the business value.