Scrum, agile, sprint, backlog, retrospective... Oh, how we just love these words that make it so much easier for us to deal with complex software projects in an adaptive way! Maybe you thought they were only vague buzzwords? Think again! In this case, it is definitely worth knowing what the buzz is about.
The agile framework scrum is by far the most popular agile development methodology, and it is here to stay so let’s dig deeper into its meaning! To get a good understanding of the concept and how it works in practice, we had a chat with one of our own Scrum Masters (and scrum lovers), Robert Bäckström.
The scrum framework is most often used in software development as well as product development, something we do a lot of – how appropriate! It is a way of working that is all about inspection and adaptation. When working on a project, many important decisions are often made early on – a stage where we have very little knowledge about the final product. Agile processes like scrum aim to balance this and postpone detailed decisions until we have more knowledge to make more informed decisions. Changes are considered not only a natural process of a project, but are also desirable and act as proof of constant learning as well as improvement of the product and its value.
The scrum team is constantly adapting to new knowledge, information and obstacles. To be able to work in this agile way, they plan their work in short timeboxed iterations called sprints, ranging from only a few days to a maximum of four weeks. During each sprint, the scrum team takes a part of the product all the way from start to finish - design, implementation and testing are all done within the sprint.
Compared to the more traditional waterfall framework, where the steps take place one at a time during a longer period, working in cross-functional teams with these short sprint iterations means that the team can, for instance, maintain the code base in a more frequent way. Since the sprint should result in a new working product increment, the code base is frequently tested. When a bug arises (and yes, they always do!) it is much more straightforward to find the root cause since the introduced changes to the code base are limited.
The same inspection and adaptation principles go for the business side of things. In scrum, stakeholders are deeply involved in the process and review the progress in each sprint. This provides valuable feedback to the team who adapt the upcoming sprint work accordingly.
The Scrum Master’s tasks are mainly focused on coaching and facilitating the scrum framework. There are a bunch of activities within each sprint: sprint planning meetings, daily scrums (or stand-ups), sprint retrospectives and sprint reviews. In short, the aim of the retrospectives is for the team to continuously learn from what they have done, and the aim of the review is for the scrum team and stakeholders to discuss the best way forward.
An important aspect of being a Scrum Master is that the they does not manage the scrum team. They are responsible for the general set-up, they make sure that the team is on the right path and they are responsible for teaching and supporting the team when it comes to the scrum framework. But their job is not to decide what is to be done. That task belongs to the whole team, including the customer.
At Meta Bytes, we work closely with our clients and they are closely involved in the sprint planning and sprint reviews. At the end of every sprint, we demo the product for the client and based on the demo and the progress made during the sprint, we set new tasks for the upcoming sprint. Together, we discuss the best way forward and adapt to what we learned during the past sprints.
Robert Bäckström, Scrum Master at Meta Bytes.
The close collaboration with our customers is something that we at Meta Bytes truly believe in and is a way of working that sets us apart. We know that it is highly valued by our clients, and we also know that this is how we will deliver amazing tech with damn good business impact.
Block QuoteBack
