Rebranding the Scrum Master Role in Tech Orgs
How Capital One is Building Better Software and Rethinking Scrum
By Sean Miller, Sr. Manager, Agile Program Lead & Bill Roberts, Director, Agile Coach
This post first appeared on Capital One’s tech blog here, and any opinions are those of the individual authors.
Change is constant in the world we live in, and that’s no different inside the walls of Capital One. Not only are we striving to build great experiences for our customers, but we’re also constantly evaluating how our technology teams deliver software to our customers and how much support they receive.
In more ways than one, Capital One is an Agile organization. Our teams choose what’s best for them and the software they deliver, so we practice Scrum, Kanban, XP and other flavors of Agile – it’s how we deliver software quickly and efficiently. But those that practice these methodologies know that they’re not a “one size fits all” model. For a long time, Capital One has maintained a culture where Scrum Masters – as originally described in the Scrum Guide and Agile Manifesto – are part of the software development team package. In recent years, we’ve determined that this no longer meets the needs of our Software Delivery Teams.
Today, our teams need more than just facilitators. They need someone who can run the puck, keep the engineers focused on writing code, and help ensure we’re constantly doing the right thing. Traditionally, there’s been no onus on Scrum Master to be technically adept. But, in a world that is becoming more and more technical, where we’re constantly raising the bar for our engineers, why not empower our Scrum Masters to become more technical as a means to truly help teams deliver?
“By keeping the Scrum Master in its true form is it safe to say that we’re being prescriptive?”
With that said, Capital One is on a journey to transform their Agile community to one more fit for a technology organization. Specifically, one that fosters a more innovative, well-managed, and engineering-focused culture. From the adoption of CICD and DevOps, to containerization and serverless technologies in the cloud, change is all around us. But it seems the Scrum Master role has seen little to no change, and that’s not very Agile!
As alluded to previously, the Scrum Master role is just that; a role on an Agile team. It has been 18 years since the Agile Manifesto was published; today many teams are no longer doing the same kind of work they were back then. Beyond writing code, these teams are now expected to support an application’s entire pipeline from configuring the infrastructure, building the application from scratch, deploying it to production, and supporting it until the day it’s retired. Many of these responsibilities are new, certainly newer than the Agile Manifesto.
To support this change in work, new software delivery roles have evolved such as DevOps Engineers, Cloud Engineers, and Site Reliability Engineers. Why shouldn’t the Agile role change as well? Amongst a world of many technical transformations, perhaps the Scrum Master role no longer meets the same needs. This is why the next step in the Agile evolution is the Agile Delivery Lead (ADL).
We’ve realized that a Scrum Master should go above and beyond only upholding the values and ideals of Scrum and facilitating meetings. That’s not to say these don’t add value – they do – but we don’t want to pigeonhole roles into a single framework or methodology.
So what does an ADL do, you ask? Well, while Scrum Masters typically focus on upholding the values of Scrum, facilitating meetings and discussions, and removing blockers, you could say that the ADL does all this, while also focusing on a teams’ delivery. Engineers have a lot on their plate, so ADLs set out to keep them focused on writing software by helping to handle ancillary technical tasks beyond coding. This can involve anything from onboarding applications to various tools used for well-managed software delivery, taking the lead on application architecture review processes, preparing various documentation, and even seeking out new opportunities regarding production support and what we call YBYO (you build it, you own it). Let’s be clear though, we are not just swinging the pendulum to the other side and focusing entirely on the technical aspects. In fact, we’ve introduced some added coaching expectations, since at the end of the day, the ADL’s primary focus is on helping to create an environment where the engineering teams can deliver high quality, valuable software.
Another side effect of moving to a more “technical” Agile role focused on delivery is that it gives the team a second set of eyes during the design stages. ADLs are not coding on a daily basis, in fact coding abilities aren’t even expected, so we may have a different perspective that’s either backed up by past experiences, or even various delivery metrics. They have sharper technical chops to facilitate richer, more engaging discussions which helps them better meet team needs. Also, by removing “Scrum” from the job title you’re removing the impression of a mandate to abide by Scrum. So if a team wants to move to Kanban, XP, or some other Agile method, our ADLs should be able to help.
At the end of the day, the goal is to lead engineering teams toward delivering value for our customers. If it means digging in and getting their hands dirty to get something done, then so be it. Agile and Scrum isn’t a one-size-fits-all process, and at Capital One we get that.