Who thinks they do too much with minimal resources?
Everyone believes they are too stretched in their work and that budgets, resources and time are scarce for the exaggerated length of projects.
It turns out that most of us resign ourselves to mumbling softly or whispering complaints in the cafe.
But this wasn’t what Jeff Sutherland together with his colleague, Ken Schwaber, the creators of Scrum methodology, did.
Tired of being tasked with oversized projects that needed to be delivered quickly, they tried to find a solution by creating their methodology.
In this post, we’ll talk about what they came up with, so you can stay on top of everything regarding scrum.
All about scrum: a complete guide
Before you discover everything about scrum, it’s important to take a step back and talk about the agile methodologies within which scrum is.
Let’s go?
What are agile methodologies?
These methodologies arose initially from the agile manifesto.
It’s a manifesto created by many systems developers who, like Jeff Sutherland, were also tired of the bureaucratic demands and outdated methodologies that plastered their designs and inhibited creativity.
Therefore, they began a real movement of change in the way in which software was developed.
This methodology recommended, among other things:
- Rapid and flexible responses to changing scenarios
- Use Adaptive Action Plans
- Collaborative and rational teamwork
- Self-organization
- Incremental development of solutions based on customer feedback
The agile manifesto showed the way to arrive at solutions which also value the following points:
- Individuals and interactions over processes and tools
- Operating software over comprehensive documentation
- Customer Collaboration rather than contract negotiation
- Responding to changes over following a plan
Today, the concept has expanded, and not just software, but product development and team management in any area can follow the agile methodology, which highlights established methods such as Kanban, Lean and Scrum, among others.
In fact, from product roadmap to agile marketing management – among many other activities – can all be done with the help of the concepts defined by the agile manifesto.
If you want to learn more about agile methods, watch this HBR video:
https://www.youtube.com/watch?v=M6aShtkL6uwAfter this overview of agile methodologies, now yes, you will understand everything about scrum.
Are you ready?
What is Scrum?
The first step to knowing all about scrum is to understand its definition and its fundamentals.
The main foundation of scrum is empiricism, which states that all knowledge comes from experience.
The second foundation is the iterative approach, that is, incremental gains to each new empirical knowledge acquired.
Thus, everything that is done must be tested (with the help of final customers) only to turn into knowledge, which is used to make the result better and better, step by step.
With this in view, we can define Scrum with the following sentence:
Scrum is a method by which people can creatively address and solve complex problems – which are constantly changing – in order to develop products with the highest possible value.
It’s a rather pompous definition to say the following: Scrum helps teams solve problems quickly to deliver products that appeal to end customers (products that are of high value to them).
But for Scrum to function properly, it rests on three pillars.
Let’s check them out?
The three pillars of Scrum
According to the Official Scrum Guide, its three pillars are:
- Transparency
- Inspection
- Adaptation
See each one in more detail:
1- Transparency
All the characteristics of the project under development must have clear and objective definitions, common to all participants, so that they “speak the same language” during the execution of their tasks.
In addition, such information and definitions must be easily accessible to all and shared constantly.
2- Inspection
Inspections should be made frequently to see if the progress made so far really fits into the project objectives and end-user needs.
On the other hand, care must be taken to ensure that excessive inspections don’t delay work progress.
3- Adaptation
It’s at this point that the incremental iterations (small steady progressions) will start to get clearer for you.
If an inspection detects that some of the desired customer satisfaction aspects are not as you expect, the process or material you’re producing must be adjusted.
And this should be done as soon as possible.
Have the definitions we’ve shown you so far confused you a little?
Calm down; you’ll see that managing Scrum teams may be easier than you think. Soon let’s talk about the roles of everyone in the teams and how to organize the well-known sprints, among other Scrum events.
Stay strong!
The main roles in Scrum teams
There’s no way to know everything about Scrum without knowing some key roles in organizing your events during sprints (we’ll explain the sprints in detail, okay? – wait a bit!).
Scrum teams have the following roles:
- The development team
- The product owner
- Scrum Master
1- Developers
The development team is made up of the technicians and analysts responsible for creating and implementing the functionality needed to complete the project and deliver the product.
The team is composed of professionals with multidisciplinary and complementary skills who must act collaboratively and self-manage through the Scrum events that we will describe later.
2- The product owner
Known as the custodian of the interests of end users, the product owner is the “owner” of the product that is intended to be developed.
They are the professionals responsible for ensuring that the value perceived by end users of the product is always maximized during the development process.
The product owner is the only team member who can manage the product backlog.
Product backlog? – Yes, another “little name” for you to decorate!
But it’s easy: The product backlog includes all the tasks that the product owner defines as necessary to achieve the project objectives, contemplating the product with all the desired functionalities.
In other words, the product owner defines what the development team should do, playing a leading role in project management.
Here are some good practices the product owner should follow:
- Define product backlog items;
- Organize the order of backlog tasks logically and productively;
- Optimize the work of the development team;
- Make sure the backlog is accessible to everyone, transparent and clear;
- Make the necessary arrangements so that the developers understand the backlog tasks properly.
3- Scrum master
Yes, every Scrum project has a master!
If the product owner is the custodian of the end customer’s interests, the Scrum Master is the custodian of Scrum rules and procedures during project execution.
Your role is to help everyone understand your roles within the Scrum method, how to follow your procedures properly and how to attend the events.
They are the defenders of the Scrum values within the project and responsible for making sure the standards are never broken or there are never any behavior deviations.
In this way, they ensure that all iterations among team members lead to the value maximization of the product created through Scrum.
Here are some good practices that the Scrum master should follow:
- Make sure that the objectives and scope of the project have been understood by all;
- Define appropriate techniques for product backlog management;
- Make the necessary arrangements for the product owner to properly organize the product backlog;
- Understand agile principles and practice them;
- Train the developers to self-manage;
- Remove impediments to the development of value in products;
- Be a facilitator of Scrum events;
- Be a Scrum evangelist in the organization;
- Explain and clarify the concepts of empirical development of Scrum products.
Scrum events: how to organize inspections and iterations
Finally, you will discover in more detail what the scrum events are and how sprints happen!
After all, anyone who wants to know everything about Scrum needs to master its four events!
It’s through them that all these complex concepts that we describe above are put into practice in an agile and productive way.
Stay tuned for them so you understand how all this works.
It’s about time!
The four Scrum events are:
- Sprint planning
- Daily meeting
- Sprint review
- Sprint retrospective
We will now see how each of these events work, but before that, we need to understand what a sprint is.
What is a sprint in the Scrum method
The goal of standardizing events in the Scrum method is to reduce the need for meetings (great, right?) Because those events already provide the right time for the exchange of necessary information and feedback among participants.
These events are organized around what is called a sprint, which consists of a predetermined period, usually a month, during which some incremental functionality will be added to the product in development.
The sprints are run in sequence so that the start of one occurs immediately after the end of the previous sprint.
Let’s understand the events that make up a sprint?
But before you start reading, check out an illustration that represents a Scrum sprint and check it out whenever necessary:
Source: Scrum.org
1- Sprint Planning
Okay, it’s pretty obvious that a sprint starts with planning, but how does this work?
Every team must participate in planning, and it has the following characteristics:
- Planning can only last at most eight hours.
And you can be sure that the Scrum master will keep an eye on the team so this is followed to the letter!
At the end of the planning, these two questions must have been answered:
- What can be delivered as a result of the sprint increment we are planning?
- How will the work necessary to deliver the increment be carried out?
2- Daily meeting
The daily meeting usually happens in the morning and can only last, at most, 15 minutes, no more, no less.
It’s during this meeting that the developers, practicing self-management, define what will be done in the next 24 hours.
In addition, the teamwork inspection is done the previous day in a collaborative way, and the necessary adjustments are already included in the planning for value maximization.
The daily meeting should always happen in the same place and time to facilitate processes and avoid disagreements.
The Official Scrum Guide suggests an agile way of organizing what should be discussed in the daily meeting with each participant answering the following questions:
- What did I do yesterday that helped the development team achieve the sprint goal?
- What will I do today to help the development team achieve the sprint goal?
- Do I see any obstacles that prevent me or the development team from reaching the sprint goal?
3- Sprint review
At the end of each sprint, the review meeting is held.
Its purpose is to inspect the incremental gain generated and adapt the product backlog if necessary.
The meeting is informal and is intended to exchange feedback, promote collaboration, and motivate staff.
Its maximum duration should be 4 hours; if it’s a sprint lasting less than four months, it may be smaller.
4- Sprint retrospective
The sprint retrospective, also called the Scrum retrospective, is the moment when the team does a thorough inspection of their work and already thinks about a plan for improvements for the next sprint.
Don’t confuse the review with planning, which marks the beginning of a new sprint.
The retrospective meeting should last no more than 3 hours (beware of the Scrum master!) And its goals are:
- Inspect how the previous sprint unfolded in relation to the team members, relationships, processes and tools used
- Identify and order the key items that were successful and the potential improvements that can be made
- Create a plan to implement improvements in the way the scrum team does its job
Take a look at this chart which summarizes schematically a scrum cycle:
Now, do you know all about scrum?
Of course, mastering the Scrum method takes time and lots of practice.
But now that you know a great deal about it, we’ve reproduced a list of the main characteristics of this method, defined in an article written with the participation of Jeff Sutherland himself:
The Fundamental Principles:
Empower creative and multifunctional teams.
More favorable conditions for the adoption of the method:
- In companies with a creative culture, with high levels of trust and collaboration.
- Teams of radical innovation that want to change the working environment.
Functions required:
- Product owners responsible for ranking the priorities to be developed by the team to generate the maximum value for the final customers and also for the business itself.
- Facilitators of processes that guide the flow of work (Scrum masters)
- Small, multi-functional, self-managed and innovative teams.
Work rules prescribed by the method:
- Planning the sprint when everyone is preparing for the next round of work.
- Definition of a fixed time of consistent duration for the sprint (1 to 4 weeks) sufficient to create a product increment that can be delivered without overwhelming the team.
- 15-minute daily meetings to assess the progress and impediments that arise.
- Review sprints to inspect the new incremental work gain.
- Retrospective sprint so the team can inspect and improve itself.
What should be delivered (the “artifacts”):
- Product backlog, a fluid and orderly list of importance of potential features and product innovations.
- Sprint Backlog, the subset of product backlog items selected to be completed in the next sprint.
- Incremental gains for the work done.
Approach to cultural change:
- Quickly adopt prescribed practices, even if they are substantially different from those practiced by the rest of the organization.
- Map out the prescribed practices and then adapt them through experimentation.
Advantages:
- It facilitates radical advances while retaining the benefits of operating as part of the parent organization, despite using a different methodology.
- Delivers the most valuable innovations quickly.
- It quickly increases team satisfaction and happiness.
- Develops general management skills.
Challenges:
- Leaders may be reluctant to prioritize team initiatives and have to relinquish control in favor of teams that practice self-management.
- New management skills are needed to coordinate dozens or hundreds of multidisciplinary teams.
- Strictly fixed iteration times may not be adequate for some problems (especially those that arise daily).
- Some team members may be underutilized in certain sprint cycles.
Phew! You really can’t deny … That you now know everything about Scrum!
Do you use Scrum in your company?
Do you miss the traceability in this kind of process management?
And what about “rituals,” are they followed precisely?
Tell us in the comments.