Massive product engineering team growth? Hire an army of scrum masters….. or maybe not.

During the pandemic many organisations grew exponentially, adding people and teams at a mind blowing rate. Teams quickly outnumbered scrum masters or agile coaches more than several to one in some cases, and that’s not including enablement team coordination at varying levels that needs support. Should the business hire an army of scrum masters or coaches to keep pace with the explosion of teams spinning up? Maybe…or not.

At my organisation, we’ve chosen to focus on scaling Agile support of high performing behaviours to keep pace with our fast paced growth. This post will share a few practices we’ve leveraged to scale our Agile practice after doubling (and still growing) our Product Engineering teams over the last two years.

Co-create what high performance looks like with teams.

As it says on the tin, start with the end in mind. We encourage teams and Agile coaches/leads to co-create what success looks like for them. Success being the high performing behaviours teams would like to move towards. Agile coaches and leads embody a matrix of competencies. Agile (Scrum or Kanban) practitioner, facilitator, mentor and transformational mastery (to name a few) teams can draw upon to help guide them towards high performance.

Our Agile leads and coaches enter into “Agreements” that focus on behaviours which seek to improve flow, trust, ownership and attention to results among others. The team and Agile coaches set a time-box to reflect on their “Agreements” and during that time partner together to achieve their goals. At the end of the time-box, teams inspect and adapt the behaviours they want to explore moving forward.

This “Agreement” is changing the conversation from a traditional output oriented role, in some ways focused largely on artefacts and ceremony to instead building trust and focus on sound Agile principles and outcomes.

Cliched but true, “what doesn’t get measured doesn’t get improved.”

Along with team health checks and flow metrics we also leverage Shu-Ha-Ri pattern of mastery to encourage team maturity. Supplementing “Agreements”, we help teams progress their Agile mastery by strengthening foundational habits and supporting their evolution to experimenting with new behaviours that aim to improve delivery, quality and other elements of team mastery. Teams reflect on their maturity and in turn use it as additional data for assessing “Agreements” with Agile coaches.

Focusing on team maturity allows us to scale how we partner with engineering teams. As teams mature, requiring nuanced guidance it creates opportunities for Agile coaches/leads to be more hands-on with emerging teams or support functions across the business (e.g. Finance, HR, Business development, PMO).

Value enabling of high performing behaviours over “protecting” the team.

I can already hear the stampede of objections referring to ‘stone tablet’ scrum guides suggesting the scrum master protects the team from the “interference” of “management”. We’ve experimented with a subtle approach, enabling teams to protect their focus by understanding the wider context of work. To own their goals and backlogs. Own the escalation of blockers and risks. Ideally, given the context of our shared corporate goals, make the right decisions and execute when necessary. Rife with its challenges, we are learning a lot from this practice.

“Protecting” the team from “management” in the traditional Scrum sense can yield initial performance gains but can hit a ceiling. Scrum taken to the extreme can hinder a team’s ability to learn the wider context of why they are building a “thing.” Unintentionally reinforce siloed behaviour and limit their ability to share vital information outside of the team. Bob C Martin controversially laments,

“This is not a problem with Scrum out of the box so much as it is a problem with the way scrum sometimes evolves.”

Rally the Agile team around compelling Objectives and Key Results (OKRs).

Drawing on diagnostic data within the organisation, our Agile team co-creates compelling OKRs aligned to corporate objectives. OKRs align our collective efforts to measurable outcomes at scale, spark innovation, create learning opportunities via pairing and growth through mentorship. Also, innovate and eat your own dog food! Though experimentation we’ve built an automated tool that generates a heat map based on individual team Shu-Ha-Ri based survey feedback. The tool supplements our data gathering efforts and improves the quality of continuous improvement conversations with engineering managers and teams.

Heavy investment in personal mastery and safety required.

Disclaimer, this approach does come at the cost of major investment in personal mastery. Through coaching dojos (e.g. coaching triads, Troika sessions), lunch and learn presentations and community of practice (CoP) to name a few, we’ve put significant effort into deliberate practice and sharing learnings. Training that focuses on active listening, facilitation skills, multiple Agile practices, self awareness and cultivating psychological safety — not the cuddly bits but the radical candour kind. Scaling Agile support this way also requires buy-in from leadership; an environment that encourages smart failure. Equally celebrating successes and learning from experiments that go down like the Hindenburg.

Conclusion: Outcomes over outputs.

There is a limit to the amount of teams a person can support. Maybe hiring an army of scrum masters or coaches for a set ratio of teams is the way to go. We value and support teams’ aspiration to mature, hone team mastery, own their ways of working so that they are empowered to engage the business and make quality decisions. Moving away from being “another manager,” this positions our Agile team to focus on growth (both professionally and for the business) and creates mobility by partnering and collaborating with teams or non engineering departments throughout the organisation. We want to scale to our support of Business Agility across the organisation, not just Agile for software delivery teams.

Quote reference: Mark Levinson, 2010, InfoQ.Com, <https://www.infoq.com/news/2010/02/scrum-failings/>