Press "Enter" to skip to content

Whose fault is it?

Whose fault is it?

A story about how blame accounting can be a powerful force into building the proper “Feature Team” mindset

Let’s say a critical bug is found.

Photo by Alexey Soucho on Unsplash

Needless to say, the defect is very quickly investigated and fixed.

Photo by Alexey Soucho on Unsplash

We’re glad that we could fix it so quickly — however everybody is well aware that not pushing the bug in production would have been better.

Hence, quite naturally, a post mortem meeting is organised to ensure continuous improvement gets in motion.

Photo by Alexey Soucho on Unsplash

The question arises: who should be invited to the meeting?

Feature Teams: a matrix organization

Before answering, let’s put some context. Let’s say we are in a big company in the middle of a transition from a Component Team model to a Feature Team model.

Photo by Alexey Soucho on Unsplash

Everyone in this setting is simultaneously included in two different teams at the same time:

  • What I’d like to say the product team, which is cross-functional and expected to handle topics from inception to delivery and follow-up
  • And one of the communities of practice, which gathers all the experts in a single given matter, like for instance software development on the back-end side of the product

Who should be invited to the post mortem meeting?

Let’s say the bug is basically a typo that the code review process did not catch. Let’s also say that such code reviews are done by peers from their community of practices.

According to you, who should be invited to the post mortem meeting? The product team or the community of practice? Which one is considered accountable for the bug and wasted energy?

Photo by Alexey Soucho on Unsplash

Holding the community of practice accountable

To many, it seems obvious that it should be about the community of practice…

The failure is clearly on the community of practice side. The developer was sloppy, and the reviewer of the code was even more sloppy.

Let’s run a community of practice post mortem.

Holding the product team accountable

I’d like to go the other way. To me, it seems obvious that this is above all about the product team…

The developer is part of the product team. The same product team (the same developer, actually) handled the fix. There is no debate on which team handled the bug: the bug is part of the team’s product backlog — even if the bug was not planned ahead. The team’s velocity will drop. The team won’t be able to deliver something else because of this unexpected extra work.

Let’s run a product team post mortem.

Small difference, big impacts

Photo by Alexey Soucho on Unsplash

You may think that choosing one or the other doesn’t change a thing.

I strongly disagree. They send very different messages.

What might come up from the post mortem meeting?

As an example, let’s consider what kind of thoughts the post mortem will bring depending on whether we focus on community of practice or on product team.

Thoughts raised when focusing on community of practice:

– Why didn’t the Tech Lead review all of the merge requests? (looking for more control)

– Can we add some tool that will perform static analysis and detect this kind of issue? (tools are often seen as silver bullets)

Now, please consider the kind of thoughts that the post mortem will bring when focused on the product team:

Thoughts raised when focusing on product team:

– Why has the code review been rushed? Is it because it has been done by someone else in the same community of practice but on another product team? (looking for more autonomy)

– Why has nobody in the team tested the work before pushing to production? (whole-team responsibility)

Creating the cross-functional, autonomous, self-organizing team

The thoughts raised when focusing on the product team clearly go in a better direction:

Photo by Alexey Soucho on Unsplash
  • Team identifying bottlenecks that impede autonomy
  • Team looking to be more demanding of its team members
  • Team focusing on work to finish instead of following a strict task assignment to specific team members depending on their expertise

Something as small as choosing the attendees of a meeting can go a long way and help create a team dynamic.

Sending the right message

Photo by Alexey Soucho on Unsplash

Given the company is in the middle of a transition, choosing the right messages to send is very important: it will directly help forging the proper mindset in the teams. That goes for meeting attendees, but also for wordings, for choosing who to speak to when requesting an information, and so on…

Liked this article? Show it!

Please clap 👏 and share the article! It is because of you that I put my heart and soul into writing.

And follow me on my blog to be notified when I publish new articles!

Thank you so much!