Scrum Training in 4 Key Points

I had the opportunity to complete scrum training and become a Certified Scrum Master. Here are my takeaways.

I’ve spent a long time working with pseudo-scrum, scrum-adjacent, or almost-scrum teams, but have never completed formal scrum training or certification. That changed this month! I had the opportunity to complete scrum training and become a Certified Scrum Master. Here are my takeaways.

#1: Scrum is a communication framework.

Scrum training reaffirmed one thing that I’ve always known about the framework: it involves a lot of meetings. In fact, almost every scrum ritual boils down to some kind of formalized conversation.

This may sound a bit reductionist, but it explains why scrum has been so successful for highly technical product teams. The vastly different skillsets (and personalities) on these teams typically lead to a communication barrier between those who want deliverables (business analysts, account managers, etc.) and those who deliver them (developers). It can be extremely difficult to organize and prioritize when business-oriented teams and developers don’t speak the same language. Rather than trying to dissolve this divide, scrum acknowledges it in the form of well-defined roles (e.g. ‘Product Owner’ and ‘Developer’). It then outlines rituals during which these team members communicate and act on critical information. For example, during the sprint planning ritual, the product owner is tasked with presenting the what and why of items being considered for development. The developers are responsible for discussing how these items will be implemented. This type of communication is much more effective because team members understand the goal of each meeting and the information that they are expected to bring to the table.

So, while scrum is still considered a product development framework, its roles and rituals show that bilateral communication is so critical to product development that the two have essentially become synonymous.

#2: Wait until you need scrum.

As the previous section illustrates, the scrum rituals combined can take a significant chunk of time out of your team’s week. For small, focused teams, it often doesn’t make sense to do anything other than build (I’ve long been a fan of controlled chaos). But when is it realistic to consider scrum?

According to the official scrum guide, the ideal size of a scrum team is 10 people. That allows for 1 product owner, 1 scrum master, and 8 developers. While this isn’t a strict rule, it illustrates the size of a team that will truly benefit from the structure that scrum provides.

In addition to the size of your team, you should also consider your company’s business model when deciding whether you’re ready for scrum. Scrum has been proven to excel when implemented at SAAS companies with a clear product focus. If the majority of your revenue comes from large, contract-based deals, project management may be better suited to your needs.

Again, there is no hard and fast rule for who can implement scrum and basic cost-benefit analysis can typically show you whether it’s worth it for your team.

In fact, scrum can even be a stepping stone in converting your business to a SAAS model if you’re not there yet — just make sure to communicate this to your customers!

#3: Simplify your tech stack.

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.

The above statement, from the official scrum guide, does not mean that every developer on a scrum team has to be full-stack. It simply means that teams must collectively have the skills to be productive every sprint.

After reading this I started to think about the easiest way to ensure that our team members (particularly developers) together possessed the knowledge and experience necessary to generate value. My conclusion: instead of putting the responsibility on developers to learn new skills, we should limit “all the skills” that need to be mastered. In other words, why not just simplify your tech stack to make it more accessible to the various members on your team?

Consider languages that are well supported, have an easier learning curve, and will allow you to build practically anything (JavaScript or TypeScript). Also vet various serverless tools (i.e. Lambda or Google Cloud Functions) that will allow you to scale without slowing your team down with maintenance costs.

In the same way that there is no firm requirement for who can implement scrum, there is no ideal tech stack. You know your team, your product, and the tools that will help them succeed.

#4 Good scrum is firm but flexible.

One of my big takeaways from scrum training was that it’s easy to look scrum-ish without following scrum at all. Unfortunately, labels like ‘product owner’, ‘scrum master’, and ‘sprint planning’ mean nothing unless they are backed by a commitment to follow the underlying process.

This doesn’t mean your team has to be the spitting image of the agile scrum guide. As our trainer pointed out, scrum should be firm but flexible. In fact, the process itself is meant to be continuously augmented in the same way as the deliverables it produces: in small, functional increments.

In other words, start as close to the scrum guide as you can. Rigidly define your team’s roles, rituals, expectations, and responsibilities. Then, starting at your first sprint retrospective, identify incremental changes that will improve the process and try them out. For example, you might try a new metric to gauge the size of development items. After a handful of iterations (5–6 sprints), you should start to feel scrum fitting to your teams nuances and unique requirements.

Ultimately, good scrum is a constantly evolving process that stays true to the scrum guide, but adapts to the changing needs of your team, your business, and your customers.

As a quick recap:

• It can be helpful to think of scrum as a well-structured communication framework
• Scrum isn’t for everybody and can cause more pain for companies/teams who aren’t ready for it.
• Limit the number of skills your team has to master to be productive.
• Continuously inspect and adapt your process to ensure your team gets the most out of scrum.

If you are implementing (successfully or unsuccessfully) scrum on your team, I’d love to talk to you! Drop me a note on my website and we can set up a time to chat.