How to Introduce Your Team to Scrum
The number of companies keen to adopt Scrum has been ever-growing over the last decade. Businesses want the advantages Scrumoffers such as improved customer satisfaction, reduced risk, faster delivery of a better-quality product, the ability to react quickly to the changing market environment, and a faster return on investment.
It’s usual for companies to try Scrum out in one ‘pilot’ team before scaling it up across the whole organization if it’s successful.
Some companies do ‘stealth’ Scrum adoption, which means they only reveal the project was run according to Scrum when it’ssuccessfully completed. Others openly announce their adoption of Scrum and get their clients and stakeholders on board.
So how can you introduce this new framework to your team effectively?
Focus on the goal
If you have buy-in from your executives, explain why you are adopting Scrum to your team and others in your organization. Try to get your team motivated and energized by the concept of Scrum, make sure everyone knows what the goal is.
Explain what changes in the work process Scrum will bring about
Let the team know how Scrum will change the way work is organized in your team. Your team are going to work in sprints and take part in events prescribed by Scrum, such as sprint planning, daily scrum, sprint review and retrospective.
A dedicated Scrum master leads the way
You will need a knowledgeable Scrum master to plan and lead the adoption of Scrum in the team and the organization as a whole.
Introduce the main concepts of Scrum
Scrum is based on empiricism, the idea that knowledge comes from experience. Software development is very complex and what will happen is uncertain. That’s why Scrum teams don’t try to make the perfect plan or forecast every eventuality. They make decisions based on the experience they gain as they move forward in the process.
The team constantly inspect their product and the way they work and quickly adapt and improve if something isn’t going well.
Empiricism, transparency, inspection, and adaptation are what Scrum is based on. And the whole team needs to know why they are so important.
Embrace the Scrum values
Successful Scrum teams live by the values of commitment, focus, openness, respect, and courage. These aren’t just words, these values come alive through the ways the team members interact and communicate with each other.
Scrum requires a certain change of mindset, and the Scrum master makes sure that everything the team does strengthens the Scrumvalues instead of undermining them.
One of the Scrum values is respect, and, as such, it must be embodied in Scrum events. For example, at the sprint retrospective no blaming language should be used, and the focus should be on what the whole team did or didn’t do well, instead of pointing a fingerat a particular team member.
Educate, coach and support your team along the way
The Scrum master educates the team about Scrum roles, artifacts, events, and values. He or she conducts Scrum workshops and training sessions on estimating, planning, Scrum values and other areas. The Scrum master promotes continuous learning and improvement.
Assemble your team
A Scrum team consists of a product owner, a Scrum master, and developers. The product owner is the one who maximizes the value of the product. He or she formulates the product goal and decides what features are going to add most value to the product and are going to be delivered first. The product owner manages the product backlog: a prioritized list of the work needed to improve the product.
An engaged Scrum master is responsible for Scrum running smoothly. He or she is responsible for the Scrum team’s effectiveness. The Scrum master protects the team from external interferences and removes any impediments coming their way.
The developers are the people who create a valuable increment of working software every sprint. There are no hierarchies in a Scrum team, the team are a single organism focused on the product goal.
The right team size
A Scrum team is 10 or fewer people. It needs to be large enough to complete a significant amount of work in a sprint. However, with too many people communication may have a negative impact on effectiveness. Some agile coaches think that 5-6 people may be the sweet spot in terms of the team size.
Scrum teams are cross-functional, which means that the team members have all the skills necessary to create value each sprint.
Your Scrum team also needs to aim at being self-organizing: the team themselves decide what to do and how to do it, instead of being told by an authority.
Get ready to sprint
With the motivated Scrum team assembled, they set their sprint duration, a month or less, usually two weeks. A sprint is the container event in Scrum where a valuable increment of software is created.
Schedule Scrum events
Scrum prescribes four Scrum events within a sprint: sprint planning, daily scrum, sprint review and retrospective. All of them are time-boxed, which means that their maximum duration is capped.
Plan your first sprint
Sprint planning is an event where the team plan their work for the next sprint. The product owner and the developers discuss the most important product backlog items and the value they can bring to the product. The developers then select the items to take into the next sprint and collaboratively come up with a plan on how to deliver them.
Every day of the sprint the developers meet to synchronize their efforts towards the sprint goal. This event is called daily scrum and is timeboxed to 15 minutes.
At the end of the sprint the team present what they have done to the stakeholders at a sprint review event. Based on the stakeholders’ feedback and any changes in the market, everyone then discusses what to do next.
Last, the team hold a sprint retrospective, the goal of which is continuous improvement. The team discuss how the last sprint went, look at the successes and failures and identify the changes they are going to introduce in the next sprint.
During the sprint the Scrum team also do product backlog refinement activities when they discuss and prioritize product backlog items and add details to them.
Determine your definition of done
The definition of done describes what quality requirements your software must meet, for example coded to standards, code peer-reviewed, acceptance criteria met, thoroughly tested by unit and integration tests, and accepted by the product owner. Only when these criteria are met, is the work considered ‘done’ and the software becomes a valuable increment.
If any user story or task doesn’t meet the DoD, it isn’t presented to the stakeholders at the sprint review, doesn’t become part of the increment and goes back to the backlog. No ‘almost done’ software is accepted.
The team collectively define their definition of done. As the team get more experienced in working together, their definition of done gets updated to include stricter criteria, thus improving the quality of the product.
Now your team are ready to begin their Scrum journey.
Get sprinting!
Photo source: pexels.com
