Is Your Scrum Team Good Enough?

If your Scrum Team has been together for years and you’ve been following the Agile principles and Scrum structure, you might be feeling quite confident. Scrum isn’t an inherently easy methodology to adapt, especially since it requires change beyond the personal behaviour level to see the biggest results. So if your team has gotten to the point that your retrospectives are empty and your improvement list is slim to none, pat yourselves on the backs!

… And then put your arms down, because there is still much work to be done.

Many teams stop growing because they become satisfied with the status quo. The ScrumMaster is expected to challenge them to continue growing. Just because your team has stagnated and you don’t know where to improve, doesn’t mean that you can’t be even better. Good is good, but great is better. And if you’re a ScrumMaster, your role is critical in that evolution. In fact, it’s your responsibility to not rest on laurels, and to tackle some of the more advanced, but incredibly beneficial, aspects of Scrum.

Is the ScrumMaster a Temporary Position?

On a regular basis, I have people ask me, “The ScrumMaster role can’t possibly last for more than 6 months, can it?” and “Does a team benefit from the ScrumMaster being full time or is 33% enough?”

Since many invest time and money into becoming a Certified ScrumMaster to advance their career, that seems like an important thing to know. But before we answer those questions, you need to first know the answers to these:

• What is the purpose of Scrum?
• What is the purpose of the ScrumMaster?

Luckily, we can find those answers in the Scrum Guide. “Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.”

The Guide goes on to say that the ScrumMaster role is “accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.”

The Scrum Guide assigns responsibilities to the ScrumMaster under three general groupings: serving the team, the product owner, and the organization. Many of these often get ignored. Do yourself and your team a favour and review it frequently.

If we walk through every element of this, the blog post will be 7–8,000 words long which, in itself, is a hint that there is much more to the ScrumMaster role than is often explored. So I will highlight only a few key items.

Coaching to self-management, what does that require?

• Ensuring the team understands its purpose
• Helping the team establish role clarity
• Finding what motivates each team member
• Helping the team to create working agreements for team effectiveness
• Empowering team members to make their own decisions
• Ensuring that all members of the team have an equal voice, not just the loudest
  (Cough, cough – I was often the loudest person on a team. Sorry about that.)

Depending on the prevailing culture in the work environment, some of these, like empowerment and equal voice, may take more time to establish and the ScrumMaster is responsible for creating an environment that allows and encourages that to happen.

Coaching to become cross-functional

The team will need to learn skills outside of their normal area of expertise to keep things moving whenever some of the team gets stuck or there are bottlenecks in an area. Ideally cross-skilling starts early, however it will take many months before it becomes habitual.

The ScrumMaster is responsible for coaching team members to pay attention to bottlenecks in the system and for facilitating this learning. Sometimes cross-skilling goes against the corporate grain, on other occasions team members would prefer not to learn new skills or feel reluctant to work outside their comfort zone. Cross-skilling is critical to an effective team, so it falls to the ScrumMaster to coach in this situation. The ScrumMaster is going to need a good understanding of human motivation and also how to influence effectively to help people, and organizations, see the benefits and come around.

Creating high-value increments that meet the Definition of Done

This is a very subtle one. Most teams (Scrum or otherwise) struggle to deliver high-quality product at the start. Scrum expects the team to grow their skill and collaboration to improve quality. As a team meet the existing Definition of Done, they’re expected to add more rigour to it. As the rigour increases they will need to slow down for a period of time until they’re more technically skilled at achieving Done. Once again, as they get good at meeting Done, they should increase the rigour. (Hint: this quality improvement cycle should never stop).

DevOps
Some teams are satisfied with a product that they hand off to another group for deployment and monitoring. From a Scrum perspective, this is a strange choice. A Scrum team should keep improving Done. In the world of modern software development, the Scrum Team should be embracing a DevOps mindset: the team that builds the product is responsible for deployment and monitoring. Caveat, from experience it can take more than a year for the team to build this degree of technical excellence.

After all, the customer doesn’t see the value of what the team delivered until it is deployed. And if it’s delayed in getting deployed by a different group, that increases the cycle time and so, from the customer perspective, the work is delivered slowly. Even in the modern age, I’ve seen Scrum teams deliver working software every two weeks only to be stuck waiting 6+ weeks for their work to get released. In addition, as the application is being prepared for deployment, problems are often found. The longer it has been since the original work was done, the more time it will take to remember what was going on and fix the problem. Building to a high-quality definition of done and releasing it, all within the same team, finds and fixes problems faster, avoids confusion and conflict over responsibilities, and delivers to the customer quickly.

Note: Some organizations put up significant barriers that make it difficult for Scrum teams to move downstream into the DevOps space. It is still an important class of improvements, however it may be easier to start working upstream first.

Agile Engineering
Creating high-value increments isn’t limited to DevOps improvements. Teams also benefit from learning to practice the many Agile Engineering practices, from Ensemble Programming to Trunk-Based Development.

ScrumMaster and Product Ownership

Some see the ScrumMaster as having only the responsibility of ensuring the Product Owner established the Product Vision, a Strategy (i.e. StoryMap), and Backlog Refinement. That is a good start, but by no means all that they can – or should – do. When a team has a casual relationship with the Product Owner and the Product Backlog, we have a higher likelihood of quality issues or rejected Product Backlog Items in the Sprint Review.

One way an effective ScrumMaster serves the Product Owner is by coaching the team to have a broad and deep understanding of the Product/Consumer/Need, illustrated here as a Scrum Product Team.

The team implements this in areas such as Behaviour Driven Development (aka BDD) to ensure that the acceptance criteria for a given Product Backlog Item are both clear and agreed on by all. Many ScrumMasters are also discovering that it helps to coach their team in Lean Startup and Lean U/X.

Becoming Lean
Lean Startup is useful when the team needs do fundamental experimental work answering questions such as: Will anyone pay for this product? Is this module or large feature area useful to our audience?

Lean U/X involves the whole Scrum Team in improving the experience of the consumer in using the product.

Continuous Discovery
Some teams go further still, working with the Product Owner in the Discovery process, ensuring the whole team has a solid understanding of the customer need at that moment. (The best description of this process remains Teressa Torres Continuous Discovery Habits). Like the Definition of Done, all of the improvements the team make to working more effectively with the PO will take time and slow the team down. From personal experience, teams take well over a year to work their way through these skills.

Serving the organization

The ScrumMaster is responsible for looking at the systemic issues in the organization that harm the Scrum Team and their ability to deliver. They’re expected to help others see these issues and then coach their resolution. They might need to coach Stakeholders on appropriate moments to interact with the team (e.g. Sprint Review), and help them see the costs when they interfere (e.g. Hidden or Ghost Work).

Wait, You Didn’t Answer the Earlier Question

Will being a great ScrumMaster lose me my job?

You’re correct, I didn’t answer this, and here’s why. An effective Scrum Team isn’t measured by its velocity; Scrum isn’t about the team churning out more User Stories. Scrum, for all of its simplicity, is actually very complex, and practicing it doesn’t equal using JIRA. When the focus is placed in the wrong place, Scrum is reduced to a mechanical task management system and Developers are turned into robots. It’s not listed explicitly in the Scrum Guide, but it’s a ScrumMaster’s responsibly to not let that happen.

Instead, effective Scrum Teams should eventually discover all of the things described above until they look like a  truly cross-functional Scrum Team. Clearly no team will get to this point after six months. I can’t imagine a team getting there in less than a year.

Once the team is truly self-organizing, the ScrumMaster should become less and less important. But there are still risks if/when they leave the position:

• Will the team fall back into old habits?
• Will they keep being challenged to grow?
• What will happen when a new team member joins the team? Or an experienced, reliable team member leaves?
• Who will tackle the systemic issues in the organization? This may be the hardest part of Scrum. It doesn’t make it any less important. There will come a point where any effective team (Scrum, Kanban or otherwise) runs into limits imposed by the organization. Without fixing these issues, progress of all teams would be limited.

There are also risks if one ScrumMaster stays with the team forever:

• The team might become complacent.
• The team/organization become dependent on the coach to help them find and solve problems.

Does a Scrum Team need a ScrumMaster full time as they go through the process of discovering and mastering all of these skills? Only you can make that call. But certainly in the early months and years of development, having reliable and consistent access to a ScrumMaster who offers that service and coaching will bring greater benefits than not.

I can say that we all benefit from having a coach. From my own personal experience, my periods of greatest growth have been when I talk to my coach and discover all of the new opportunities standing in front of me. Also consider that, in a complex environment, just as we think things are tidy, safe and well established, something new (e.g. pandemic) shows up to destabilize again.

I suspect the fundamental question that needs to be answered is what are the limits to growth for a Scrum Team? If your team is stuck inside very tight limits as illustrated by the “Typical Scrum Team” arrow, then the team will run out of growth opportunities sooner. In this post I’ve illustrated a few areas (among many) of possible improvement:

• high-value increments (DevOps  Mindset, Agile Engineering Practices)
• broad and deep understanding of the Product/Consumer/Need (Lean, Continuous Discovery)

Some teams improve first by going downstream (DevOps), others upstream (Continuous Discovery), and some improve in both directions at the same time. There is no recipe, just opportunities.

Exploring any one of these with a team will likely take a large chunk of a year. Together, they represent years of work. So, yes, in theory eventually a team might hit a limit where the ScrumMaster is no longer contributing to the team’s growth, however few teams attempt to achieve truly cross-functional Scrum Team status and, even those who do, remain vulnerable to change where coaching would be needed again.