Agile

How to adopt Scrum in your team

Luis Ortiz

— 8 min read
How to adopt Scrum in your team

In our article The Perks of Being a Scrum Master - Developing soft skills and preventing anti-patterns, we stated how relevant the Scrum Master figure has become for the global market in the last 10 years. That trend relates to the fact that more and more companies want to be agile to effectively meet their customers' needs each time.

One of the most adopted agile frameworks is Scrum. Its basic structure is suitable for almost all kinds of industries, and it brings some inherent team-building practices that tend to benefit most organizations. That's why, this time, we put together sort of a Scrum quick start guide. We hope it can be helpful for agile rookies looking to implement it inside their teams.

Topics to check

  1. What is Scrum?

  2. The roles
    2-a. The Scrum Master (SM)
    2-b. The Product Owner (PO)
    2-c. The Scrum Development team

  3. The events
    3-a. Sprint
    3-b. Sprint planning
    3-c. Daily Scrum
    3-d. Sprint review
    3-e. Sprint retrospective

  4. The artifacts
    4-a. Product backlog
    4-b. Sprint backlog
    4-c. Increment

  5. Effectively adopting Scrum

1. What is Scrum?

Straight out of Scrum.org, "it is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems." It has a set of roles, events, and artifacts that enable agile workflows, which must be fully understood both by the team using it and the organization as a whole to really leverage its benefits.

Even if the company is not entirely shifting towards an agile approach for all their practices and processes, it's crucial to establish how the Scrum-oriented teams' work connects with other units, such as business, marketing, etc.

A good bet is to hire a Scrum Master, whose job, among other things, includes helping everyone "understand Scrum theory and practice, both within the Scrum Team and the organization."

2. The roles

Aside from the Scrum Master, the guide considers two more roles: The Product Owner and the Dev team. Each one has its own set of responsibilities.

2-a. Scrum Master (SM)

A leader with the primary goal to improve the team's practices and the organization. A SM is accountable for the effectiveness of the group. The principal activities of the Scrum Master are:

While serving the Scrum team:

  • Removing blockers or impediments so other members of the team can perform their job.
  • Ensuring all the Scrum events take place and are rightfully conducted.
  • Coaching the team members to learn self-management.

While serving the Product Owner:

  • Helping to define what the product goal is and how to compose the Product Backlog.
  • Making sure the dev team accurately understands the product requirements.
  • Supporting communications with other stakeholders.

While serving the organization:

  • Leading and coaching its agile transformation.

As you can see, the Scrum Master carries a lot on his shoulders, so you might be wondering if a single person can pull out the agile transformation your company requires. The answer is: It depends on the nature of the products, the teams' size, and several other factors. There is no restriction on how many teams a single Scrum Master should serve, as long as they can effectively facilitate and deliver for all of them.






2-b. Product Owner (PO)

Is who makes sure the work delivered by the Dev team actually maximizes the value of the product. A PO is accountable for:

  • Developing and communicating the product goal to all the stakeholders.
  • Creating the product backlog items and making sure the Scrum team has a clear understanding of them

There are some cases in which the same person performs the Product Owner and the Scrum Master roles. It tends to happen in small companies or teams, and, as in the case of the number of teams a single Scrum Master should serve to optimally function, it might suit some organizations' needs.

However, it's essential to address that the product owner serves as a bridge between the business unit and the development team. In contrast, the Scrum Master's primary focus is helping the team.

2-c. Scrum Development team (Dev team)

The Scrum guide describes them as "the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint." This team is mainly accountable for:

  • Defining the items that will be worked on during the Sprint, also known as the Sprint Backlog.
  • Sticking to what the definition of done is for their pushes and deliveries.
  • Helping to accurately estimate the effort a story or task may take.

So far, we have mainly covered how these roles function in developing a software product/service but remember that Scrum can be adopted in several areas. A marketing Scrum Dev team might be composed of account managers, content creators, campaign planners, etc.

As adaptable as it can be, not everything should be Scrum oriented. You might've heard the example of building a bridge across the river and how ridiculous it sounds to create it in a Sprint cadence, delivering increments based on the users' behavior. Yet, it could be done. And even if no one is building a bridge that way, there may be someone trying to stuff agile into its workflows just for the sake of doing it. But we'll review this topic in another article.

3. The events

Keeping agile means maximizing the investment of work time into actual improvements on the product to satisfy your customer needs. That's why, in Scrum, there exist prescribed events meant "to create regularity and to minimize the need for meetings not defined…" in the framework. One prominent feature of these events is that they must be time-boxed to avoid waste. The events are:

3-a. Sprint

The 'heartbeat of Scrum' -according to the guide- is a fixed-length event of "one month or less" with the concrete goal to bring an increment to the product. All the other events happen inside a Sprint, and there are some points to consider:

  • The product backlog can be refined as required.
  • The scope can be renegotiated with the Product Owner.
  • The quality of delivered work shouldn't decrease.

Each Sprint starts immediately after the end of the last one.

3-b. Sprint planning

The team establishes the work to be performed. It also serves to start a Sprint. According to Scrum.org, the planning session serves three main purposes:

  • Understand how the value of a product/service can be increased during the Sprint.
  • Select and refine items from the product backlog.
  • Define how will the selected items being worked on, conforming to the Sprint Backlog.

3-c. Daily Scrum

These 15-minute meetings (also called Stand-ups) are meant to review the progress towards the Sprint Goal. It also serves the team to communicate blockers or dependencies and adjust the Sprint Backlog.

It must be held at the same time and place every day. If you want to learn more, check our post 8 tips for better Stand-up meetings.

3-d. Sprint review

After a Sprint has concluded, the team gathers to review the accomplished work and how conditions have changed. It is also an opportunity to showcase the Increment to key stakeholders and obtain feedback. Some other features of this event are:

  • All the Scrum team must attend, plus any external stakeholder designed by the Product Owner.
  • The done and not done items are reviewed.
  • The group defines what should be worked during the next, which will serve as a foundation for Sprint Planning.

3-e. Sprint retrospective

Also held at the end of the Sprint, the purpose of this session is for the Scrum team to get together and review improvement opportunities based on how things went. The discussion centers on people, processes, and tools used, rather than work delivered. For your sessions to run smoothly and effectively, remember to:

  • Only invite the Scrum team members.
  • Make sure everyone feels comfortable sharing their opinion.
  • Prevent peers from blaming each other by defining a neutral approach to issues.

The best way to get relevant feedback from all the attendees is to ask the good old three questions:

  • What went well?
  • What did not go well?
  • What could be improved?

That's the usual technique, but there are many others you can try. Whether you're starting or want to improve, check out this post in our blog with more suggested techniques and tips.

Retrospectives must span action items, which are a concrete way to follow up on the improving commitments made during the session. The best way to host engaging sessions that will let all your team input their ideas and easily follow them is with the Retros app, available for Jira and Confluence (and coming soon to Trello). If you haven't had a chance, you can try it for free here.

4. The artifacts

These are the concrete representation of work to be done or how will value be delivered, and they are three:

4-a. Product Backlog

As stated before, it's composed of the stories defined by the Product Owner with the assistance of the Scrum Master. In the Scrum guide's words, it "is an emergent, ordered list of what is needed to improve the product."

4-b. Sprint Backlog

You can think of it as a diluted version of the product backlog, but including only the items developed during the sprint. This selection is oriented towards meeting the sprint goal.

4-c. Increment

The concrete output of a sprint is an increment, which is described in the Scrum guide as "a concrete stepping stone toward the product goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. To provide value, the Increment must be usable."

Several Increments may be delivered during a single sprint. It always depends on capacity and complexity.

5. Effectively adopting Scrum

Ok, shifting to Scrum might not be a piece of cake, but it ain't rocket science either. Knowledge Hut's Scrum Adoption Patterns and Practices put some exciting considerations on the table. We highlight two core ideas that might help you start your agile path:

  • Go all-in or select a pilot team(s) to start using Scrum. The first option can carry financial risks, so our advice would be to start gradually. You want to improve things, not break them.
  • You can choose a public display strategy, which relies on communicating the teams and products built with an agile approach. This may raise awareness but also resistance from some folks.
  • If you prefer the stealth approach, you must make sure to keep a small scope and wait until the delivery of the product -or the completion of the project- to publicly announce that it was created within. a Scrum framework.

Consider the fact that many freelance coaches specialize in bringing agile inside organizations, so hiring experienced people isn't your only option. It's always easier to perform these type of transformations with the help of a skilled person, but that doesn't mean you can't do it yourself.

In conclusion, it's crucial to fully understand the framework's components and goals before implementing it. Otherwise, you can disrupt your workflows and harm your budget. Never forget that Scrum isn't an end by itself but a way to deliver more value to your customers with less effort. If you're achieving that result, then you're on the right track.

We'll definitely check on the best metrics and KPIs to monitor your Scrum practices effectiveness in a future article. Keep tuned!

Highlights summary

In order to effectively adopt Scrum, you must first understand its main elements:

  • Roles - Scrum Master, Product Owner and Development team.
  • Events - Sprint, Sprint planning, Daily Scrum, Sprint review and Sprint retrospective.
  • Artifacts - Product Backlog, Sprint Backlog and Increment.

Regarding people, Scrum considers three main roles:

  • Scrum Master (SM) - In charge of making Scrum happen.
  • Product Owner (PO) - Translates business needs into stories so Dev team can work on them.
  • Scrum Development team (Dev team) - Work on stories and tasks to produce a Sprint Increment.

The three core artifacts in Scrum are:

  • Product Backlog - Composed of stories defined by the Product Owner.
  • Sprint Backlog - The stories that will be worked during the Sprint.
  • Increment - The delivered, functional work performed by the Dev team.

Are you adopting or looking to improve your Agile practices? Is your team remote? If your answer to any of these questions is ‘yes’, you should check out our products for distributed teams. We focus on making communication more effective and easier for remote teams.

Check out our other tools:

Stay on top of our upcoming releases:

And subscribe to our blog below!

Read more