Tag Archives: no dogma

Definitions are harmful

Yesterday I attended an amazing talk by Stéphanie Walter at DevFest Nantes. In this talk she presented a series of very “lean” tips and tricks about web design and how to organize the whole process from wireframing to development “the hard way”.  I don’t usually write about webdesign…and this is not going to happen today neither, but something in her talk caught my attention.

At a moment near the end of the talk, Stéphanie described an iterative, incremental process where quick feedback loops allow quick reactions, avoid big re-works, induce a better collaboration and a better communication between everybody and allow creating better design, better user experience, … in opposition to the usual process implemented at her company. After the talk, someone asked “Would Agile help you?” and she answered something like “We tried once but it failed. We designed and developed each part of the site one after the other, but the developer missed some opportunities to make more common CSS and had to rework many things after the fact, etc.” I must say I was very surprised because

  1. what Stéphanie described sounded totally Agile to me. She talked about incrementally creating the design, about very Lean-like ways to avoid wasting time, about better collaboration, etc. So the question was very bizarre to me because she was definitely there already.
  2. She answered no!

Actually this is not the first time I hear or read something like “Agile won’t work for us : what we do is [some kind of definition of Agile]” and I really don’t know what to do about it. I’m not even sure that we should do anything about, apart from being aware of the phenomenon. This is just a funny fact : applying our “Agile” definition failed, let’s drop it completely and go back to our Agile practice.

This whole thing reminds me of a question a colleague asked me some time ago. The team I work in used to practice Scrum, but we improved a couple of things, making us get away from theoretical Scrum and move to a more “kanbanish” process. Since I am supposed to be the Kanban guy, my teammate asked me if we were “doing Kanban now“? I said “Why do you care? Do you really need a new religion?!” Maybe that was a bit a condescending answer, but my point was that we did not need a definition of what our way of working had become. I really wanted to avoid inhibiting improvement initiatives by saying “we are doing method FooBar now”

I think that as long as people feel free to make improvements, as long as they think they are inventing something, then they will keep on improving. But if they happen to reach a point where they recognize something that has already been described, something that has a definition, a concept, they will stick to it and stop inventing. People tend to stop “thinking”, they tend to stop trying things when they “hit” a known, comfortable word.

That is why definitions are harmful : they are very static, very…defined. On the contrary improvement, changing things, is not defined, it’s moving.



I’ve been talking about this before so there will be no surprise : I don’t like dogma-driven thinking in software development (people who know me personally know that it’s also true in politics or any other area).

Tonight I stumbled upon an initiative of Alistair Cockburn : The Oath of Non-Allegiance…and of course I’m in:

I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.

I signed the oath of non-allegiance

Now that I have taken oath, I must make a confession : I sometimes exclude from consideration ideas based on their source when the source appears to me as dogmatic. This is a mistake. Extremism is a plague for learning and anti-extremism is definitely an extremism. So let me add this appendix to my oath:

I will not exclude from consideration any idea coming from schools, dogmas and heritages based on the single fact that they come from a heritage, a dogma or a school.

The Wise Man and The Inquisitor Priest

A wise man

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!

We love metrics!

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?

The massive lobotomy of dogma-driven thinking

dogma-driven thinking lobotomy
dogma-driven thinking lobotomy

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 thisIt’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.

No dogma!

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: