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.

Ravings on #NoEstimates

#NoEstimates

In this probably too long post I will try to expose my thoughts on #NoEstimates as I see it. I will also try to give some pieces of answer to the most recurring questions and critics exposed by #NoEstimates opposition.

Twitter

#NoEstimates is by essence a twitter thing… and this is a plague, really. I’ve been reading many, and participating in some, #NoEstimates twitter conversations, and what really hit me is how much it is difficult to have a built conversation within 140 characters. It especially is with #NoEstimates because of an obvious vocabulary issue in the very definition of what an estimate is, and how much it differs from a forecast for example. I am convinced that many arguments about estimates would not have occurred if people would have first worked on a kind of “mutual understanding”.

So, for the record, and in order to make future conversations with me easier, I consider estimating as very different from forecasting in the sense that forecasting uses data to predict the future, usually with statistics and probabilities, while estimation is more based on experience and is more “vague”… but that’s only my definition and you may very well disagree. We just need to know what we are talking about before we start fighting.

Not doing estimates existed way before #NoEstimates

The first story I heard (read) of was the one of Dragos Dumitriu, as described by David J. Anderson in “Kanban : Successful Evolutionary Change for Your Technology Business”. This story dates back to 2004. There are of course many other “old” stories like this one, including from people in the anti-#NoEstimates side (I’m thinking of Trevor K. Nelson here).

What is important is that although the hashtag is rather new, the question is pretty old. This also means that Woody Zuill’s point of view (he initiated #NoEstimates as a hashtag for those who don’t know) has nothing to do with a dogma or anything of this kind. I find it’s a shame to read sometimes things like “zealotry” or “evangelical” when talking about #NoEstimates. People who wants to talk about not/less using estimates in software development can use this hashtag. Period. Woody Zuill has his own view, others have other views, no “absolute” here. #NoEstimates is neither a movement nor a religion.

Common sense

I am paraphrasing Peter Kretzman here, but I genuinely think that trying to get rid of estimates is pure common sense and I will try to explain this as much as possible.

muda

The first thing that comes to mind is that estimates do not produce concrete value. That makes them a waste in the sense of Lean. It seems logical, if you follow this paradigm, to try to get rid of them when possible.

only a tool

“[Estimates are] a tool, not an outcome” (Peter Kretzman, The case against #NoEstimates, part 3: NoEstimates arguments and their weaknesses). I agree with that. One of the main critics anti- have against #NoEstimates is “Don’t blame the tool because you don’t know how to use it”, and this argument is a bit flawed in my opinion : let’s abstract away “estimates” one moment and talk about a random tool instead. So let’s say we have a tool. This tool have proved useful many times but it appears that many people fail to use it correctly. This tool is intrinsically dangerous when not correctly used. Often it is so much misused that it can jeopardize the whole project, or the whole company. Facing with this situation in his company one can either

  • Make the tool easier to use, which means change the tool, so that people can use it correctly
  • Train people in the tool, so that they eventually manage to use it correctly. The “don’t blame the tool” critic live here.
  • Find another tool that would do the same, or better, and would be easier to use
  • See if we could completely get rid of the tool, maybe by changing the very problem the tool is designed to tackle

#NoEstimates is about the last two points, or a combination of both :

  • some of the #NoEstimates advocates seek to find ways to remove estimates as much as possible and replace them when needed by forecasting based on actual data and statistics. A very common practice in the Lean/Kanban world.
  • others – or the same actually – believe that by changing the business relationship we could completely remove the need of providing any kind of future prediction. Hence no estimates at all. Some relationships are more difficult to change than others though, and of course internal software development with fixed time and budget (“own money”) would be easier to do with no estimates than a fixed- scoped public-procurement based projects…

obvious in certain situations

There are domains where estimations are often not used at all, in nowadays’ software business. Unsorted : very urgent operations, fixed-budget fixed-time research and development, fixed-time options testing (UI design testing with prototypes for examples). You can figure some more situations I am sure.

We all agree !

Maybe the main thought I have about #NoEstimates, and it will be my conclusion, is that most of the #NoEstimates folk agree with most anti-#NoEstimates people. Unfortunately some barriers exist and it is our duty to try and break them so that the discussion go a step further. That is the goal of my Open letter to anti-#NoEstimates people.

 

Open letter to anti-#NoEstimates people

#NoEstimates,

Dear Peter, Glen, Trevor…and friends,

As some of you might already know, I’ve been hanging around in the #NoEstimates hashtag for quite some time. Even before that, before I even noticed that there was a hashtag, I and my team had been practicing a less-no-better-fewer-leaner-estimates kind of software development.

To sum it up, my story is basically that, in a context of co-called “Agile” software development, I was not comfortable with how estimates were done (the whole poker planning thing). Instead of trying to improve our estimation process, to make it more accurate and reliable, which is a path I respect, I, in a Lean-minded attempt, tried to remove estimates as much as possible and use historical data instead. I know that there is a recurring discussion out there about the very definition of what an “estimate” is and the difference there is between “estimate” and “forecast”. Honestly, although this discussion drives – consumes – a big part of the whole #NoEstimates thing, I don’t care much.

Ever since I began to read things about #NoEstimates, on twitter or elsewhere, I keep asking myself the same question. I might already have tried here and there to talk about it. Maybe I sometimes was a bit too vehement (euphemism), which may or may not explain why I still haven’t found The Answer. That is why I’m writing this open letter.

So my question to you is very simple :

Why do you even care about #NoEstimates ?

#NoEstimates is a hashtag where people who want to try to do software development business without estimates gather and talk together. To be precise I should write “do their software development business”. What I am meaning here is “I am a software editor, and I run the company without estimates because I do blah blah” : good for you! On the other hand “Estimates are a very useful tool for me and I can’t possibly imagine why I should not use them in the context of this US DoD public procurement I’m interested in.” : good for you too! That’s OK if you use estimates successfully. I once asked if anybody had ever heard of a no-estimate-like story in the context of public tendering. The answer was “no“. That’s not a big deal either.

So why do you all fight #NoEstimates like it was some kind of a threat ? Does anyone of you think that he is going lose his job if #NoEstimates proves usable in some domain ? Would it somehow jeopardize your business ? Please ! Please tell me why this permanent, impassioned rant about #NoEstimates !

P.S. : I know, because I’ve seen it already, that some of you will accuse me to try to avoid having a discussion : not at all! On the contrary I am really, genuinely eager to understand the very Why of all this.

P.P.S. : This open letter can be read as a follow-up to #NoOthers and #NoEstimates

Definitions are harmful

No dogma,

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.

 

#NoOthers interactions

Break silos !

The classical interaction between people supposed to work together on a product (marketing, product management, software development management, developers, designers, etc.) is driven by requirements. The usual (implicit) process is then

  1. I identify a problem I need to solve for doing my job (better)
  2. I identify things I would need to solve this problem
  3. I identify people around me who could provide me the things I need
  4. I require them – namely the others –  to give me those things. Depending on my hierarchical position this part could be more or less easy…
  5. I collect others’interpretation of what I required
  6. I try to solve my problem with those things, and blame the others for not giving me what I required

Typical things I might require here are precise specifications, prioritized user stories, overall goal, estimates, cost, deadline, etc.

The main concern with this approach is inherent in the concept of others :

  • although I might think I know what I need, my understanding is limited to the things I know, to my own domain, and thus I might not be aware of what others know.
  • others are not very likely to understand what exactly I need, leading to a very incomplete solution.

My suggestion is to turn this interaction process upside-down :

  1. I identify a problem I need to solve for doing my job (better)
  2. I publicly expose my problem to the team : no others here
  3. Some of my teammates propose me things they can give me that would be relevant to solve my problem, according to their own knowledge and their own domain
  4. I collect what my teammates gave me
  5. I try to use those things to solve my problem, and improve collectively to a solution.

Some benefits of using this approach :

  • My teammates understand my job better
  • Non-obvious solutions might emerge
  • Nobody feels like they are working for nothing, or losing their time

A very naive example now, to make things clearer : My job consists in hammering nails. For each kind of claw there is a kind of hammer that I get from my blacksmith. One day I am facing big difficulties with a new kind of claw.

  • Classical interaction : I go to my blacksmith’s and ask him to make a bigger hammer.
  • No-others interaction : I go to my blacksmith’s and show him the new kind of claw. He suggests me to use a screwdriver!

Of course this is all very theoretical, so any comments would be appreciated.

#NoOthers and #NoEstimates

#NoEstimates, Break silos !,

Yesterday I promised to give some concrete examples related to what I call #NoOthers. The first one will be #NoEstimates.

What #NoEstimates should/could be

Example #1

Product Manager : “We have plenty of things to do on the product. There are many new features to add and there are also a couple of really embarrassing defects that we should address too. I need to know how long each of those things is going to take so that I can balance defects with new features in the schedule.”
Dev#1 : “Well…It ain’t easy to estimate bug fixing time before we get into it. As far as I can tell right now no bug solving ever took more than 3 days, but we can do some stats if you really need to make accurate forecasting.”
Dev#2 : “The thing is that we are not confident at all with the estimates we give you. For the smaller things we can have some interesting enough statistics based on what we already did in the past…but for user stories like foo or bar the scope is way too big.”
Product Manager : “I understand that you can’t give me accurate estimates…but I really need to know  when we are going to start working on baz. At least sales people need to know.”
Dev#2 : “We can try to split foo and bar into smaller user stories so that they can fit into the stats we have, but maybe we could just consider working on baz right now if it’s that important?”
…

Example #2

Customer : “I need to know how much it will cost me to have this product, and when it will be done.”
Project Manager : “Of course. But allow me to suggest that maybe your real need is not the one you think.”
Customer : “What do you mean?”
Project Manager : “Well, as far as I understand the product you want to build, you definitely need to get to the market as soon as possible.”
Customer :  “Who needs not?”
Project Manager : “Yes. So let’s first try to focus on a core set of features that will allow you to get to the market quickly. We really want to extract the features that compose the very minimum product here. Then we could improve the product by adding the other features as described in the specs…or other features if needed. Does it make sense to you? ”
Customer : “It totally makes sense…but I still don’t see how much it will cost us in the end.”
Project Manager : “It will cost you the amount of money you want to put into it! Of course for the minimum product we will provide you some kind of cost estimate after breaking the selected features into small pieces of work, but for the rest you will be able to stop when you want to.”
…

What #NoEstimates sometimes is / How it is perceived

Product Manager : “We have plenty of things to do on the product. There are many new features to add and there are also a couple of really embarrassing defects that we should address too. I need to know how long each of those things is going to take so that I can balance defects with new features in the schedule.”
Dev#1 : (thinking) He wants estimates, let’s give him estimates! Maybe he wants some random numbers to fill in a lottery ticket after all “No more than two days for each of these bugs IMO. foo is pretty big : I think of 7 or 8 days of work. bar looks easier so I think it won’t take long.”
Dev#2 : “Not sure about bar : nobody has touched this part of the product  for a while. I don’t think we can estimate that upfront… Hmm… What is the real purpose of this story again?”
Product Manager : (thinking) Here we go again! NoEstimate bullshit! She doesn’t want to commit herself with an estimate and will argue about the purpose of every single piece of user story “Come on! You guys are incredible…”
…

No Others

I must admit those (almost) fictional pieces of dialog are a bit cliché, but they outline a key difference between what #NoEstimates is and how it is often perceived :

  • #NoEstimates is a hashtag that gathers people who want to try and find an alternative to using estimates as a tool. It really is a #NoOthers concept in the sense that we need to understand everybody’s needs to find the best suited tool / way of working together (and we think that estimates might not be that tool).
  • #NoEstimates is perceived as a rebellious community of developers – others – who do not want, or who simply can’t, understand what business people – us – need.
  • #NoEstimates can be used as a banner to wave in front of product/project/whatever managers – others – who do not, or simply can’t,  understand what dev people – us – need.

 

More will come on this subject…

No Others

Break silos !,

L’enfer, c’est les autres (Hell is other people)
Huis clos, Jean-Paul Sartre

Silos. Much have been written about them for years, DevOps has made its way, and I’m sure you are familiar with the whole break-down-the-silos thing as we have been hearing about during the last decade.

Yet silos still exist. Why?

Because there are others.

Others. They don’t know us. They don’t know our job. They don’t know what we need to do our job well. They don’t quite seem to even bother trying to understand us. They are selfish and self-centered. They sometimes want to force us do our job in a certain way that is unnatural to us. They don’t want to help us. They basically don’t understand us at all…I’m sure you are thinking of some particular others right now.

The very notion of others implies a conflict of some sort between them and us. But ask yourself : Are others the cause of the conflict or does the concept of others arise as a consequence of this conflict ?

My opinion is that there should be no others.

Others only exist because we choose to solve problems by accusing each other instead of working together…but this attitude does not solve any problem in the end of the day, and only breaks the team into silos :

  • You are a developer and feel frustrated because you don’t really understand the problems your code is supposed to solve : don’t blame the product owner for not understanding your job. Instead try to work together as a team a figure out a better way to communicate
  • You are a product owner and feel frustrated because you have to deal with new features that have been sold to clients but do not fit well into the product : don’t blame the sales people for not understanding the product. Instead try to work together as a team a figure out a better way to work together
  • You are an IT security engineer and feel frustrated because…
  • You are a project manager and feel frustrated because…
  • …

The message I am trying to convey here is basically we are others’ others. When I complain about others not letting me do my job well, or not understanding me, do I even try to understand them? Do I even bother asking what they need to do their job well? Now think about the people you designated as others a couple of paragraphs above…

This little rant is only a beginning. More will come with more concrete examples in the next couple of posts on the subject, but as always feel free to leave a comment below or share your opinions on this subject on twitter.