Tag Archives: project management

The Wise Man and The Inquisitor Priest

No dogma,
A wise man
Wisdom…

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!

No dogma,

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

No dogma,
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 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.

No dogma!

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:

Slack Time : A try-learn-improve catalyst

Kanban and Lean Software Development, Uncategorized, , , , ,
kaizen

In my opinion, a software development actor – by actor I mean a company, a team, a PM, a developer, the PM’s dog – starts being Agile and thinking Agile when he realizes two things. First that the customer – or product owner – cannot detail all the requirements and all the features at the beginning of the project, and will probably change his mind anyway. Second that software development is a creation activity (craftsmanship), not an engineering activity.

Once he realizes that, he begins to feel confident in the fact that some things cannot be streamlined and plan-driven from the start, that there is no such thing as a recipe to make a good software, and that both the requirement part and the pure development part are somehow made of try-failure-try-success cycles. So we try and experiment. If you are developer you might want to try and build your own set of best-practices that fit your current situation. If you are a project manager you might want to try to improve the process by making some small adjustments in a try-and-learn format. In short you stop being dogmatic, you stop thinking in terms of plan-and-apply and begin to believe in try-learn-improve.

This new try-learn-improve culture is basically what Japanese people call kaizen, which is kind of a buzz-word these days. The whole Agile thinking is based on the concepts behind kaizen : improve what you are doing every day, step by step, little by little, from the inside, each time the environment changes, etc.

At the highest level this is now a no-brainer: we stop trying to deliver the whole value – the whole product – at once but deliver it little by little, adding value at each step and gathering feedback as quickly as possible, allowing a quick learn-and-improve loop. Scrum, for example, completes this loop on every sprint through a review with the stakeholders and a retrospective with the team.

At a lower level, however, things are not so obvious. Of course people know that there might be some improvements to do. If you ask a developer, she might give you a list of two or three things that should be improved. Same for a tester. But they just can’t make those improvements. They just don’t have time. And because they don’t have time, they cannot complete the try-learn-improve loop. Why? Because their project managers try to hunt slack time down, believing in the 100%-utilization dogma.

There is a misunderstanding here, a confusion between “a good process utilizes all the resources at 100%”, which is questionable, and “utilizing all the resources at 100% makes the process good”, which is definitely wrong. And project managers that continuously try to maximize resource utilization are wrong. They are running after a symptom, a consequence of what they really seek. Metaphorically having a fever does not make you having flu.

If you are a Kanban-aficionado like me, you already know that limiting the work in progress can help us getting the process under control and ensures that things will end up being done. We are not going to start a hundred things at the same time without completing them. But WIP limits serve another purpose : creating slack time. When someone is “blocked” because of WIP limits and cannot do regular work he has to do something else, which can be about improving its own work, thus completing his own try-learn-improve loop, or, if you believe in self-organized teams, improve the current flow by helping unblock the bottleneck, or even improve the whole process if possible.

But even if you don’t practice Kanban, you should still try to create slack time, thus creating room for improvement. The main advantage of creating slack time with work-in-progress limits instead of scheduling it is that it might create opportunities for improvement right away. For example, a developer who cannot do regular work because the testers are overburdened might work on test automation improvement, etc.

As a final note, you are invited to read (and sign) Pawel Brodzinski’s Slacker Manifesto. You might also want to watch the video of his talk at LKCE2012 that deals with the subject.