Scrum may sound like a sports tactic, but it’s a methodology we use at Rewind on a daily basis to develop our work and to achieve our goals.
Scrum is simply a methodology or guide to developing software. Software development methodologies can be described as a combination of processes (or as a framework) that the organization agrees to follow in order to accomplish a certain goal. There are many types, and selecting the right methodology for your organization depends on several factors, including your team size and your organization’s goals.
Well, your organization made the decision to implement Scrum, now what? Well, the first thing is: don’t panic! If you were using Waterfall, Extreme Programming, Feature-Driven Development, Shape-Up, or nothing at all and need to migrate to Scrum development methodology, then stick around for some helpful tips and tricks we discovered while going through this process. Hopefully, learning from our experience will help prepare you and your team for a smooth transition.
Agile vs. Scrum: what’s the difference?
Well, is there a difference between Agile and Scrum? Sometimes, Agile and Scrum are discussed as two different things, and sometimes they can refer to the same thing. While the terms are often confused, they both rely on an iterative process.
The key difference between them is that Agile is a philosophy that utilizes a core set of values and principles, and Scrum is a specific type of Agile methodology that is used to facilitate a project. Sort of how all squares are rectangles but not all rectangles are squares, Agile methodology isn’t always Scrum, but Scrum always uses Agile methods.
Why implement Scrum?
Well, as mentioned before, the methodology choice depends on several things, including your product, team size, and other factors.
Scrum methodology can be applied in almost all types of projects, specifically where the requirements are highly emerging and rapid changes are needed. With Scrum, work is done simultaneously by the development team, rather than sequentially. Also, adaptability is the key for Scrum teams, so that changes can be supported and integrated into a project currently in progress.
The key benefits of scrum include:
- Quicker release of usable product
- Greater ability to incorporate changes
- Adaptable to changing requirements and/or market demands
- Better user satisfaction (since features are released faster)
- Decision making is in the hands of the teams, increasing developer autonomy
- Better visibility of progress on project development
Scrum implementation, step by step
As a certified Scrum Master, I can say implementing Scrum is not always easy, however, there are some techniques that can be applied to make that process smoother. Some of those techniques we learn in theory, but the majority of them (which are the ones we will talk about in this article) we learn with experience. Learning to implement Scrum without actually practicing it is sort of like trying to learn to swim online: you’ve simply got to get your feet wet to truly understand the Scrum process. So, let’s dive in!
Step 1: Communicate
The first tip sounds rather obvious, however it’s essential to ensure everyone is on board with the change! Does everyone involved in this change understand why the company is implementing Scrum? Maybe, maybe not!
Some people in an organization may not fully understand the need to change, some are used to the ‘old way’, some really like their comfort zone, some don’t think there is a need for a process at all. It’s common to have someone doubting the change, or questioning the reason why. It’s very important that everyone involved understands exactly why and how this transition will benefit the team.
Take as much time as you need to talk to everyone, explaining the pros and cons and the reason why the team needs Scrum. If you come to the conclusion to implement Scrum, there’s likely a reason why. Perhaps the current process is not working as intended, or the team is growing and requires a formalized process in place. Lean into these frustrations, and explain how Scrum will help alleviate day-to-day issues your team may be facing.
Team meetings are ideal to introduce the change, but if you notice that a specific team member is having problems understanding the change, talk to this member in private and first listen to what he/she has to say. Addressing concerns head-on with empathy and honesty lets your team members be heard while also giving the Scrum Master more insight into what your team needs from their software development process.
Step 2: Train
Second: training! Make sure everyone goes through training to expand their knowledge on what to expect when working with Scrum. You may have people on your team that worked with Scrum in past experiences, but may also have someone that is clueless about the process. Having all of them (even the ones with experience) going through the same training will level the playing field and make sure everyone knows what to expect.
Set 3: Adapt
After training, you will get familiarized with the Scrum guide and all the ‘by the book’ implementation, but the beauty of Scrum is adaptability! ‘By the book’ does not always apply to your setup, your product, or your team. So here is the third (and maybe most important) tip for you to apply during your Scrum implementation: don’t be caught up on every single line you read in the guide. The guide is exactly what it says: a guide! You can adapt as much as you want and need to fit your team, culture, and product. Scrum is a framework, not a cake recipe to follow where if you add less of an ingredient, it won’t turn out as good.
Essential Scrum ceremonies
Scrum methodology recommends various meetings or check-ins, called ceremonies. Let’s explore some of the most essential scrum ceremonies (and how to adapt them to your team’s needs).
Stand-Ups
Stand-ups (or Daily Scrum) is an essential practice when implementing Scrum. It’s a daily meeting that allows team members to sync on what they’re building, what isn’t working, and what they need help with. Yet, like all Scrum ceremonies, it has been adapted!
In the past, Scrum best practices would suggest a few questions to keep this quick meeting sharp: What did I do yesterday? What do I plan to do today? Any impediments? But this has changed! Thanks to the amazing adaptability in Scrum, they noticed this became a ‘status’ meeting, which was missing the point. So, the 2021 Scrum guide updated this process. Stand-ups in reality are not for status updates, and also not for management! Daily Scrum meetings are held for the development team only, in order to unblock each other, check dependencies, promote quick decision-making, and consequently eliminate the need for other meetings.
Retrospective
Another key ceremony that makes you adapt Scrum to what you need is Retrospective. As a matter of fact, I believe this is the most important ceremony Scrum has. This meeting is to summarize the past sprint and identify where there is a need for improvement.
It should be a time when everyone feels safe to speak up, to say what bothered them, what they liked and want to keep doing and offer suggestions on how to improve things for the future. I have seen meetings where nobody speaks their mind, I’ve seen some where everyone wants to speak on top of each other and it might become heated, but there are some techniques to help you make this meeting more productive and effective. Many people asked me about this process, so I decided to explain in detail how Rewind development teams handle this ceremony.
Our team is currently using an online tool to help with the Retrospective process. As a remote-friendly company with a distributed workforce, I knew we needed an online tool everyone could access. RetroTool has different templates that can help guide you through the meeting.
Start/Stop/Continue is a common template I’ve used in the past. In this template, Scrum team members list things to start doing, things to stop doing, and things to continue doing.
Currently, we are experimenting with Liked/Learned/Lacked template, where team members are asked to list things they liked, things they learned, and things that were lacking.
Once we start the Retrospective, we take 5 minutes on our own to write down (virtual) post-its notes of things we liked, things we learned, and things we think we lacked during the sprint. After 5 minutes (or when everyone is done), the team publishes their notes so everyone can see them. This process is anonymous, but the author can reveal themselves if they want to. After publishing, we take a few minutes to bundle the repeated notes (if needed) and then we go for a vote. Every member votes for the notes they believe important and the notes with higher votes are discussed further.
After the voting is complete, then we start talking about the popular notes and listening to other people’s opinions about why they believe what they do. There are a number of things that can come up in this discussion: things to change, action items, change of a process, etc. It is up to the team to come to a consensus on what is best for the team to move forward. After this meeting, everything discussed is summarized and documented and will be reviewed at the beginning of the next retrospective, in order to see if the action items were taken care of.
How to estimate
During your transition, you may encounter another uncertainty (trust me, there will be lots) – estimates! This topic might show up on your very first sprint planning meeting, where the team will be discussing the tasks while planning the sprints, and the question will be: how many tasks can we fit into one sprint? Well, that will depend on a lot of factors! Don’t worry, it is very unlikely to get it right on the first sprint, or second… truly, estimating is a guessing game, but it’s a game you and your team will improve at the more you practice.
The teams’ velocity might take some time to be accurate, and even after a while, it could have some variations from one sprint to the next according to how many working days there are, if there is any team member on vacation or away sick, or simply because this sprint contained harder tasks than a previous one. In any case, life happens, so don’t be discouraged if your first few estimates vary.
Story points can help you through the process, but then the next question would be: how do I calculate how many story points to assign to a task? Googling ‘how to estimate a user story’ will return millions of answers, so you may need to play around with different methods until you find the one that clicks best for your team.
At Rewind, we like to use the Fibonacci sequence to guesstimate how long a task will take. The Fibonacci sequence (1, 2, 3, 5, 8, 13, …) is useful for estimating because as the numbers get larger, so too does the difference between them. This reflects how when a task is large, there is often plenty of uncertainty around what is involved. Using the Fibonacci sequence to structure our estimates is useful since forces us to consider the complexity of the task while allowing for the occasionally unknown nature of a task’s components.
It also allows the team to quickly estimate whether a task is a 1 or a 2, or whether it’s an 8 (and needs to be broken down into multiple 1 or 2 card tasks). Note that it’s important to establish that the “points” on a card do not equal the number of days a task might take. For example, in our team, we understand a 2 as a simple task, but not a one-day type of task (the ‘2’ does not mean it will take up to 2 days to be done – if testing is trickier, we often count that towards the estimates as well).
Bias among your team is another obstacle when attempting to estimate stories accurately. Planning poker is a very helpful way to remove bias from the conversation. Essentially, the dynamic of the game doesn’t let the team members see the numbers others have picked until you pick your own, so team members cannot influence each other while estimating a task.
There are several online tools to help set up planning poker with your team. At Rewind, we like to use Scrum Poker Online, as it works well and it’s free. Here’s how it works:
- The team member has a deck of cards (only with the corresponding number, for example, the Fibonacci sequence) to pick.
- After the PM explains the user story and all questions are answered, each team member will pick a card that will be hidden from everyone else.
- Once everyone makes their decision, the cards are flipped and the estimates of each team member are revealed.
If we have a big gap between the choices, we talk about it! The highest defend their point of view, and so do the lowest. Often someone is seeing something that others are not, and this constructive discussion helps the team to figure that out. The team can come to a consensus and the estimate is picked.
This can help establish guideposts for estimating the rest of your tasks as well. A simple comparison of “task 1 will take X points. Is task 2 bigger or smaller than task 1?”. This gives the team an idea of what to follow.
Dealing with hotfixes
During my years of experience with Scrum, another issue the team might encounter is interruptions. Bugs: they happen! Hotfixes? Yes! Does this interfere with the sprints and the team’s velocity? Sadly, yes.
The best way to overcome this problem is to decide what to do with the interruptions in the first place. Ideally, no changes in the sprint should be made once the sprint starts. But the reality is, very few of us are writing code in a perfect world.
Having a conversation with stakeholders and the Product Owner on what to do when the team faces an unexpected obstacle is the best way to ensure everyone is aware of what to expect if the sprint scope is changed. For example, checking the severity of a bug before introducing it to the sprint scope might save a lot of time. If the bug is not urgent or has low severity, it can be on the top of the next sprint backlog. However, if it is a hotfix and needs to be fixed right away, this will affect the team’s velocity and at the end of the sprint, not all the tasks promised might be completed.
Flexibility is key when dealing with unexpected bugs and hotfixes. Sometimes things happen and we are forced to adapt. Luckily, Scrum was designed to be adapted and made your own.
Summarizing Scrum
To summarize, as said before, not everything will be by the book and some unexpected situations might show up from time to time. The key is to adapt as much as possible and always learn for the next iteration. The beginnings will always be challenging – things might not work smoothly right away – but hang in there and you will see the engine aligning sprint after sprint. Once you and your team find their groove, you will have a very comfortable team working together to their full potential.
Interested in adapting with us? All Rewinders receive a professional development stipend of $5000 CAD per year (even non-Scrum Masters). Join our growing team of developers, DevOps, and engineers as we work to back up cloud data everywhere.
