Why Use Scrum? 6 Reasons and Practical Examples

For each Scrum project, we conduct a business workshop with the client. Together, we set the framework for the project, including the key functionalities of the application or website.

However, it often happens that ideas don't correspond to reality. The original assumptions may not be 100% accurate because market trends may have changed since they were established.

Sometimes you have to see a feature to realize that it doesn't make sense. And vice versa, sometimes you need to recognize that a feature is missing to find out it's necessary.

Scrum includes a product demo at the end of every sprint, where the project team shows the current version of the product to the client. Together, we think about what is needed, what is redundant, and what is worth improving.

Thanks to this, the client can influence the course of work on an ongoing basis. We avoid a situation where we code something only because we planned it three months ago. Thanks to Scrum, we code only what the client and his clients really need.

An example from a project:

A client from the food industry hired us to recreate old versions of existing websites and build a custom CMS. After business workshops, we agreed to create all pages from scratch, using content from previous versions.

Thanks to weekly meetings, we learned that some of the old pages contained useless information and outdated sections that we shouldn't include in our scope of work. As a result, we saved time for both the client and ourselves and could think of something new that would be useful for the users.

After business workshops with the client, we create an initial list of functionalities and start coding. Scrum sprints, during which we present the results of our work and discuss the next steps, are held every week or two. You can read more about our process in the article How we do IT.

Sometimes, however, after the first or second sprint, the product turns out to be sufficient. Thanks to quick feedback rounds, some projects planned for several months are handed over much earlier, saving the client's time and money.

An example from a project:

For a client from the energy industry, we designed a new control panel for the company's consultants. For one of the first sprints, we created a basic version just to present the essential functionalities.

It turned out that the demo version was entirely sufficient for the client and his employees, so we stopped further UX work. As a result, the customer used it for business purposes much faster than initially planned.

Having worked for a couple of years in waterfall methodology, we learned that clients stress the most when they don't know what is happening in the project. Is everything going as planned? Is the project going in the right direction? Do I know everything I need to know?

In Scrum, the client is a full-fledged product team member and participates in weekly demos. As a result, he is fully aware of the progress of work and the existing problems or possible threats.

The knowledge exchange between the client and developers is smooth; nothing is left unsaid or unclear.

An example from a project:

Finance industry. To progress on the project, we needed constant access to specific knowledge that only the client had. So we created a dedicated Slack channel, where we exchanged knowledge on an ongoing basis with financial specialists on the client's side.

As a result, the client knew exactly what we were working on and at what pace.

Each person in a Scrum project has to explain their part of the work for a given sprint to the rest of the team. No developer works in isolation, and information on individual tasks spreads within the team and is available to everyone. As mentioned above, the client is part of the product team, too.

Thanks to this, the project is resistant to team members' leave and unforeseen situations, such as absence due to illness. So when your tester is suddenly unavailable, everyone knows what to do in the testing field, and it's easy to continue working without any delays.

An example from a project:

In Scandinavia, July is the month when everyone takes long holidays. It was no different in the case of our client from the renewable energy industry, who went on a whole month of vacation.

Because he participated in demo meetings before his departure, and the entire project team knew what each developer was working on, his month-long absence didn't stop the progress of the project. We even solved a problem that usually lies on the client's side without his participation.

Daily Scrum is a meeting where the whole team talks about yesterday's work and what they will be doing today. Developers have the opportunity to listen to each other and share information with the rest of the team that could impact the day's assignment.

Thanks to this, the team's work is smoother. We avoid downtime caused by missing information. We don't do unnecessary work because we verify the sense of specific actions faster.

Daily Scrum helps to correct the project course at the level of everyday development work.

An example from a project:

When planning sprint activities for a security-related project, one of the developers prepared a list of conditions to meet. However, we discussed them internally and concluded that they would take 2x longer.

We started proposing ways to deliver the project within the set time frame. Together we developed conditions that we managed to meet within the specified time, and we delivered the product at the end of the sprint.

In our opinion, all of the above arguments boil down to the most important one:

Scrum encourages the client and the development team to work closely.

Together we build the product on trust, partnership, and open exchange of information. Because the client is involved in the process, he can correct the course of the project on an ongoing basis. He can give feedback and notice whether he needs certain features and if any are missing.

On the other hand, the development team is also more involved: they code and co-create the product with the client. Team members listen to the client's ideas and give their own suggestions, so they take an active part in the project.

As a result, the product is the result of collaboration and meets the customer's needs as closely as possible.

That is why we decided to work with Agile methods, and we encourage everyone with whom we work to do so.