How does Scrum look from the inside?

Our relationship with Scrum has been going on since 2017. We've been testing each other on joint technology missions. We got to know each other better every year. We had ups and downs, and in times of crisis, we sometimes looked at different methodologies. Once with jealousy, sometimes with a little melancholy...

And although the journey hasn't always been a bed of roses, we never hesitated if Scrum was the right way.

Today, a few words about what Scrum is for Order Group and how we implement it in our daily work.

The OG way

If you work with Scrum, you must choose whether you want to use it fully or take advantage only of its individual tools. Many companies declare that they work in Scrum, but in their own way; they draw particular rules and adjust them to their own working environment.

I don't judge this approach and understand teams that aren't willing or able to work 100% agile. However, this is not the OG way. We believe that only implementing Scrum entirely allows you to get all the Scrum benefits: create the world's best software and become better people, employees, and teams.

At Order Group, we build a work culture that allows us to use Scrum with all its principles. However, this is not an easy and short process. The most difficult Scrum principle to implement is the self-organization of the product team.

In Scrum, the team takes ownership of making critical business and technology decisions. It isn't easy because the team has to cope with the responsibility. At the same time, decision-makers outside the project, such as analysts, senior developers, or C-levels, may be afraid to give up the ownership and pass it over to the product team.

However, we believe that working and improving on this Scrum principle is worthwhile because the ownership of individual team members makes them feel decisive and effective. The project becomes their child, for which they take responsibility, for better and worse.

Only with this approach can great things be created. :)

Dear Product Owner, you are one of us!

The Scrum team includes not only the development team but also the client. Thanks to this, the client, equally with us, feels responsible for the project.

We have proven many times that if the client is close to the project and understands the Scrum process, the project's success is spectacular. This is because both sides of the equation are equally involved and jointly responsible for the result. We're a team with a common goal.

On the other hand, projects where the customer locks himself away from the product team cause a discrepancy between the final product and the business expectations. The development team works on the guidelines set behind closed doors, and the client doesn't correct the course regularly.

This way, it's easy to misalign because everyone imagines the interface in their own way. Documentation is a theory that you want to confront with practice and verify the compliance on the developer-client line as soon as possible.

That is why we include the client in each project; we create a need for them to be actively involved. Again, only this way do you create outstanding software.

Scrum = Planning

Working on large IT projects has taught us that planning is everything and that you have to plan on many levels. For example, when the project lasts several months and involves many teams, you need to set a long-term roadmap and minor milestones.

Scrum equips us with a set of planning tools: big room planning, sprint planning, or backlog grooming. We plan from top to bottom, first at the level of the entire organization.

We are going public in 4 years.

The application is to be ready in the fourth quarter of two years.

In three quarters, there is a conference where we want to show the MVP.

Next quarter we want to see the first render...

We also plan at the level of individual departments. For example, depending on the project's size, we may create a separate roadmap for the business team, development team, hardware team, product team, and administration.

As with the previous (and following) arguments, planning is a process, and we are constantly learning it. See how we managed to plan a big technological project in the renewable energy industry.

Designers side by side with business and programmers

Obedient to Scrum, we also include graphic designers in cooperation with developers. During Live Design Sessions, we design business guidelines in real-time and then program them.

Thanks to this, we make quick product decisions, and the feedback loop is short. We evaluate the actual work that is the fruit of the collaboration of all teams. We're drifting the momentum wave.

The opposite of this approach is the separation of graphic designers from the client and programmers. Designers collect guidelines during workshops and then start designing the product behind closed doors. Then, after 2 or 3 weeks, they present their vision of the product to the client.

The risk is that each graphic designer will understand the theoretical guidelines differently. If the product owner doesn't verify in real-time whether the design direction is correct, and developers can't assess whether something can be programmed or not, then after 3 weeks, it may turn out that the work has to be done anew.

That is why we consult the design on an ongoing basis and arrange the work so that the design is 1-2 sprints ahead before development, thanks to which we analyze changes as they happen.

Developers, product owners, and graphic designers unite! :)

Don't you know who you are? Scrum will give you the answer

As work in Scrum happens on an ongoing basis, it's inevitable to collect and receive feedback constantly. You're out if you can't accept criticism and don't want to improve your work.

During the project, we collect information about what is not working and how to improve it. We also account for it regularly: we write down a list of things we failed at each retro meeting. Then, we identify ways to fix them. Finally, we prioritize improvements and check whether they have been successful every week or two.

Feedback applies to both individual team members and the entire team.

In addition to the ongoing feedback loops, we evaluate projects in their entirety at the end. During the project post-mortem, we assess the project, and, just like in retro meetings, we reflect on what we did right and what was wrong, and how we can avoid mistakes in the future.

All this is to improve our processes and skills. To show each other where we have gaps, what works and what doesn't.

Scrum forces the team to improve itself. Those who don't want to develop and find it hard to receive criticism are not suitable for working in Scrum. To catch up with Agile methods, you need to be able to cope with the pace of change.

Scrum is a process that visually shows who is a leader in the team, who is a craftsman and whether they fit the company's culture or not. It's a mirror where we can view ourselves daily and look at our work without a filter.

But is everyone ready for such dynamics? Definitely not.

Luckily, we are not everyone. :)