The Scrum You Don't Know

But we don’t have a Product Owner! The Product Owner is unavailable! We are working on several projects at the same time! Our deadlines are getting delayed. Testers do not have time to test our code.

And what does Scrum have to say about this? Nothing! No matter how much you strain, struggle, or complain, nothing! Orthodox Scrum proponents will say this is not compliant with Scrum. They will argue that if you have problems, it’s because Scrum has not been fully implemented.

However, implementing Scrum practices is difficult, as you can read in Michał’s article. But are orthodox Scrum proponents right? Does the mere fact that not everything was implemented according to the Scrum rules mean it will fail? I want to dispute this notion.

A long time ago, when I was learning Test-Driven Development, I heard a saying (still promoted by Uncle Bob): “You must not write a single line of code for which there is no test.” Is it true? No! Of course, it is permissible. Of course, it’s possible, and any seasoned TDD practitioner will tell you. However, to do it sensibly, it requires a lot of experience and intuition.

Similarly, with Scrum, you may not get the “Scrum Certified” stamp, but you can do it just as well.

The main problem is that in most cases, when using one approach or another, we focus on the principles, on the letter of the law, rather than the spirit… And then we have two options: either to fully comply with the letter or to start breaking it, justifying our mistakes.

Orthodox Scrum proponents (those who issue certifications) will always tell you that you must act according to the letter. Because only then can they guarantee that it will work. If you make your own modifications, you lose the guarantee.

What Can Stand in Our Way?

So, we have the green light for modifications, but I would like to warn you. Modifications are a big responsibility, where our greatest enemy stands in our way, which is ourselves. More precisely, it’s about the mechanism of rationalization.

I occasionally conduct training and often encounter this mechanism. It appears, among other situations, when we talk about a solution, tool, or approach that requires considerable effort to implement. Participants often seek justifications and reasons why they cannot do it, why it’s not feasible. Most often, it means:

• it simply takes a lot of time before it starts working,
• it’s difficult to execute (negotiations with many people are needed, there’s a risk of backlash),
• we tried once before, and it didn’t work, probably because we didn’t know how to do it.

Therefore, if you want to remove or change something in Scrum (e.g., persuade your Product Owner (client/business person) to be more available because they are overseas and don’t have much time), be brutally honest with yourself and have a conversation with yourself (don’t do it too loudly, as your colleagues might look at you strangely ;-)):

• could it be that I simply lack the courage to do it?
• might I have to be assertive with my boss, and I don’t know how he’ll react, or am I afraid he’ll react badly?
• am I afraid of backlash if I propose a different solution?
• the person always yells, so he’ll probably yell this time!
• what if he fires me?

Unfortunately (or fortunately), in 90% of cases, the real reason why it’s not feasible lies right here, so consider whether you’re applying a band-aid (in the form of process changes in Scrum), instead of undertaking treatment.

What Is Needed?

However, let’s assume you are convinced and objectively sure that something needs to change in the rules. The key is to understand what the spirit that stands behind the rules written in the Scrum Guide is (or any other approach like TDD, BDD, DDD, Kanban, etc.). And this is not easy because it is not always explicitly articulated by the method’s creators. Often, even the creators themselves don’t fully understand why it’s needed, even though they’re intuitively convinced it must be so. And then the community tries to make sense of it over many years.

Therefore, I would like to briefly look at these Scrum principles. This topic will be spread over several posts. Today, we’ll start with the Product Owner.

Product Owner

This is probably the most critical part of implementing Scrum. It is very rarely possible to meet the expectations set by the method. Scrum speaks of a role linked to business. Someone who is responsible for the project from a business/client perspective and makes decisions from that viewpoint. For me, the main message of this role is:

IN EVERY PROGRAMMING PROJECT, IF IT IS TO HAVE A CHANCE OF SUCCESS, THE RELATIONSHIP WITH BUSINESS MUST BE WELL-ESTABLISHED.

What does this specifically mean:

• there’s one point regarding business decisions - there is one person (or entity) who makes decisions about the future of the project and requirements. A common practical problem is that requirements come from many sources (e.g., different departments in a company, different individuals), and the team has to deal with it. This is not good. The team does not usually have the appropriate business perspective to make such decisions. But it can suggest, recommend, or encourage, and that is fine.

• business is available on specific terms - the ideal of Agile is known as customer on-site, who works directly with the team, which is rarely feasible (though it’s worth fighting for it to the end). It’s important to establish specific cooperation rules upfront. These rules should cover topics like:

  • when the team can communicate with the decision-maker,
  • with what matters,
  • what level of engagement from this person the team needs,
  • how disputes will be resolved,
  • how problems will be addressed
  • how we will consider changes
  • how we exchange feedback (here, Scrum offers templates in the form of Scrum meetings, Sprint Review, and Sprint Retrospective).

The key is to define why these rules are important to both sides.

Therefore, whether we have someone called a Product Owner or not does not matter. If we can establish the right relationships with business, we are in a safe zone. If not, no method will help us.

That’s a start. More in the following posts.

(Text translated and moved from original old blog automatically by AI. May contain inaccuracies.)