This article is part of the « No dogma » series. Do not forget to read the other articles on this topic.

Ok…I know what you are thinking, but no! I don’t hate Scrum! The software development world is crowded by people who have had success with Scrum. Scrum solves many problems and reduces many risks that every software project is confronted with. And this is the same for XP or Kanban. I won’t deny it.

In fact there is a concept that I don’t like with methods like Scrum or XP : the ScrumMaster / Coach role.

First of all, I’d like to mention this article : Delete [ScrumMasters], by Tobias Mayer. Not the same discussion as in this post, but still an interesting view on the ScrumMaster role.

Actually I don’t hate ScrumMasters or XP coaches neither. The concept of coach is a good concept. What I dislike is their theoretical limitations due to the definition of their role:

The ScrumMaster is responsible for making sure a Scrum team lives by the values and practices of Scrum.

Learning Scrum – The ScrumMaster

The Scrum Master is by definition the Inquisitor Priest of Scrum. If he does his job well, he will make a team implement Scrum entirely, protect the team against non-Scrum interactions with external people, ban non-Scrum practices and burn sorcerers and witches.

This is not what I think a real coach should do, so let’s define another kind of coach. Maybe a LeanMaster, no an ImprovementSage or just a WiseCoach – you name it.

The WiseCoach – actually I like this one – is not related to any methodology or guru. His goal is not to make sure that the team implements the selected method well but to make sure that they improve themselves and focus on delivering more business value. He will never say “We are doing Scrum : we must blahblah” but “This part of Scrum does not work with the team : why? what could we change to improve it? what is its exact purpose? how could we get to better results with something else?“. He will never say “No Scrumbut here!” but “Let’s implement a kind of Scrum+” He focuses in putting the team on the auto-improvement path, with no dogmatic boundaries

The WiseCoach is change-oolic. Thus he prevents the team from being lazy and makes sure that they always try to improve in a permanent try-learn-improve loop. He helps the team analyze the current process and policies, mitigate risks and change for the better.

Finally the WiseCoach is a wise man, a philosopher. Thus he knows that software projects and teams are complex systems and that there is no such thing as “best practices”, good/bad dualism, true/false statements, magical answers, etc. Instead he believes in balance and small-step continuous improvement. He refuses ready-to-wear solutions. For him there is no absolute truth, there is a moment, a state that we need to improve.

This kind of people already exists of course. Some of them are proud of themselves, but others are hiding themselves in the dark. They are ashamed of their blasphemous behavior, but they should not. You WiseCoaches who read this : show yourselves!

This article is part of the “No dogma” series. Do not forget to read the other articles on this topic.

At pm.stackexchange.com there is a very common kind of question:

What are the best metrics to monitor QA?

I want to monitor the performance of the QA team. I have the following data available : foo, bar and qux. I thought of measuring the foo/bar ratio per week. Is there any better metrics?

My two cents is that this kind of question is completely irrelevant!

First this kind of question begs for a dogmatic answer : a one-stop solution, an universal metric that would fit every situation, disregarding any specificity of the environment or the business, a magical performance index. I’m afraid this sort of things does not exist.

The first thing you need to ask yourself when searching for a metric is probably “why?” : What are we trying to achieve by measuring this ? Basically there are three kinds of metrics :

• motivation metrics are meant to catalyze improvement. Scrum’s velocity can be a good example. Defect rate can be another one if the goal is to improve QA.
• business-related metrics are aligned with strategy at the business level. There is a goal that must be achieved at the company level and we need to know if we are on track to achieve this goal.
• metrics that should not exist!

Hence a much better question would be

Our company wants to reduce customer dissatisfaction. Customers mostly complain about the poor quality of our software. Moreover they also claim that we do not release often enough and that we take too much time to fix defects in the product. 

But is there still a question?

This article is part of the “No dogma” series. Do not forget to read the other articles on this topic.

As I wrote before, I spend much of my time reading stuff from pm.stackexchage.com (PMSE). A typical question on PMSE goes like this (not a real question, but close):

My team and I are doing Scrum, and we are going well most of the time, but it happens that we fail to complete all the stories planned for the current Sprint. In this situation the story is rejected and sent back to the backlog. When we do so we stop working on the item, then we have a Sprint Review Meeting, a Sprint Retrospective, (a weekend) and a Sprint Planning Meeting that inevitably re-plans the story for the next Sprint. Only then we can finish the job. Since our stakeholders do not seem to need a precise synchronization point exactly every two weeks (we do 2-week Sprints), I don’t quite see the interest of keeping this fixed timebox for Sprints in our Scrum implementation. What am I missing? Why should we keep using fixed timeframes?

and a typical (and caricatural) answer is like “Scrum uses fixed timeboxes. This is how we do“. This is what I call the massive lobotomy of guru/dogma-driven thinking.

I’ve already talked about it before, but I wanted to be more explicit here. So if you allow me this Morpheus-style statement, my answer to this question would, in short, be “Free your mind”.

Let’s forget about Scrum just one minute. Let’s even pretend that Scrum does not exist at all and assume that the question is more like

My team and I implement an iterative, agile-minded, software development process with fixed timeboxes for each iteration. We are going well most of the time, but it happens that we fail to complete all the stories planned for the current iteration. In this situation the story is rejected and sent back to the backlog. When we do so we stop working on the item, then we have an iteration review meeting, an iteration retrospective, (a weekend) and an iteration planning meeting that inevitably re-plans the story for the next iteration. Only then we can finish the job. Since our stakeholders do not seem to need a precise synchronization point exactly every two weeks, I don’t quite see the interest of keeping this fixed timebox for iterations in our process. Should we keep using fixed timeframes? Why?

An obvious answer is now : “You’re right! If you do not need fixed timeboxes for business reasons and think your team can deliver new features continuously with a more floating deadline, why not giving it a try? Just be careful that your team does not work on too many items at once and still focuses on finishing them, now that the deadline pressure has been released.” You are about to invent Kanban!

I’ve talked about Scrum a lot here but that is not my point. What I am trying to say is that every dogma once was just a solution to a particular problem that their guru, who was just a simple software development manager then, tried. Then the guy thought “Hey! That is working pretty well! I’m sure many other teams could use this method as well” and he became a consultant, wrote a book, animated training camps and master classes, launched certification programs, etc. Little by little people, followers, adepts have forgotten the why part, the very reason why the now-guru has tried it for the first time, and started focusing on the how part. They stopped thinking by themselves. They just wanted to implement the new method. We have to do it like this. It’s written in the book. The Certified Coach said so. Etc.

Think by yourself. Try things. Learn from your mistakes. Become the next guru…

If you read this article down to this point, you definitely want to read Pawel Brodzinski ‘s Agile Bullshit: Agile Thought-Leaders Know It All : quite the same topic, but treated by a much more experienced project manager than your humble servant.

It’s been something like one year since I started participating in Internet communities about software project management. I’ve read tons of questions and answers on PMSE, discussions on mailing lists and so so many blog articles and books. During this year I’ve noticed kind of a pattern : to get faster results, people want off-the-peg solutions, they want ready-to-use methods that they can apply in any situation. They don’t care of the reasons why it works, they don’t mind if the solution is not as suited to their problem as they initially thought : they are happy, because the solution they have gives them the illusion that their problem is trivial : they just need to follow the dogma.

Dogmas are seducing : everything is written. You just need to follow the book, right? Follow the guru!… But wait a minute : it is pretty paradoxical, isn’t it? Every business is different, every customer is different, every project is different, every software development team is different, every stakeholder is different, every day is different, and every one of you guys, hoping for this never-ending enumeration to eventually come to a point, is different, yet there is an universal solution that works every time. Bullshit!

Of course I know that many of you readers know that managing a software project is all about complexity and balance, that you need to adjust everything on a daily basis, but still we can see, all over the Internet, people seeking for the miraculous solution. That’s why I am launching a small series of articles, for the next couple of weeks, on the topic “No dogma”.

Articles in the “No dogma” series:

• The massive lobotomy of dogma-driven thinking
• We love metrics!
• The Wise Man and The Inquisitor Priest
• Non-allegiance
• Definitions are harmful