the champion model

Table of Contents

Key Takeaways

• The Champion model helps fill skill gaps in agile squads by empowering team members to take ownership of key areas.
• Champions are passionate volunteers who drive collaboration, knowledge sharing, and continuous learning within and across teams.
• Champions should focus on owning their subject, setting clear measures of success, fostering communication, and building a knowledge base.
• Security Champions are a prime example—embedding security early and improving practices without adding new hires.
• The approach is flexible and can apply to many specializations, from automation to compliance, bringing real value by breaking down silos.

When building our diverse, effective, multi-discipline teams it is important to be mindful of the current and potential profile of skills within the teams. Often, people within teams have cross discipline interests and the opportunity to explore or exercise them is not presented often enough in a high pressure, time sensitive delivery scenario. A model which I have personally found great success with (both as someone working as part of a squad and as someone who is building out a new squad) is the Champion model.

So what exactly is a champion? I won’t bore you with a dictionary definition, instead I will give you my interpretation of a champion…

A champion within an agile squad is someone who can compensate for a lack in any skill set among the existing team by providing expertise, facilitating knowledge transfer, raising awareness and encouraging collaboration between not just the members of their squad but across other squads too.

Champions are not often thought of as part of the initial squad makeup, usually the need for a champion is identified as part of a retrospective or an analysis into gaps in the squad after a sprint/series of sprints - that is where I personally think the value in  a champion truly lies. Someone who is able to take ownership for a gap in skills/knowledge and drive improvement and collaboration on that topic/subject.

You may be worried as a squad lead or scrum master that this model might lead to bloated squads, adding more resource any time there is a gap identified, or the management team thinks there is a lack of knowledge/understanding on a specific topic, but the champion model  actually works best when there are no new additions to the squad, since it is likely that your champion is already part of your team.

They are a colleague who is already involved with and familiar with your product/initiative, but who might be showing a keen interest in a particular area. They could be a developer, QA, architect, or DevOps colleague - the role is not significant, the key thing is passion for the particular subject area.

Furthermore, they don’t need to be senior, but management needs to see the value in having this champion to provide them the right support. Extra work will be required, so having a willing ‘volunteer’ with a keen interest in the role is important to ensure they are effective and stay engaged.

Ideally (often, it won’t work otherwise) your champion should be a volunteer or someone who is nominated based on visibility of their own interest or passion in a particular subject area. Often, the benefits of the model not just to the overall team/programme will need to be made clear, but also to the individual. Someone is more likely to be motivated to succeed under this method if they understand the benefits to their team and to themselves - whether that is self-development – adopting the role of a champion can help advance the career of an individual and increase their value and eminence within the organization. Champions should aim to be SMEs of the particular topic and they can’t always be expected to know everything off-of-the-bat … so opportunities for training, engagements and conferences should ideally be offered to the champions where possible.

So, you’ve identified the need for a Champion in your squad. You have a passionate, enthusiastic volunteer. Now what are the responsibilities of your champion? How does it change the day-to-day dynamics for the Champion?

The champions should be responsible for 4 key things;

• Owning the subject area within the team
• Defining key metrics or identifiers to measure the success of their efforts
• Establishing the required communication channels
• Building a knowledge base for the team and wider organization

Whether qualitative or quantitative, there should always be a way to measure the impact (and hopefully, success) of a champion. Whether these metrics and goals are established as part of a sprint, or as part of a wider plan doesn’t matter too much - it is more important that these objectives are clearly documented, presented and agreed with the team to ensure that there is buy-in and universal understanding of the proposed benefits, hopefully both short term and long term.

Communication is vital, but even more important is collaboration. Breaking down silos and streamlining communication between disciplines and teams is a key tenant of the agile methodology, and your champion should embody that. They should aim to identify where communication and collaboration could be increased to achieve the goals mapped out in point two.

In all sense of the word, the champion should own their subject matter within the team. After effective communication and knowledge sharing, in between the workshops and ideations should be a process to document and store information, new ideas and lessons learned - anything to the benefit of the common understanding in the team.

Having said all of that - overall, I believe the responsibilities of a champion, not matter how complex or misunderstood the subject matter, can be summed up in one very simple term - empowerment. Empowerment for the team and driving successful outcomes.

You might have gotten this far (well done!!) and whilst, hopefully, the benefits of the Champion model are clearer to you now - you might be struggling to visualize what this might look like in your team. Where do I need a champion? You may be asking yourself. How about a real world example then? Let’s start with an easy one, the Security Champion.

Now - you’re probably thinking -  “security is always one of our key principles” - and you’re probably right. But, how deep does that go? How far left have you shifted security conversations? When does security start to form part of the conversation and decision-making? If you’re not thinking about security before discussing features and breaking down those features in to user stories and PBIs - you WILL benefit from a Security Champion.

Security champions help to bridge the gap between a developer who knows about security best practice and a development team who thinks security-first, shifting the security conversations and assessments so far left, the considerations and requirements around security for a given feature or work item are always on the tip of the tongue across the team. Your security champion understands the developers (even if they themselves are not a developer) in your team, they can articulate security concerns in a way that engineers will understand and be able to consider and eventually implement. By imbedding your champion in both peer programming and code reviews (be it merge requests or ad-hoc reviews of WIP features), they can improve code quality early in the development lifecycle and crucially reduce security efforts later on.

Your security champion should be responsible for the 4 high level outcomes I outlined above;

Owning the subject area

Your champion should be involved in the high level conversations at the roadmap level, helping to inject the “what about” questions when it comes to security and compliance and further down the line they should be proactively evaluating code for security issues and taking responsibility for raising issues that require the involvement of the security team.

Defining key metrics or identifiers to measure the success of their efforts

You should work with your champion to agree and document these KPIs near the start of the sprint, whether it is security scanning coverage of published containers or the number of NFRs tagged with security against user story work items, your champion should own the “improvement” in these KPIs and be able to not just demonstrate improvement but effectively tell the story of their journey and communicate the benefits of those improvements to a wider audience (not just a squad retrospective)

Establishing the required communication channels

Collaboration is key. As such, your champion should be establishing a network with other champions (maybe they’re security champions, but maybe they’re not) and stakeholders, attending regular meetings and workshops to ideate, innovate and share ideas and lessons learned whilst assisting in making security decisions across the teams.

Building a knowledge base for the team

Your champion should be responsible for creating (or maintaining, if one already exists) an internal base of knowledge, which should be the main focal for security-related information. Knowledge is key, and your security champion should aim to benefit from ongoing training to keep up-to-date with the latest practices, methodologies and tooling to share this knowledge. A knowledge base should ideally provide structure and direction to your organization’s security approach, policies and procedures and may for example include information about vulnerabilities and risks relevant to the organization or products as well as best practices e.g. secure coding, secure by design principles, threat modelling.

And it doesn’t stop with Security. I’ve seen (and helped to implement and mentor people into) champions in multiple different disciplines. It might be an Automation Champion, Compliance Champion, Test Champion or Ops Champion. The possibilities are far and wide, but hopefully the benefits are clear to you now.

Champions are not alone and often, the foundation for the subject matter area has been laid elsewhere in the organization. Sometimes, it just takes a bit of a can-do attitude and critical thinking to bring together those disparate conversations and like-minded people to take charge of something within an organization and be able to demonstrate real value in collaboration, cohesiveness and who knows, you might just end up with more than just a good strategy on the other end.