In my classes I often liken an aspect of the ScrumMaster role to that of a sheepdog. That an important part of their role is protecting the team. Often the direction of this protection is assumed to be outward, for example, insulating the team from external interruptions.
In a recent newsletter (sent on September 22, 2016), Mike Cohn discussed this part of the role in more detail. He spoke to two areas of protection:
- From Management Dysfunction (external), and
- From Team Complacency (internal)
The thing that struck me in Mike’s post is the internal protection perspective, ie., protecting the team from “themselves”. It made me think about areas where a ScrumMaster can really help their teams in this area.
Let’s explore some specifics…
Protect the team…
- From under and overestimation. Both can be destructive, but that latter can be combatted by pulling work in. The former is harder to accommodate. Guide the team towards realistic estimates that vary less and less over time.
- From not listening to each other…deeply. Seeking to understand before simply responding or debating a specific position. Often this can be established with “ground rules”. It’s also a place where you can lead by example.
- From over commitment. Reality often includes things like interruptions, maintenance, support, etc. High priority things that undermines the team’s capacity. Teams generally are optimistic and forget “reality” when making commitments. Particularly under pressure.
- From not understanding their capacity and striving for predictability. A part of over commitment is not clearly understanding your velocity and historical turbulence. Additionally, it’s striving for predictability over a specific number.
- From “mailing it in” at retrospectives. Boredom, repetition, not doing anything with the results, hard challenges, etc. all can cause teams to disengage. Look to create engagement and accountability around the notion of continuous improvement.
- From allowing “them” to influence team decision-making. Teams need to be encouraged to make the “right” decisions without being overly influenced by their leadership team or other outside forces. Establish a charter (guard rails), then let the team decide how to meet the challenges.
- From not considering context and Yesterday’s Weather. Again, this relates to capacity management and truly paying attention to history as a planning partner for future commitments. This even relates to user stories and the notion of “reference stories” as a means of tightening up estimation.
- From thinking that core Scrum is “optional”. Scrum is a very simple set of interrelated practices. While you can “pick & choose” a subset of things to apply, it vastly undermines the results. You see, the practices are interrelated IF you wish to realize the tremendous promise of agility (results) in your teams.
- From marginalize Leadership; not respecting or being empathetic of their leaders. This would also include trust. We often need to remind the team that their leaders are human too. They make mistakes, are under pressure, and that the team should look to partner with vs. partition leadership.
- From not being totally transparent. Usually organizational cultures struggle to handle the “Truth” that the agile transparency provides. So, many teams “hide” aspects in order to make the truth more palatable. Help your teams to courageously make EVERYTHING transparent; the good, the bad, and the ugly.
- From a lack of team courage. My favorite core Scrum value is courage. It permeates all of these protections. Often the ScrumMaster needs to be the most courageous when protecting their team. The example you set, can then open the door for the team to behave more courageously.
- From a fear of failure or ramifications. Extending from courage is the courage to strive for creative and innovative approaches. To try new things. To stretch and take risks. And yes, to sometimes fail. I’m convinced that the greatest agile teams look failure in the eye and courageously strive for continuous improvement.
- From not holding to their quality values; cutting corners. A core part of agile is doing things “right” the first time. Holding quality dear as a team. A clear measure of a commitment to quality is when the going is tough or the pressure is on. Then ask – does the team hold to their quality commitments, definition of done, and agile principles?
- From thinking that “agile” teams do little/no planning or forward-looking analysis. Agile planning usually takes place in the backlog. There is: backlog refinement, sprint planning, release planning, road-mapping, activities story-mapping activity surrounding the backlog. Healthy look-ahead, is a fundamental practice of solid agile teams. Not too little and not too much, but a healthy balance.
- From not understanding and supporting the healthy interplay across the core Scrum roles. Each of the roles (ScrumMaster, Product Owner, Development Team) has special focus points and responsibilities. While there should be collaboration across the entire Scrum team, in the end each role has unique responsibilities that need to be understood, supported, and trusted.
- From distrusting each other. Trust is a 360o element in all organizations. It’s not just around leaders trusting the teams. It also affects team member to member trust. For example, trusting someone’s estimate, their recommendation, or their ability to represent the team in a meeting.
- From avoiding having the “crucial conversations” that will make the team great. Confront all behaviors or practices that are preventing the team to excel. Open and honest and non-personal confrontation. And deferring conversations, hoping that things will magically get better, is usually not a sound strategy.
- From not taking the Sprint Demo as seriously as they should. It’s a phenomenal opportunity to be transparent and show “where the rubber meets the road” for team work. It also allows for feedback – leading to adjustments. And heck, the team might even get positive feedback every so often.
- From considering EVERYTHING to be a “management problem”. I find many teams “looking up” at management and blaming them for all of the teams’ ills. While management can often be dysfunctional, there are usually many challenges that the team can mitigate and/or resolve on their own.
- From taking themselves too seriously. Yes, software is a serious business, but taking time for an occasional break and having some fun can really set a different tone within the team. Look for daily opportunities to inject “fun” into the team – no matter what is going on in the sprint.
- From being too collaborative. Remember that not ALL decisions need to include EVERYONE on the team. I sometimes think that teams can overdo their collaboration. Sometimes team trust plays a part in this. Try to help the team achieve a balance of – entire team for important work/decisions, but subsets for everything else.
And finally as Mike said, from complacency. Many of the ideas I’ve listed could be categorized under complacent behavior.
But protection can take different forms
I thought it important to explore the various forms that protection can take. I think most of us view it as attack dogs and electric fences. That extreme level may be required at times, but it can also be a bit subtler than that.
Direct Protection
Direct protection is when you intervene on behalf of the team. This could be a direct comment or observation in a team retrospective. Or asking someone to stop interrupting the teams work from the outside-in.
Indirect Protection
Another way to explain this is “behind the scenes” protection. For example, when a leader is interrupting the team, you sit down with them 1:1, explain the impact and look for alternative ways for them to make requests of the team. Another way to do this is by setting organizational guidelines that protect specific situations.
Learning Protection
This is one of my personal favorite protection mechanisms. It involves letting something fail and then helping the organization or team learn from it. Retrospectives can be key here. Or simply using an example in future conversations with stakeholders in a “remember when” fashion.
Wrapping Up
I want to thank Mike Cohn for inspiring me yet again. It’s amazing how, after all of these years, he continues to be a thought leader in our space.
And for all of you ScrumMasters reading this article, I hope I’ve inspired you to be more active in your team protection. I really like the “sheepdog” analogy for your role and I hope it doesn’t offend anyone (ScrumMasters = sheepdog) and (teams = sheep).
It’s the ever vigilant and protective stance that I’m going for. And sheep rock too!
Stay agile my friends,
Bob.