What is the difference between a successful and unsuccessful team? Success can be measured in several ways, but the measurement we like to use are goals. Successful teams are able to reach their goals while unsuccessful teams often do not.
Most successful teams follow a process to guide them through the daily activities that will help push them in reaching their goals. At Asian Efficiency, our team uses the Scrum framework for us to reach our short and long-term goals. In this article, we are going to go over the basics of Scrum, how Asian Efficiency uses Scrum, and how it helped us become a more successful team.
What is Scrum?
According to Scrum.org:
“Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”
Now what does this mean in plain English? I like the definition that TechTarget gives:
“Scrum is a framework for project management that emphasizes teamwork, accountability and iterative progress toward a well-defined goal.”
The key words in that definition being teamwork, accountability, and iterative.
Here at Asian Efficiency, it is the framework we use to make sure that things are moving forward according to our goals. We use these goals as our guide to steer the company forward or to where we want it to be. The Scrum framework allows us to break down big projects (or goals) into smaller stages while being able to review and adapt along the way.
What Is The Main Benefit of Scrum?
Scrum allows the team to effectively communicate, collaborate, and iterate. Communication is key to a great Scrum Team because it provides visibility on how everything is moving. Collaboration also helps the team to be productive because it allows the team members to play off each other’s strengths and produce the best possible result. Iteration is important because at the start of the project, you may not have all the information you need or you may make assumptions about what the customer or stakeholder is looking for. By iterating, you are able to get frequent, actionable feedback before it is too late.
How Scrum Works
Scrum is a combination of people (the team), events (the meetings/discussions), and artifacts (the things you need to use scrum).
Let us first go through the Scrum Team (people).
The Scrum Team is composed of the following people:
- Product Owner
- The Development Team (or The Team)
- Scrum Master
The Product Owner visualizes or has the vision on what he or she wants to build or to develop based on what the customer or end-user needs. This is then translated into a backlog of tasks that the team will be working on.
At AE, this is Thanh’s role. Aside from being the CEO of Asian Efficiency, he is also our Product Owner. Every start of the quarter, he meets with the leadership team to discuss and plan out what we will be working on for that quarter. These plans are then converted to tasks in our backlog, and he will then prioritize these tasks for the team. (We’ll be covering the backlog soon — think of it as the list of things to be done.)
The Development Team works on this backlog of tasks until it is moved to done. Since Asian Efficiency is a small team, we wear many hats and although Thanh is the Product Owner, he is also part of the Development Team since he also works on tasks.
The Scrum Master is the team’s servant leader. In Asian Efficiency, I am the Scrum Master. I help the team overcome hurdles or distractions so that tasks will get done and the vision of Thanh becomes a reality. I am also part of the Development Team.
It’s normal to have tension between the roles. For example, Thanh might get some push back if the team thinks that the workload is too much—or too little. But one of the great things about working in AE is that this type of discussions are always welcome. We can disagree but still come to a point of understanding and at the end of the day, we still are able to work towards the same goal.
The Scrum team has defined roles and ideally, it should not cross over. For example, the Product Owners should not be a part of the Development Team or be the Scrum Master. But for smaller teams like ours, it can still work since we wear many hats.
Scrum events help foster open communication and transparency in the team. This also allows the team to work efficiently, effectively, and be able to make improvements.
The Sprint is the heart of Scrum. Everything revolves around it. It is a time-boxed event that repeats. For example, AE uses a two-week sprint which means that our goal is to finish everything in the sprint backlog within two weeks and at the end of the two weeks, we start another two-week Sprint.
The other Scrum Events are:
- Sprint Planning
This is when the Product Owner and the Scrum Team discuss what will be included in the sprint or what will be worked on.
- Daily Scrum
It’s a daily scrum team meeting that allows the team to check in and give progress on their tasks. It’s also when the team shares what they plan to work on that day.
- Sprint Review
When a sprint ends, the team gets together to review what has been done. This is also the time when the team can demo what they have accomplished. Feedback is also discussed during the sprint review.
- Sprint Retrospective
This is the last scrum event where the team discusses what could be improved.
Although it may seem like a lot of meetings, you can time-box these events so that you can make it tight or combine some meetings. For us in Asian Efficiency, the Sprint Planning, Review, and Retrospective is just one meeting and we time-boxed it to 1.5 hours. The Daily Scrum is also relatively short. The longest is probably 5 minutes.
These artifacts represent the work which provides transparency and opportunities to be inspected and adapted. Although the technical term is artifact, these are just things we use in Scrum to keep track of what needs to be done.
The three main artifacts are:
- Product Backlog
Think of it as THE to-do list that never ends. Projects, goals, visions are all added to the product backlog. Thanh, the product owner, is accountable for this and only he can add to it.
- Sprint Backlog
These are product backlog items selected for the current sprint. It is up to the team what items get added from the product backlog since they are the ones who knows what can be done and how it should be done. The Sprint Backlog tells the entire team (PO and Scrum Master included) what the team will be working on for the current sprint.
This is the sum of all the items from the product backlog that has been done. Each item in the product backlog has its corresponding number of points depending on the complexity and the time it will take to finish it. The increment will help the team determine if they are near their goal when it comes to the points.
Putting it all together
Let’s go through an example of how we at AE use scrum so that you can see how it all works together.
It all starts with the quarterly planning. Everything that’s discussed and agreed upon during this planning session goes to the Product Backlog.
At the start of the Quarter, we have our first Sprint Planning call where we discuss what we will be working on the next Sprint. During this call, we also discuss what is the definition of done for each task. The definition of done is exactly what it says it is: it is how the Team knows when the task has been completed as outlined by the Product Owner.
Once the Sprint starts, we have our daily huddle every 11 AM Central Time. We go through our roadblocks (if any) and our priority task that we will be working on that day. The Scrum Master goes over the Sprint Board to make sure that things are being worked on and moving from the Sprint Backlog towards Done. The Sprint Board makes everything visual. Just by looking at it, you will see what’s still in the Sprint Backlog, what’s in progress, what needs to be reviewed, and what’s done. This entire process takes anywhere between 5 to 15 minutes.
Our Sprint Board is electronic, but many companies use a whiteboard and post-it notes.
The day before the Sprint ends, we have our backlog grooming call. This is when we talk about what we plan to do the next Sprint. When the Sprint ends, we have our Sprint Review. During the Sprint Review, team members take turns demo-ing what they worked on during the Sprint, and the team discusses any hurdles or accomplishments they encountered. During this process, we discuss issues based on its complexity, hurdles that happened or demo a product to the team. We also go through feedback during the review.
Immediately after the Sprint Review, we have the Sprint Retrospective.
During the retrospective, we talk about:
- What went well
- What could have gone better
- What should we stop doing
- What should we continue doing
- What should we start doing
This is a very important part of Scrum because it allows our team to continuously improve and it also helps identify and resolve conflicts. Our retrospective is heavily influenced by the 5 Dysfunctions of a Team by Patrick Lencioni. It taught us that trust within the team is really important. Knowing that, we are able to share our thoughts during the retrospective (or even outside of it) and it will always be “how can we make it better” instead of “who made it worse”. If you haven’t read the book, we suggest you read it.
After the retrospective (still the same call), we go through Sprint Planning. This is basically a review of the backlog grooming call that we did the day before. But if there are any changes to be made, then we discuss it during this part.
Finally, we go around the (virtual) table for our roundtable of gratitude. Everyone on the team shares who they are grateful for and why. Although not part of Scrum, we included this because it feels great to be able to vocally express your thanks to someone and also to be at the receiving end. It is short, but it has become an extremely important part of Asian Efficiency, culture.
We then start the new Sprint and the interation continues.
To recap, here is AE’s Scrum Cycle:
- Quarterly Planning Session to decide what goes to the Product Backlog
- Sprint Planning to discuss what the team will be working on during the next Sprint
- The two-week Sprint starts
- Daily huddle call to go over the Sprint board
- Backlog Grooming Call a day before the sprint ends, to discuss what will be done the next Sprint
- Sprint ends and we immediately have the following calls:
- Sprint Review
- Sprint Retrospective
- Sprint Planning
- Round Table of Gratitude
- A new Sprint is started
We also talked at length about how AE uses Scrum in our podcast, The Productivity Show. You can listen to it here:
Why Scrum works for AE
Prior to using Scrum, AE experimented with different processes or methodologies and nothing really worked well. Through research, we discovered the Agile Manifesto that led us to the Scrum methodology.
The Agile Manifesto states:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
While Agile refers to methods and practices based on the Agile Manifesto, Scrum is the framework used to implement Agile. Although Scrum was created mainly for software development, because of Agile, we can implement it for other industries. What’s important is that you have a defined goal.
5 Reasons Why AE Uses Scrum
- Highly visible for the company owner to see where things are at
- Unified language for everyone in the company to discuss work related stuff
- Self-organizing team (just because it’s not assigned to you doesn’t mean you can’t work on it)
- Continuous improvement because of the iterations
- Transparency (everyone knows what the status of a project or task is, there’s no red tape)
Want to get started with Scrum but aren’t sure how? Here’s a beginner plan:
- The most important step is to get your team’s buy-in and with that said, you need to explain Scrum to your team. Make sure you focus on what is in it for them and how it will help them.
- Once you get their buy-in, start building your product backlog. Do this step with the Product Owner in case it’s not you. Take stock of all the things you know need to be done and break it down into tasks with a clear Definition of Done for each.
- Decide the length of your Sprint and what will be in your first Sprint Backlog. If you aren’t sure what length to use, try 2 weeks. Remember the people doing the work (the “Team”) are the ones that will decide what will be in the first Sprint backlog.
- Decide on what you will use to track your Sprint (it could be a whiteboard, post-it-notes, or something like Trello)
- Schedule and go through the Scrum events (Sprint Planning, Daily Scrum, Sprint Review, Retrospective). Remember that it may seem clunky at first, but stick with it. The more you do it, the faster everyone will be.
Remember, you don’t have to do it exactly like how AE does it. Make it work for your team by making changes and making improvements. You might not get it right the first time–and that’s okay! Adapt and do something different during the next iteration.