Scrum makes your work more efficient.. and more fun
25 January 2019
Scrum is a term that you hear more and more often. The question is whether it is simply a hype, or whether the method really does have practical benefits. And if so, how can you use Scrum? Yellax has used this method for many years; e.g. during development of Typical Manager and BeeFinity, and also when developing standards for our customers. Scrum is a rugby term. It basically means working as a close-knit team. This is not only more efficient, it is also much more fun.
In the world of technological development (R&D), you often only find out what you want in terms of functionality once the functionality has actually been created. Imagine the following situation: after three months of hard work, you are proud of what you have created. Happy that you have finished on time, you present the functionality. At that crucial moment, you may discover that what you have developed does not correspond to the situation in reality and will not be implemented in practice. Unfortunately, stories like this make the news far too often. Did the developers fail to understand the assignment, or were they misinformed? Was the description of the situation not a true reflection of reality, or did the requirements change? Yellax has adopted a flexible development approach in order to cope with challenges like these. Interim validation and involving people: that is the basis of Scrum.
Scrum in Industrial IT
Scrum has its roots in the software development market. However, the method also offers advantages for many other sectors. Perhaps not always in the exact form prescribed by the Scrum method, as individual elements can also be applied. To make a team more flexible, for example, and use the team members’ skills to cope with changes and uncertainties in a project more effectively. It encourages you to think twice when forming teams. The teams that achieve the most are those where each discipline is represented and the team members truly collaborate with each other in order to complete the project. Less work is thrown over the proverbial fence and there is a much greater level of shared interest for the customer. Holding a Daily Scrum with the team – i.e. reviewing the day together in no more than 15 minutes – improves team spirit and mutual understanding. With Scrum, you jointly prepare the schedule. This not only results in a more reliable assessment of the input effort, it also creates a clearer picture of the tasks. In the paragraphs below, we briefly explain how Scrum works in practice.
How it works
Scrum is a method that was created to provide structure in projects where the requirements, wishes and expectations can (and almost always will) change very quickly. When using Scrum, the work is carried out in small delivery cycles (Sprints). A Sprint generally lasts for two to four weeks and the decision about what will be done in this period is not decided until the first day of the Sprint (Sprint Plan). As a result, amendments and course corrections to the development process can be made every few weeks. Yellax sometimes spreads the work for a major release or a major new functionality over multiple Sprints. In such cases, we divide the work up into small, bite-sized chunks (Backlog items or User stories).
Sprint plan
When preparing the Sprint Plan, the team and the product owner jointly determine which items have the highest priority at that point in time. The team and the product owner discuss what is and is not appropriate for the Sprint. The Sprint is ‘finalised’ at the end of the planning session. This means that no changes are made to the Sprint Backlog as the Sprint progresses. If new discoveries or information lead to a need for additional development, the associated tasks can be included in the next Sprint. This creates structure within the team: the items on the agenda are clearly defined and minor changes that might distract the team’s attention during the Sprint are blocked. This fixed structure makes the team more predictable and allows more accurate assessment of the amount of work required to build a functionality. In addition, up-to-date information on how far the team has progressed in relation to plan and what everybody has done during the past day is available on a daily basis. What are we going to develop the next day, and what problems do we need to solve in order to achieve the overall goal of the Sprint? We call this daily meeting the Daily Scrum and use it as an opportunity to make small course corrections every day in order to deliver all the planned functionalities at the end of the Sprint.
Backlog Refinement
In order to accurately assess how much work is required for something, we organise a Backlog Refinement session (refining and updating the Backlog) during each Sprint. This session is intended to identify which subsequent Sprints will be assigned to the Sprint Backlog. NB: the actual Sprint Backlog is only finally determined during the Sprint planning session. During the Refinement session, the team and the product owner analyse the functionalities that are to be developed. Does everybody understand them clearly? Is any information missing? Can the functionality be broken down into smaller chunks? This is because we know that the smaller the Backlog items are, the greater the accuracy with which they can be assessed. Looking at the different Backlog items as a team also creates greater understanding between different people. Something that one person feels to be simple on the face of it can be seen as quite challenging by somebody else. This discussion makes it possible to describe Backlog items increasingly accurately and create clarity for the team.
One danger of making assessments as a team is that the team members may assign an excessive amount of time (and try to please everybody). This is why you estimate the amount of work as effort rather than an exact number of hours. This estimate, for which there is no unit of measurement, reflects a gut feeling based on experience, complexity and the level of uncertainty. You may find this a bit strange when you start using Scrum, but you will soon discover that estimating in terms of effort works well.
Sprint review
At the end of a Sprint, the developers present what they have developed during the preceding weeks to the persons who are involved in the project. The latter can give feedback during the presentation and also assess whether the functionalities meet the expectations. Feedback is guaranteed. This feedback is often incorporated immediately in the next Sprint.
Sprint retrospective
At the end of each Sprint, the team analyses how the Sprint went. This is perhaps the most important meeting in the Scrum method. The meeting looks at how things went (the process) and not so much at what has been developed. For example, is it possible to describe what needs to be built even more clearly? Is it possible to automate specific steps that recur on a regular basis and can we solve bottlenecks? This helps make each Sprint even more efficient. As a result, continuous improvements are made to the process, the team and the technology used.
Conclusion
An approach based on Scrum with the associated Sprint plan, product Refinement, Sprint review and retrospective makes it possible to:
• respond quickly to market demands;
• closely match the practical situation;
• reduce the amount of unnecessary development;
• quickly respond to changes;
• do things better every time.
The main benefit of using Scrum to develop Yellax software is that we can respond more quickly to market demands and requirements formulated by our users. Furthermore, we are becoming increasingly proficient in estimating the amount of work and there is a greater degree of understanding between the developers and the stakeholders. We also repeatedly ask ourselves: how can we do things better this time, both for customers and for ourselves? This experience has led us to also apply this method generically for standardisation and the implementation of Typical Manager and BeeFinity.