Scrum is all about doing less (a case study)

Many of Scrum propagators (mainly trainers and consultants who are “selling” Scrum) claim that thanks to 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 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.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
~Antoine de Saint-Exupéry

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 the 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 various interests.
Our client thought that they can reduce the complexity by creating comprehensive documentation for the entire solution. It quickly occurred, 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 was not easy to decide what is 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 stakeholder and decide 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 – the 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 the larger audience.

Scrum 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 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 be able to settle the agents. We discuss this details during Backlog Refinement process and at the Sprint Planning. 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 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 users’ problem we are planning 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 are 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 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 have any sense.

Our team needed help, this is why we assigned a Scrum Master to the team. Scrum Master is focusing on the process, not on the product. Such a person is responsible for helping the team to focus on what is the most important and improve the process 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 we were able to focus on the main problems first and limit the number of implemented functionalities that are 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. He is rather repeatedly asking questions about what is most important at the moment and reminding all the time about the answers that we gave. 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 stakeholders required more functionalities than we had been able to deliver. During every Sprint Planning, we had to reject some requirements that were least important at that moment. Every time we promised ourselves that we will deliver it in next iterations…

After 4 months of using Scrum, our Product Owner came to me and said: “This Scrum is awesome. I have 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 that we didn’t need most of them, or we not intentionally solved those problems by 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.