Tag Archives: no others

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

#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.