Scrum Is All About Doing Less (a Case Study)
Scrum Is All About Doing Less (a Case Study)
Scrum teaches us to do more by doing less. One dev shares his experiences with Scrum, and how it methods helped his team achieve better results.
Join the DZone community and get the full member experience.Join For Free
Many of Scrum propagators (mainly trainers and consultants who are "selling" Scrum) claim that thanks to them, Scrum Teams became hyper-productive. They claim that teams are able to deliver much more (up to 600%?) functionalities in the same amount of time. Scrum increases a team’s productivity - that can be a nice marketing slogan. But this slogan, even if true (in some cases for sure) is not the greatest benefit of using Scrum.
I would like to share our story, a case study from one of Pragmatic Coders’ projects where we implemented Scrum.
When Everything Needs to Be Done Nothing Will Be Done
Our story starts about a year ago. At that time, one of our teams started working on a complex platform for the tourist industry. When building complex products, usually there is a necessity to meet the needs of a number of stakeholders who have varying interests.
Our client thought that they could reduce the complexity by creating comprehensive documentation for the entire solution. It quickly occurred to them, and to us, that creating that documentation for the complex product is “simply” complex. Instead of decreasing complexity by writing documentation we are increasing it. After few weeks we managed to convince our client to try a different approach. Our method was to focus on one functionality at a time. Something that will be useful as soon as we deliver it, not at the end of the project. Let's build it first.
In a room full of stakeholders it wasn’t easy to decide what’s the most important feature to start with. We found it hard to decide on what should we deliver first. The decision needed to be made as soon as possible, so we selected a decision maker - the Product Owner. In Scrum, the Product Owner sorts interests of stakeholders and decides how the product will be developed. She/He is doing it by creating the Product Backlog - an ordered list of Product Backlog Items (product features that should be implemented).
In the world without Scrum, people tend to work on many different features at a time. Integration of such features can be a nightmare and this approach needs a lot of synchronization, usually provided by managers. That consumes energy, money, and most importantly - time. And well, it usually does not work. When people are working on various things at a time we lose transparency and predictability. It is hard to deliver a stable, working version of the system until "the end" of the project. Testing and inspecting the product as soon as possible is the crucial part of delivering the final version. Even if the product is in it’s most basic form, users will give the valuable feedback that needs to be used in creating the version that will be ready for a larger audience.
Scum Is All About Removing Complexity
In Scrum, we work in short iterations with a set duration, called Sprints. At the beginning of each Sprint, we are setting a goal - the Sprint Goal. We define the main problem or group of problems we want to solve in the next two weeks. In our case, a good example of the Sprint Goal could be: "Provide the ability to settle agents who are selling our products." As you can see, it’s not describing the functionality itself, and also it’s not about how we should settle the agents. We discuss these details during the Backlog Refinement process and at the Sprint Planning meetings. We are always trying to find a solution that meets the goal, fits into other constraints we have and is possible to deliver in a short iteration. This (especially the last part) often requires compromises.
Thanks to focusing on small goals, and realizing them step by step, we are able to deliver the next, working, stable version of the system very often. Then users and stakeholders can inspect it, so we are sure that this is exactly what they wanted. If the functionality does not fully solve the users' problem, we are already planning the next iteration where we improve our solution. But usually thanks to that approach we are able to deliver a minimum functionality that solves each problem and it is enough.
When the Deadline Knocks at Your Door, Who You Gonna Call? A Scrum Master
The challenge in our case was that we had the deadline. The tourist season starts in March. We needed to have core functionalities before the start of the season, so our client's company could use the system from the very beginning of the season. Otherwise, migration of the data from other systems to ours in the middle of the season would be counterproductive and extremely costly. Missing the deadline was not an option - without a new system, our client would lose market shares and delivering it in the next season would not make any sense.
Our team needed help, this is why we assigned a Scrum Master to the team. A Scrum Master focuses on the process, not on the product. They are responsible for helping the team to focus on what is the most important and improve the processes they use. When the team is focused on the product it’s usually hard to notice problems with the process they use at work. And there are always opportunities for improvements.
Thanks to the Scrum Master, we were able to focus on the main problems first and limit the number of implemented functionalities that were not critical. But without a Scrum Master, it was easy to lose focus and forget about the deadline. With the tight schedule and a lot of functionalities to be delivered, we couldn’t allow ourselves to waste time on things that were not the most important. A Scrum Master is not a traditional manager who is telling people what to do. They, rather, repeatedly ask questions about what is most important at the moment. They also constantly remind us of the answers we've previously given to that question and help us work on what matters the most. Scrum Master also teaches the team on how to use Scrum properly. His/Her role is also about helping the Product Owner with good backlog ordering.
Scrum Is All About Doing Less
As I wrote before, we had to make a lot of compromises since we knew the team capacity for each iteration but the stakeholders wanted more functionalities than we had been able to deliver. During every Sprint Planning session, we had to reject some requirements that were the least important at that moment, each time we promising ourselves that we would deliver it in the next iteration.
After 4 months of using Scrum, our Product Owner came to me and said: "This Scrum is awesome. I’ve just removed about 60% of product backlog items from the bottom of our backlog. We have been pushing those items down at the product backlog every time when we were not able to take more to our Sprint. After few weeks it occurs to me that we didn't need most of them, or we unintentionally solved those problems via other functionalities we have implemented."
I think that those few sentences above are the best description of Scrum and the greatest benefits it provides for teams and stakeholders. This is why Scrum is the method we use in most of our projects.
Published at DZone with permission of Wiktor Żołnowski . See the original article here.
Opinions expressed by DZone contributors are their own.