Scrum is done in sprints, and iterations are welcomed throughout the project’s life cycle. It is created to help organizations deal with complex projects one step at a time. It is about having tangible results after each sprint that can be shown to stakeholders. That way, if iterations are needed, they can be done while the project is still in the early stages.
So what are sprints?
You can think of sprints as little pieces of projects done in a set amount of time. They are created to make each project more manageable and more flexible to possible changes. Their duration is fixed to make the work consistent. Each sprint has a set goal, and during the sprint, changes are not made to make sure the goal is being achieved. To achieve the goal, each sprint includes:
This is a crucial part of starting each sprint. Here they answer the questions of what will be done in this sprint and how the job will get done. They discuss Product Backlog items that will help with achieving the goal they set for this sprint.
Daily Standups are a 15-minute event Developers have at the start of every day while working on the project. They decide how to structure Daily Standups, but they always have to have the Sprint Goal in their mind. They use it to plan what tasks need to be done during the day. They also have meetings during the day if anything needs to be discussed.
Sprint Reviews are created to take a look at everything that was done in the now completed sprint, and to decide what future adaptations should be. In this event, stakeholders are presented with the current results, and then it is discussed if anything needs changes so that those changes can be put into the account for Sprint Backlog in the next Sprint.
In the Sprint Retrospective, the team inspects how the last Sprint went. The goal is to increase productivity and quality. Here they discuss everything that needs improvement, such as communication, used tools and the work of individuals. After this, the team is ready for the next Sprint.
Now that we know what sprints are, let’s jump into the roles of the Scrum team which are Product Owner, Scrum Master and Development.
When we talk about Product Owners, we talk about one person and not a whole board of people. Their job is to define the work and to make sure all the deadlines are met, as well as to prioritize work that needs to be done. They should work closely with the development team members throughout the project and they should have good connections and communication with them as well.
According to the Scrum Guide, they are responsible for:
- Developing and explicitly communicating the Product Goal
They always need to think about the value the project should bring and they need to be able to communicate it.
- Creating and clearly communicating Product Backlog items
They need to be able to prioritize tasks of their team members and make decisions that will help them continuously improve the project they are working on. Make sure that everybody knows what to do at any given time.
- Ordering Product Backlog items
- Ensuring that the Product Backlog is transparent, visible and understood
Everybody on the project needs to be aware of any changes happening at any given time. It is the Product Owner’s job to make the conversation transparent and understood.
Their work is to make sure that work is being done on time, but according to the guide they also need to understand that their job does not include micromanaging the development team.
One of the functions of Scrum Master is to stop Product Owner when they want to manage the development team. Constant micromanaging can make the Development Teamwork inefficiently and create a distraction from the tasks that need to be done.
They work tightly together with the Product Owner and Development Team. Helping to communicate the value of the project better, and to manage the backlog together with the Product Owner. They make sure to help the team with any problem they might have. For example, if their laptops are not working, Scrum Master will help them find a replacement.
And when the team has everything they need to do the work, they also need to make sure that the Scrum process is protected and followed. They are the ones who know how Scrum works, and they need to make sure that the team is always working within the Scrum framework.
They make sure that the team stays productive and that no deadlines are missed.
In a software development project, Developers are usually a group of five to nine professionals consisting of developers, architects, testers and designers. Their job is to make sure everything they define in each sprint is done correctly and on time. They work together and decide how a task, that was prioritized by the Product Owner, can be accomplished. Scrum Master supports them and helps them stay in the Scrum process, but other than that, they should be self-organized and decide what task from the prioritized product backlog should each member of the team take and complete.
For the success of projects using the Scrum framework, all of these roles need to cooperate together. Transparency and good communication are the keys to creating an environment for better collaboration that will eventually lead to the project being done more efficiently and successfully following the vision all through the end. It is important to realize what is lacking after each sprint during the Sprint Retrospective and try and make it better for the next set of sprints.
Scrum in Bornfight
Now that we know what Scrum is and what it should look like, it is time to talk about how we, as a company, implemented it. But before we start, we have to consider every framework and methodology as a blueprint. It doesn’t mean you have to blindly follow the rules – those are simply guidelines that might not completely work for your business model, and to make it apply to our model, we needed to make some changes.
In order to better explain how we implement Scrum, I sat down with Mirna, our Senior Product Manager, and Mia, our Project Manager, for a quick interview, and you can read the information they shared in the rest of this blog post.
Why did we start using Scrum?
As a company that works with the start-up world as well as the big companies, it was very early clear that using the Waterfall methodology is inefficient as it is hard to define the full scope of a project and all the requirements in advance. The practice has also shown that, by not being flexible, the budget and focus can go through the roof. That is why using Scrum was a logical next step. By implementing Scrum in execution of all our projects, we were able to become more flexible while still having the possibility to show our clients one linear, Waterfall-looking, project timeline.
We see Scrum as a methodology as it lets us do smaller chunks of work in a defined period – Sprint. And as such, we always adjust everything we do to the needs of our clients.
Project Manager role
In our Scrum implementation, we have the role of a Project Manager, which is not a typical Scrum role, but it fits into our business model. Project Manager is a role that combines Product Owner and Scrum Master. That is probably the biggest difference between following Scrum by the book and the way we implement it. And we did that precisely because of the approach of working directly with the client and adapting to our client’s way of working. Project Manager is more of a Waterfall role, but we use it because it is more tailored to the way our clients experience the process, regardless of our internal way of working. Of course, we are aware that one person can’t be responsible for a large-scale project, and that is why the responsibility will be shared within the team when it is needed.
Using Scrum is extremely beneficial for the development team because of the seamless knowledge transfer. There is no better way for a Junior to advance faster than by working together with Seniors on completing their common goal. By actively participating in Daily Standups, Sprint Plannings, and Retrospectives, Juniors get exposed to details and knowledge they wouldn’t be if the situation were different.
Managing the Development Team
When it comes to managing the development team, Mia and Mirna have different strategies. However, it is important to know that there is no good or bad approach as everything always depends on the project itself, the team, and senioritis in the team. So for example, if the project is straightforward, and if we need to produce an MVP (Minimum Viable Product), it is important to spend more time managing the team. The reason for this is because the team would otherwise create the best thing they could, which is ideal when we talk about the finished product, but not when all we need to produce is an MVP.
But, if the solution to the project is not completely clear, meaning we are still brainstorming and trying to figure out the ideal solution, it is always best to try and leave more freedom to the development team as they will come up with a more creative approach. And the Project Manager’s job here is to keep everybody and everything within the timeline and the budget.
The other approach would be to let the teams have more responsibilities. To be able to do that right, before each project, the Project Manager needs to completely analyze the project, arrange with the client all possible requirements, make a deal for a minimal viable set and then transfer tasks to the team.
However, to have self-organized teams, people in it need to be mature. It is always easier to work with a team full of Seniors who know how Scrum works, and who know exactly what needs to be done. But usually, that is not the case. The probability is that you will have at least one Junior in the team who is still learning. You will help that Junior the most by managing them, but also by letting them make some mistakes along the way – which will help them learn faster. It is always important to remember that everybody can contribute ideas to the project, but the Project Manager always needs to have the last word as they are the ones in constant communication with the client, and they are the ones who need to worry about everything being done within the deadline and the budget.
When it comes to working on a project, the most important thing is the trust and honesty of the whole team. If something was done wrong, it is important to own up, and the team, together with the Project Manager, will find the solution for it. After all, any methodology, no matter how implemented, won’t give successful results if there is no trust and honesty.
Scrum is transparent, and transparency is what our company is known for, so this is an ideal framework for us. However, every project is different, and every project has different demands, so we have to be flexible even when choosing the framework for each project. With that being said, we do mostly use Scrum as our preferred framework, and even our Project Management team in the Product Unit has adapted their work to it. If you are interested in learning more about it, you can read about it here!
We like to keep communication with clients throughout the project and hear their feedback and improvements they would like to see before the project is over. Clients always need to be up-to-date with all the iterations which wouldn’t be possible if we were, for example, using Waterfall where they would see the finished product at the end of the project.