Category Archives: Uncategorized

Huge collection of tools

Blame your tools !

Uncategorized

A couple of years ago, I used to blog and tweet a lot about #NoEstimates, before I decided to completely quit this discussion. In one of the latest articles I wrote about estimation, I insisted on estimations as being only a tool. Even though I won’t discuss much about estimations in the post, I think there is still room for talking about tools, and how they can catalyze, or, on the contrary, inhibit, a business or an organization cooperation and improvement.

tools ?

WWII poster about broken tools, from https://catalog.archives.gov/id/535048

Before going any further, I’ll share with you my own definition of what I call “a tool”. A tool is any object, or a process, or a word, anything really, that you hire for solving a problem.

For example, a hammer is obviously a tool, but money is also a tool : it was invented to ease exchanging goods between people. An important thing to understand is that a tool is not essential. It is something that people use to achieve a goal, but a tool is not a goal. You don’t want to own a hammer, you want to own a hammer because you often need to nail stuff to your wall. I suppose that money is only useful in a context of private property, but I can’t remember buying anything from my wife, or from my children. At a wider scale, some anarchist communities from the past removed money as well. It’s just a tool.

control and uncertainty

Human beings don’t like when things go out of control. They are scared of unpredictable behaviors. And, this is true for individuals, but this is also true in a team or any kind of organization, of any size. That is why we, Human, like process. A process is a tool, or a set of tools, for keeping things from happening in an unpredictable manner. A process can be heavy and constraining, but it is reassuring. It becomes kind of meta when we think that management, in its own way, is a tool created for dealing with creating and improving process, which are tools !

It is very important to understand how much effort Human can put in making sure that everything stays in control. In a business organization, predicting the future is vital, hence the invention of tools like budget, gantt charts, and estimations

WWII poster about broken tools

blaming the people

When people are used to working with a defined set of tools, they tend to forget that those tools do not define the organization, but it’s the organization which defines the tools. There was a problem to be solved, the organization invented, or hired, a tool to get rid of the so-called problem, and now we keep using the tool because we don’t want the problem to come back. But when we live in a process, or let’s call it a system, for a while, we are inclined to believing that the system rules the organization.

In this context, when someone misuses a tool, we naturally blame him/her. The system is good, the person who misused it is evil. When a worker, in a factory, causes an accident with a machine, the company accuses him/her to be inattentive, or worse. Sabotage ! (you may not know it, but the word “sabotage” comes from the French word “sabot”, a clog, which strikers used to throw into their machine to break it).

Poster representing a worker falling

Any system, any tool, has caveats, and as the Murphy’s Law teaches, there will be someone to misuse it. But, where most organizations see an occasion to blame someone, you must see a place to improve the system.

improve… or remove

In France, in the second half of XVIIIth century, King Louis XVI realized that the monarchy was not doing its job well enough. Monarchy is definitely a tool, so he tried to improve it so that the problem to be solved, which was basically keeping him on the throne, could be dealt with. But the system was too heavy and flawed. Privileges, unbalanced taxes and laws, huge inequalities between the people, nobility and the cloth : the gap was too important and every try was another failure. The solution : remove the tool. Long story short, Louis XVI is beheaded.

"Louis XVI de France", Antoine-François Callet

When a system goes wrong, an organization will often, after blaming some people of course, try to improve it so that the misuse situation never happens again. This is when new tools are created. In the introductory example, many tools were added to monarchy : new local parliaments, new laws, new taxes, abolishing corvée, the estates general, etc. But, most of the time, it just makes the system more complex. That is why you should always consider removing the failing tool completely as an option. Remember : it is the tools which is primarily failing, not the people who use it.

more practical examples

  • In my house, in a room that used to be a bedroom, we store washed laundry that needs to be ironed. We used to put it on a table. Unfortunately, the table was quite big, allowing us to store an impressive amount of clothes on it. My wife, realizing that we were not using the table as a simple buffer anymore, decided, instead of blaming us two for being lazy, to remove the table.
  • In France, the presidential election campaign was horrible. Day after day, a new scandal arose, and people were just disgusted to realize that all of those politicians who lead the country were so corrupted, and selfish, and misusing their position so much for their own benefit. But maybe the problem is in the system itself. Révolution !

Two cases/trolls from software development now :

  • In Object Oriented Software development, every problem has its design pattern. A common improvement strategy is to stack them up : “Oh! In this situation you should add a factory to build the various strategies to be injected by the dependency injection container into the front controller, so that the facade abstracting away the service is …” or maybe plain old functional programming would do the trick
  • In modern javascript programming, the current hype is to use React, with redux, with redux-thunk, with reselect, with rereselect, with recompose, with redux-saga… or maybe it’s completely insane to add tools one on the other to try to mitigate the problems of each previous tool

conclusion and takeaways

a pile of rusty tools

  • Tools are just tools, they should not define your organization.
  • When a tool works that’s great. When it doesn’t work, or allows people to do bad things with it, change it
  • Instead of blaming the people for misusing a tool, blame the tool for allowing people to misuse it.
  • Sometimes it is better to throw the old tool away completely. Maybe the original problem does not even exist anymore

There ain’t no bad requirements

Uncategorized,

The Bad-Requirements Mea Culpa

I often take part in conversations on the topic of “bad requirements”. Typically a project manager starts complaining about how poorly one feature was developed. Maybe the feature went out very late, or it might be because of an abnormally big amount of bugs, or whatever problem that you can imagine (or remember of). Sooner or later in this conversation, the PM starts thinking that something went wrong because of him. And inevitably he ends up blaming his requirements.

It is very easy to blame the requirements; and the more precise they are, the easier it is to find that they are bad. I remember of a particular story of a website that should have been released in three languages, but the Spanish contents were not ready yet. It was decided to open the site in French and English only. Instead of explaining the problem when describing was needed, the PM in charge wrote something like “Hide the Spanish flag”. Very precise, and very incomplete. The developer did not ask any questions and actually hid the flag using CSS. The Spanish site was still reachable and got on top of Google searches with Lorem Ipsum contents.

Nevertheless we should not blame the requirements. If you recognize yourself here I’ve got a good news for you : there ain’t no bad requirements. 

Conversations

In the Agile world, the word “requirements” has been considered harmful and is now viewed as a monster that should be avoided at any cost. I profoundly disagree with that because, once again, “requirements” is just a word. The truth is even Agile practitioners use requirements, and this is because we need a way to express what we need to do with the product. Sorry my fellow agilists, but the truth is that user stories are functional, user-centric, goal-driven requirements.

Requirements, whatever the form you use, are not bad in essence. They are just tools. Like any other tools they can be used correctly or badly. But on the contrary to other tools that can be hard to master and very error-prone, requirements are quite easy to use if you remember what their real purpose should be. If you write requirements in stone and never talk about them whatsoever, you are running into big troubles. But whatever how you write them, if you use requirements as a conversation igniter, then you’re good.

Let’s go back to the example above about the Spanish web site. The real problem is not that the requirements were to hide the flag. No. The problem here was that the PM did not explain the purpose of what he needed, and that the developer did not ask. So the real problem is the lack of a good conversation, as simple as :

– Why do you want the flag out ?
– Well, the Spanish contents are not ready yet. We don’t want the Spanish site to be visible.
– Hum… Okay, maybe we should make sure the site not reachable at all, and set up a redirection just in case we forget something.

Tada! You’re done. No user story, no weird template or framework whatsoever, but only one thing : a conversation. A requirement is a tool which purpose should be to enable a conversation so that the best possible options are chosen, but there is no bad requirements, only bad conversations.

 

 

Why I decided to quit #NoEstimates

Uncategorized

Introduction

#NoEstimates is essentially a twitter hashtag, as I already mentioned in a previous post. In this post from late 2014, I tried to explain my point of view on both the #NoEstimates hashtag and the reasons why I think we should try as much as possible to find other ways than estimates in order to make decisions.

Today, I decided to stop using #NoEstimates as a hashtag, and the purpose of this post is basically to explain why.

The best I could find to summarize my thoughts right now is this tweet of mine :

Origins

When I first heard of #NoEstimates, I was the leader of a small development team, using Kanban in quite a Lean fashion. The team was not really involved in estimating potential value or cost, or even effort; so that the only thing business was asking from us was delivery date estimations.

As I explained in “Indian Planning Poker”, we first tried to use effort estimates – the Agile way – to deduce delivery dates. That proved completely useless and a big waste of time. Since we were in a Lean state of mind, we decided to drop all those wasteful estimation stuff and use a simple rule : slice it until it is small enough to be “as usual”. This would be sufficient to enable statistical forecasting : not every work item would be the same size, but their size would follow a distribution that we could use.

In Kanban we want things to be as much business as usual as possible. The standard, Kanban, way to operate is to identify several classes of service, for example based on their cost of delay, and make sure we “modelize” their cycle time distribution. To be clear : the heuristics we use for determining cost of delay and slicing work items are definitely some kind of effort/risk/complexity/cost estimation.

My first blog on the #NoEstimates topic was a rant against standard Agile, velocity-driven estimation. There is something I don’t get with this story point, velocity thing, really. At that time I thought that #NoEstimates meant exactly “no fucking story point estimates, use data and statistics for fuck’s sake”. I was then – I still am – a pretty big fan of people like Pawel Brodzinski and Troy Magennis.

Hopes

While I was stepping into the #NoEstimates world, I realized that some of the most important thought leaders behind the hashtag were sharing my views on budget-driven development, what I called post-agile. In fact I realized later that it was just “Agile” – not post-Agile. Anyway.

Product development became a main focus. Lean startup, story maps, impact maps, “job to be done” are the kind of stuff I got into. I really believe in product discovery and learning. My main thought here is : do not estimate outcome, try and learn. Learning might involve estimation though.

Opponents

When I started tweeting with the #NoEstimates hashtag, I wanted to say something like “Hello! We don’t use effort estimates here. Come around, I’ll tell you how if you wish”, but that did not happen. What happened was that #NoEstimates was actually a minefield. I immediately had to answer things like “Give me a real example of a multi-billion project done without any kind of estimates”. Ouch. “Please reply to the 5 blog posts I wrote against #NoEstimates”. Hum…

I tried. I genuinely tried to answer, given my knowledge and experience. But it seems like I failed. I had pretty interesting conversations though.

Disillusions

But #NoEstimates comes with a huge load of emotions. Time passing, I noticed that most of the conversations around #NoEstimates were very superficial. I got involved in a couple of them myself. On the topic of #NoEstimates you can find conversations about linguistic, semantic, how to behave politely, etc. and all of this comes and comes again without any hope for improvement.

I really got frustrated and wrote an open letter to try and understand why #NoEstimates was that dangerous, why there was so much hatred, on so little details, in vain. I saw many people, including myself, try to explain that not all estimates are to be removed, that obviously we knew that we basically estimate all the time in our day-to-day life, in vain too. Neil Killick, who recently got involded in a pure semantic argument, also tried to sort this all out, in vain again.

The thing is that this hashtag is bad, too extreme maybe. I’ve seen it described as a tribe, with some revolutionary connotation. The truth is  we should have settled the semantic discussions a long time ago. Instead :

If we want to move forward on this topic, I think we need to stop using the #NoEstimates hashtag. When I’ll come to twitter to talk about estimates, I won’t hashtag #NoEstimates anymore. Estimates are just a tool. There is always a bigger purpose and we should talk about it instead. Are we talking about #ReleasePlanning ? Is it #ProductDevelopment ?Estimates are a vehicle, not a target. Let’s move forward and talk about the real things.

MyToy

I just released a Lego-based Agile product development game for small teams, called MyToy.

You can find detailed instructions on the dedicated page : MyToy : An Agile Product Development Game.

If you have any suggestion or comment, feel free to leave a reply here, or use the dedicated contact form located at the bottom of the game instructions page.

Losing product vision

Uncategorized,

Developers, and I am no exception, usually complain that product management people lose product vision. They are often tempted to fill the product with a bunch of “useless” features which dilute the real purpose of the product, the main job of it. And since one of the most unpleasant thing of a developer is not understanding the reason why a feature should be added, this often causes endless arguments and create a real barrier between us and them.

Now let me tell you a story that happened yesterday.

A teammate and I were were talking about making coffee. As both him and I own a single serving coffee maker at home, we always experience huge difficulties when we have to make coffee with the regular coffeemaker that we share at work. When I first had to use the machine three weeks ago, I had not touched a regular coffeemaker in the past four years. I didn’t know the proportions of coffee and water to put in the machine and the result was…spectacular.

During our conversation we came to think about a product. We had a clear problem to solve : measuring the volume of coffee to put in the coffeemaker. Instead of using a traditional measuring spoon, which would only partially solve our problem (we would still have to know how many spoonfuls to use), we quickly designed a kind of 10-cups measuring bowl :

10-cups measuring bowl

We had a product vision, a problem to solve, a job-to-be-done, or whatever you call it…and then the conversation continued. Within about 2 minutes our simple, easy-to-use, problem-solving, user-focused product was looking like this :

coffeemeasuringrobot

The new product was much more complete and full of really cool features : voice command interface, measures both water and coffee, can deal with more of less strong coffee, can make coffee for any number of cups, changes used coffee filters, washes the coffee pot, etc. But what was the problem we were trying to solve yet? Clearly we had lost our product vision.

Quickly designing a product is easy. Making it evolve in a consistent and coherent way is much harder, and it’s everyone’s job in the team to try and stay focused on the main problems the product is meant to solve. Because losing this focus is also very easy, we must work together on the product, not against each other like we often do.

Je lance aujourd’hui un nouveau site entièrement en français : matthiasjouan.fr

Le thème principal est le même qu’ici : le développement logiciel tant au niveau de la programmation pure et dure que d’un point de vue gestion de projet. On y parle donc de Lean Software Development, de Kanban et de tout ce qui fait notre art(isanat).

L’idée est en fait de satisfaire nos amis francophones, qui représentent plus de 45% des lecteurs de Scalable Ravings. Je continuerai bien sûr de publier ici le contenu en anglais

À bientôt sur matthiasjouan.fr

————————

I am launching today a new site entirely in French : matthiasjouan.fr

The main topic of this site is the same as here : software development, both in terms of programming and in terms of project management. We’ll talk about Lean Software Development, Kanban and every aspect of our craft.

The idea is to satisfy our French speaking friends, who represent more than 45% of the readers of Scalable Ravings. I will of course continue to publish English contents here.

See you soon on matthiasjouan.fr

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.

A Bug Tracking Story

Uncategorized, , ,

I’ve been working at Ve-hotech for years now. I first started being a developer and then moved to a project manager position…and as far as I can remember the tracking of bugs has always been a problem. The problem is not actually the bug tracking itself but to find a way to handle bugs when you cannot solve them as quickly as they get reported by end users (yes, we’ve been through pretty tough times…)

A classical approach for handling an important amount of bugs is to use a web-based bug tracking system. This is a pretty convenient way to centralize all the reported issues. The business stakeholders can then sort the bug list and prioritize it, allowing the team to pick up the next more important issues and solve them.

Although this approach might be compulsory when dealing with hundreds of bugs or when the team is not collocated, it surely is a pretty big overhead when the number of bugs is thin and the team and product owners are working at the same place.

Understanding that nobody really wanted to use a web interface for managing bugs, that the redmine instance we were using was beginning to get out of sync, and as we were moving to Kanban, I decided to morph the bug tracking system into a physical, visual, post-it driven bug backlog. Imagine a 2-meter high sheet of paper covered with little, yellow sticky notes – 80 or so.

The goal of this bug wall was to ease the work of product owners, since they could see everything at once and select the defects they wanted the team to solve more easily. New issues were added into a special area of the wall so that stakeholders could identify them and decide where to place them on the wall – and when to put them into the Kanban flow.

There were three main drawbacks with this bug tracking implementation :

  1. The team – the people who know about the technical part – was not much involved into the prioritization/evaluation of bugs criticality
  2. There was no simple way to get a whole-picture view of the product stability
  3. Who can possibly sort 80 sticky notes?

To solve these problems, the boss (I wish I have thought of that first but…) came out with the idea of using a sort of criticality matrix.

We could actually dramatically improve how bugs were handled using two criteria:

  1. Intrinsic severity : Does this bug jeopardize users’ data? Does it happen all the time? Is it highly visible? On the contrary is it only a highly improbable situation? Maybe we could not even see it by ourselves? etc. We decided that four levels of criticality were enough, each one having its own set of criteria.
  2. Technical impact : How the team feels about this issue. Is there any identified risk? Is the fix difficult to implement? Do we need to rewrite an important part of the product? Do we even have a clue about how to debug this? etc. We don’t need any precise measures or calculations here. A simple gut feeling will do.

So the current implementation of the matrix is a 2×2-meter grid with horizontally the intrinsic severity, from A to D, and vertically the team feelings : 

As you can notice the first line is special. Bugs that cannot be quickly evaluated go there and need special attention as basically the team do not know where it comes from.

In the above example the two bugs in [A/???] are highly critical and must be dealt with as quickly as possible since, for example, they happen all the time and threaten user’s data, and the team don’t know at all how to solve them. On the contrary the four bugs in [D/:-)] are likely to be very improbable bugs that would be very easy to solve with no real impact on the rest of the product. There is no emergency to treat them.

As we wanted to have a global stability indicator, we affected each row and column an arbitrary coefficient : A=20, B=10, C=5 and D=1; ???=4, : -)=3 etc. In the above example, each [A/???] bug is worth 80 points (20×4) whereas [D/:-)] bugs are worth 1 point each. The above matrix can thus be estimated : 20*(2*4 + 2*2) + 10*(1*4 + 4*3 + 2*2 + 1*1) + 5*(1*4 + 4*3 + 4*2 + 2*1) + 1*(2*3 + 1*2 + 4*1) = 592

This approach facilitates decision making about scheduling while providing a good visualization and an easy-to-understand stability indicator. It can also break the last silo that might still exist in an Agile organization : the one between product owners and teams.

Do you use a visual tool for bugs with your teams? How do you prioritize them? Go share your experience and answer this follow-up question in pm.stackexchange.com

Exorcism : follow-up

Uncategorized

Yesterday I told you about a debugging method I like to call exorcism, and how, until recently, I thought I had invented it. Then let me tell you a story.

Today I was at my parents’ house. That was tea time and I was talking to my father about the fact that I discovered that “exorcism” was actually a common practice. My father never went to college. He even stopped his studies in tenth grade (we call it “seconde” in France). Nevertheless he always helped me with my math problems when I was in high school, and even after. But today when I told him about exorcism he said : “That’s exactly what I’ve done with you when you were in high school. Every time you came to me with a math problem I used to sit down and listen to you, but I never understood a word of what you said! Neither the problem nor the solution! The thing is that you needed to rephrase the problem out loud to find a solution, and as I’m pretty good as a listener…”

Wise man.