Monthly Archives: May 2015

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.