Press "Enter" to skip to content

How to subtly fail at implementing Scrum

Thanks to the Scrum Life community for making me think!

One of the great things about Scrum Life is that it is more and more becoming a community: a place where people share their thoughts and experiences.

For instance, some comments make me realize that I can be biased in these videos: what I describe but also what I advise in these videos is not completely neutral.

And that’s normal — we could even say that it is to be expected: as a French consultant, working in French companies, doing French videos, it only makes sense that my own experiences and advices are tainted by, well, French culture and way of doing.

The case: comments about the Product Owner role…

Scrum Life #11 is about whether testing should be handled by the development team or the Product Owner.

Sometimes, I am actively fighting against these situations that I routinely encounter, such as in Scrum Life #11 where I explain why the boring work of checking all acceptance criteria should not be part of the Product Owner’s job.

Scrum Life #17 address the — all too common — case where the stakeholders are not attending the Sprint Reviews.

Other times, I simply take for granted ways of working that the whole French market practice as the obvious and only way. This was the case in Scrum Life #17 where I explain why it’s a problem when stakeholders don’t attend Sprint Reviews.

And then that’s when comments reminded me that I was biased.

It was pointed out that I made assumptions about the Product Owner which may not be consistent with the Scrum Guide.

Original comment thread, in French.

(all following quotes are my home-made English translation — all loss of meaning are on me!)

It starts with a gentle reminder that what I describe in the video — stakeholders not attending the Sprint Reviews — might not be that of a big deal: it all depends on the role of the Product Owner.

Kibo Nakamura: Hi! I don’t agree in full. In my view you are under-estimating the role of the Product Owner (PO). It’s up to him to provide continuous feedback both from stakeholders and from the market. By the way, I remind you that the PO might not be part of the development team. Actually, the PO is not required to be present during the Sprint. So, when stakeholders don’t attend the Sprint Reviews it is up to the PO to provide the useful feedback. Lastly, according to the Scrum Guide, it is the PO who makes the decision to launch on the market or not.

At first, I tend to dismiss this comment, not (yet) really questioning my own train of thought. You know how it’s not always easy to receive feedback! 😖

JP Lambert: Thanks for putting this video in perspective. Different kind of projects call for different ways of working!

Luckily, my discussion partner doesn’t feel that this hand-waving answer is enough. He keeps digging:

Kibo Nakamura: That’s true but, a priori, the Scrum Guide remains valid in all situations. Furthermore, even if I understand that you are more a Scrum Master, this video could misguide those trying to pass the PSPO certification from

Otherwise, I’m really happy to see French VLOG about Scrum. Congratulations!

Signed: a certified PO 😉

That’s some interesting points. Even if I usually bash Scrum certifications, yet it’s not a reason to misguide those trying to pass it.

At this point, I’m not yet fully acknowledging my own biases about the Product Owner role. I’m simply grateful to have this comment that might prevent some people from failing their PSPO certification because of my video:

JP Lambert: Thanks for making this clear!

And then, I started really thinking about it. Yes, indeed, that makes sense! Yes, that explains most of the issues I see in France about Scrum. Yes, I was biased.

JP Lambert: Thanks again for your comments… They make me think. Indeed the point of view you describe is in full accord with the Scrum Guide: the PO doesn’t attend the DSM, in an ideal world the PO is provided by the customer rather than being a middleman with the customer (in which case the role would be better described as Proxy-PO — which is an anti-pattern), and so on.

This matches the thoughts that I previously presented in this post:

Basically, depending on the kind of project and people, the PO role will be more like an Agile project manager (which lines up pretty well with this video: what’s the point in running a Sprint Review with no stakeholders) or like a Product Manager (which matches your comments).

It makes me wonder if I am not taking shortcuts based on my experience: a clearly French-tainted one by project managers and by business and tech fighting each other. The situations that I depict in this video seems to be natural for companies that fit this experience (and that may well be failed implementations of Scrum).

In the end, moving away from the Scrum Guide, for instance by including the Product Owner into the DSM, can be a good way forward but is also a slippery slope. Many Agile coaches agree to say that this is a good thing, as it makes collaboration easier. Yet be careful that this is not hiding artefacts from the old way of doing…

Well, all these thoughts are quite rough. Thanks again for challenging what I’m saying! Please continue 👍

And here we are. Could we elaborate on these raw thoughts?

Who handles the project management stuff?

Let me take an aggressive stance towards what I see in these companies.

Let us imagine a company where Product Owners handle all the project management stuff. What’s interesting in this company is that Development Teams struggle to self-organize. Is that really surprising? Is self-organization needed at all in this case?

Let’s follow the red thread. If the Development Team doesn’t handle project management at all, then what makes the Development Team take on ambitious goals? How can the Development Team successfully serve the business above all while avoiding building any technical debt?

Basically, we’re asking Development Teams to run as fast as they can BUT at the same time to run slow enough so that they can keep running at a sustainable pace.

That’s really hard. I’m not sure the Development Teams can solve this dilemma if they don’t handle project management themselves.

What’s the point in having a Scrum Master?

These same companies often don’t see the value of having a full-time, dedicated Scrum Master in each Scrum Team.

That kind of make sense: do you need a Scrum Master if you don’t have to coach the Development Team about Agile project management? If you don’t have to help the Development Team self-organize?

It simply makes sense. Basically the Scrum Master job boils down to the following stuff:

  • Ensure meetings happen. It’s true that you don’t need a Scrum Master to do that. It’s not strictly a Scrum Master skill!
  • Make sure project management stuff is done, helping and coaching if necessary. But you don’t need that if the Product Owner already handles it all on his own.
  • Help and coach the Development Team to self-organize. But what’s the point? Self-organize what? There already is a project manager in disguise — the PO — who takes care of everything. Why bothering to self-organize? Plus being directed is comfy.
  • Shield the Development Team from the org, if needed. But since the PO is doing the project management stuff, she is front-facing the org every single day. No need to shield the Development Team: the PO is already taking it all and doing a fine job as a shield. (even if the shield might be cracking under the pressure, but honestly who cares!)
  • Drive continuous improvement. Unfortunately, the impact of continuous improvement is quite limited if the Development Team is not self-organizing. It becomes a blame game, and most if not all of their issues will be attributed to external causes which, of course, cannot be affected.
  • Protect the Development Team from itself and help it be rigorous. The Scrum Master will definitely help with that. However forcing process is only the worst way to do it. The better way would be to have the Development Team follow the process because it makes sense to them and because they are convinced they gain value from following it. But how do you get there without a self-organizing team?

Maybe you have a Tech Lead around?

In those French companies, I also see a taste for the Tech Lead role.

I’m not very fond of this role as it introduces some kind of hierarchy inside the Development Team. Plus, the Scrum Guide doesn’t recognize any specific role in the Development Team.

In short, if you have an amazing Tech Lead, she will help the team become amazing — but she would have helped the team anyway if she weren’t Tech Lead. On the other hand, if you have a bad Tech Lead, she will prevent the whole team from working properly — but if she weren’t Tech Lead she might have just fit into the rest of the team instead of impeding the team.

Some would argue that the Tech Lead job is part of the Scrum Master’s — the technical one, of course. Indeed, the last item about rigor fits this view. So, having a Tech Lead is one more reason not to have a Scrum Master! Yeah!

In the end, the Tech Lead is one more way to prevent the Development Team from self-organizing.

Do we have a grudge against self-organization?

So, the question is: self-organization is at the very heart of Scrum, but those organizations are doing everything they can to prevent Development Teams from self-organizing. How come?

I don’t have the answer. What’s sure is that those companies haven’t changed their mindset. They might very well have adopted the Agile practices, but their mindset is still in the old ways…

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *