Master Tailor

This is a translation of the old Swedish folktale "Mäster Skräddare". I haven't been able to find a translation for it, and I find it a bit cute and at the same time quite thoughtful. So here's my attempt at a translation. It's far from perfect, and if you have suggestions how to improve it, I'll gladly consider them.

It's hard to capture the nuance and connotations of the original Swedish piece. Especially the Swedish word "bidde" that roughly means "became". But in some kind of cute dialectal form. The word is never used anywhere else but in the folktale, and has because of this become the hallmark of this tale. The word is extremely hard to translate for this reason.

Anyway, here it is:

Master Tailor

Once upon a time a little man went to the tailor with a piece of cloth.

- Good day, Master tailor, said the little man with a bow.
- Good day, said the tailor, sitting on the table sewing with his legs crossed.
- Can I have myself a little coat sewn from this little piece of cloth? asked the little man.
- That should be possible, said the tailor.
- When can you have it done?
- On Saturday.
- OK, Master tailor. Thank you very much, Master tailor. Goodbye, Master tailor.
And the little man walked home.
Saturday came and the little man went to the tailor again.
- Good day, Master tailor, is my coat done?
- Ah, but no.
- It's not done? Why not?
- Ah yes, it wasn't a coat.
- Oh, it wasn't a coat after all? What happened?
- I'm making a pair of pants instead.
- I see, you're making a pair of pants? When will those be done?
- On Saturday.
- OK, Master tailor. Thank you very much, Master tailor. Goodbye, Master tailor.
And the little man walked home.
When Saturday came the little man went to the tailor again.
- Good day, Master tailor, are my pants done?
- Ah, but no.
- They're not done? Why not?
- Ah yes, it wasn't a pair of pants.
- Oh, it wasn't a pair of pants after all? What happened?
- I'm making a vest instead.
- I see, you're making a vest? When will that be done?
- On Saturday.
- OK, Master tailor. Thank you very much, Master tailor. Goodbye, Master tailor.
And the little man walked home.
Saturday came and the little man went to the tailor again.
- Good day, Master tailor, is my vest done?
- Ah, but no.
- It's not done? Why not?
- Ah yes, it wasn't a vest.
- Oh, it wasn't a vest after all? What happened?
- I'm making a pair of mittens instead.
- I see, you're making a pair of mittens? When will those be done?
- On Saturday.
- OK, Master tailor. Thank you very much, Master tailor. Goodbye, Master tailor.
And the little man walked home.
When Saturday came the little man went to the tailor again.
- Good day, Master tailor, are my mittens done?
- Ah, but no.
- They're not done? Why not?
- Ah yes, it wasn't a pair of mittens.
- Oh, it wasn't a pair of mittens after all? What happened?
- I can't make anything.
- I see, you can't make anything at all? OK, Master tailor. Thank you very much, Master tailor. Goodbye, Master tailor.
And the little man walked home and never came back again.

A Swedish version can be found here: Mäster skräddare

Why not estimating doesn't make sense

Here's a breakdown on my view of "not estimating" (or the hashtag #NoEstimates).

Let's start with the NoEstimates definition:

http://zuill.us/WoodyZuill/2013/05/17/the-noestimates-hashtag/

Key: "...alternatives to estimates [of time, effort, cost] for making decisions"
One could wonder why "value" or "benefit" is left out of the list, as if value alone would be enough, but anyway, this is in essence a good description why we estimate: to make (inform) decisions.

Let's continue with definitions. What does it mean "to estimate"? Let's go to the dictionary:

Merriam-Webster

But, perhaps NoEstimates uses another definition? No, it doesn't seem so. This is a slide from a presentation by Woody Zuill:

https://vimeo.com/131194136

Basically this definition is the same thing as the dictionary version. The dictionary is just more "condensed" and better generalized.

So, the definition would now be "...alternatives to having a general idea about the size or cost of something for making decisions" (I excluded "value").

Let's look at "size". When making decisions, those decisions have impacts. What we want to get a general idea about is the size of the impacts of those decisions. And here the NoEstimates definition of "estimate" fits as well. Everything we do has a cost and takes some effort (and has "value", but we've for some reason left that out). It's the size of those things we want to have an idea about.

Now, one automatically wonders: what would an alternative (to estimates) be?

There are alternatives: Random or chance/hope (and time traveling, but I won't cover that).

You could do "Eeny, meeny, miny, moe" or roll a die, flip a coin, JavaScript Math.random() or turn to Tarot cards, haruspicy, tasseography, or... well the possibilities are probably endless.
But if you'd make a decision (and spend money on something) would you use any of these methods? Well, some do (I guess). But as a piece of advice?

This can't be it. But other alternatives?

Setting a (fixed) budget? But what should the size of that budget be? Math.random()? And how would we have an idea of the size of the scope for that budget ("What's possible")?

Setting a timebox? Question still remains: what's the size of that timebox? Math.random() again..? And the other question remains as well: the size of the scope for what can be accomplished within the timebox?

Seriously, I can't come up with any alternatives. And I've so far never heard one either. And to be honest; there are none either. It's plain old common sense.

Hence, not estimating doesn't make sense.

5 questions before mob programming

I guess most people have already heard about "Mob programming" by now. If you haven't, there are quite a lot of sources out there. Start at mobprogramming.org. Also check out this youtube video.
I both do, and have been doing, mob programming for some time now. I think it's a great way of working in some situations and contexts. Basically we have used it as follows: instead of having one or two people working on a thing and then demonstrating how it was done with a code review, we all work on it together. This is usually common when there's something more "difficult" that needs to be done or when there's something that everyone needs to have a good insight into. These sessions usually last between half a day and a day, or perhaps a couple of days (though I have never been part of that) and have involved around 3-8 people. And with these situations in mind, mob programming isn't really something new. It's the setup (how to arrange a mob programming session) that I think is something to look at. I'm not going to go into details about this setup in this post, you can find resources online. Or drop a comment and I'll try to explain.

But how would it be like to always work in a team as a "mob"? I have some questions in mind. Questions I think one should ask even when considering mob programming sessions for shorter periods of time.

1. Productivity/Cost?

To my mind, mob programming feels expensive. I have never performed any experiments to measure if/how/in what way productivity is affected. But looking at what has been accomplished during these mob programming sessions I can't say that the productivity has increased significantly. For us, this hasn't been the main purpose for doing it either. There are other benefits for shorter periods of time.
But one can just look at it purely mathematically (statistically).
If 8 people finish a task in 1 hour, that task will have cost 8 hours of work.
If 8 people finish one task each in 1 hour they will have finished 8 tasks, and each task would've cost 1 hour each.
Thus, a mob of 8 people needs to increase their productivity by 800%. OK. I hear you. Nothing is never completely parallelizable and probably 8 people might be able to get things done a bit faster. But still: 800%. Things aren't done that much faster, if any faster at all.
Software developers are expensive already. I don't think those paying us would like it to be even more expensive than it already is. So, this is really something to consider before starting; what are the other benefits of working in this setup?
Those benefits usually revolves around less or no meetings (daily standups, code reviews etc.) and also an increased knowledge sharing and overall code quality, no code merging issues, no nonprogressive items (e.g. when someone is absent). But I think there are things to consider here as well. What about training? Do we send the entire mob? Or just one or two? If so, who? Or is the mob responsible for their own training? How is that arranged? And on another (related) topic; what if the mob works on something and everyone "gets it" except one person who doesn't? Is that person comfortable with asking? Because again: productivity. Suddenly there are 7 people explaining something to 1 person. With 8 people at a halt. It might actually go faster explaining something having 7 people explaining it (more inputs/aspects), but it might just as well go even slower having 7 people talking at once. It leads me to the next question.

2. How to deal with Groupthink? (Or the opposite?)

If you haven't heard about groupthink before, you can read more at wikipedia: Groupthink. Specifically; does the mob foster too much agreement rather than surface disagreement? I have no answer to this kind of question. I haven't done mob programming long enough to have noticed any problems with this, but I would be concerned about this if working in a mob situation for longer periods of time.
My experience so far is actually the opposite. I don't know if there's a word for it (similar to "groupthink"), but I've worked in groups containing people with "strong opinions". And that is really good in a way, because it carves out great results (again: in my experience). Thus, you can say that my experience is that we actually are surfacing disagreement. But the flip side of this is that things takes even longer time to complete (see question 1) - reminder: in my experience. We haven't had a need to really deal with this, because carving out great results (and not as in quantitative results) have been the focus and purpose.

3. Rules for opting out?

What would we do if someone in the team doesn't want to mob? How do we make sure that we don't "force" this upon someone? (I guess these are relevant questions for pair programming as well). Does the whole thing collapse? Can someone be allowed to go off into a corner on his/her own? Is that OK? How will the other team members feel about this?
I have no answers to these questions. I've only been in groups where everyone really wanted to do it. Except one time. It was a team with only three members, so I don't know if it counts. But anyway, one team member didn't want to do it and we "solved" it by not doing it. We reverted back to one pair and the other developer working on things on his own.
Still, valid questions to consider before starting a mob.

4. What are people's skills and interests?

This is related to the previous question. There might be some people in the group that aren't interested in some areas of development and/or have no intention in deepening a skill in it. Perhaps some people in the group have no interest in SQL or HTML/CSS or graphic design or interaction design or the backend code or anything else. Should we force these tasks upon them? Should we split the mob into smaller mobs? Is it even still a mob then? Have we kind of lost the benefits of the mob then?
Again, this has never really been an issue for us. We have worked on very specific things for shorter periods of time. Thus, it has always been interesting for everyone to see and be part of what's done. But is it true for everything and/or in the long run?

5. What are the means for hiring more people?

If we have a mob, why would we hire new/more people? What's the purpose? And a different, but related, question: how big should the mob be? If everyone is working on the same thing anyway, why not reduce to e.g. 5 people or 4 or 3?
One reason might be that the mob is missing some kind of competence/skill. But after that? Do we have to form a complete new mob? How big should that mob be? Or should some people (with certain competence/skill) switch between two (or more) mobs? If so, is it still called a mob? Are we limiting ourselves with whom we can hire (see question 3)? Or is it better to just keep increasing the size of the mob to get increased productivity when starting/investigating/experimenting with new initiatives? Or is it better to let the existing mob switch between initiatives? But then... have we lost the ability to hire more people? What will that lead to?

Pair programming

Some of the questions actually apply to pair programming as well. Especially the first question. But with a pair you only have to increase productivity by 200%. And one could argue that the quality level increases by the same amount making the extra cost worth it in a longer perspective. Though in my experience, this is far from always true. In many projects (when I think of it, I guess it's all of them) I've been part of, the cost tends to drift away, forcing us to stop working in pairs after a while or asking for more money/time. That might be bad move in the long run (or not?). And sometimes a single developer might spend way too long time on a task not asking for help as well. And when working as a pair, we always produce more elegant solutions and it always feels very satisfying (and what's that worth?). But still, I think it's a relevant question when pairing as well: is the additional cost actually worth it? Is the quality and knowledge sharing etc. increased by the same amount? Anyway, two people is at least "only" double the cost.
Would you hire a painter where one paints while the other is standing behind giving advice? I know, it's not comparable with knowledge work. But from a cost perspective it's still relevant. Would you hire 8 painters with the same setup?

Perhaps there are more questions to ask. Feel free to add those as comments and I might add them.

An attempt at explaining HSL colors

Working with CSS (Cascading Style Sheet), I've come to appreciate HSL (Hue, Saturation, Lightness) colors over the more common (I'd say) RGB (Red, Green, Blue) that is used when working with colors in CSS. I think it feels like a more "natural" way to think of colors. Once you get to know how it works. RGB is pretty straightforward since it's just a mix of red + green + blue, and by mixing those colors you can get different nuances. HSL is not equally straightforward. At least that's what I think :-)

HSL is part of CSS version 3 colors, but currently it seems that Internet Explorer 8 is the only of the major browsers not supporting it (see caniuse).

But why do I like HSL better than RGB? I'll try to explain how it works, and then you can judge for yourself what you think.

Just like RGB colors, HSL is represented by three values. The first value (Hue) is a number between 0 and 360). It's the number of degrees in the color circle (and thus, 0 and 360 is the same value). See this picture:

(picture from wikimedia)

HSL(0, X, X) is red. HSL(120, X, X) is in the green area, etc.

Now, let me jump to the last value - Lightness. I think it's a bit easier to explain than Hue. I think of it as "whiteness" or "blackness" (duh!). A number between 0 and 100%. Thus 100% will always be white and 0% will always be black - no matter what the other values are.
So HSL(0, X, 100%) is white just as HSL(120, X, 100%) is white. And HSL(0, X, 0%) is black, just as HSL(240, X, 0%). If you stay at 50% you'll have "medium" lightness.

HSL(0, X, 50%) is red. HSL(60, X, 50%) is yellow.

What's Saturation then? I like to think of it as "grayness" or, inverted, as "colorfulness". A value from 0 to 100%. Where 100% means "full color". And 0% means gray. And 0% will always mean gray, no matter what degree in the color circle you set. But! The Lightness value trumps this value, so HSL(X, 0%, 100%) and HSL(X, 100%, 100%) is still white and HSL(X, 0% 0%) and HSL(X, 100%, 0%) is still black. But by playing around with the Lightness value, you can get different shades of gray.

HSL(0, 0% 50%) is gray and HSL(0, 0%, 80%) is lighter gray.

And now we're starting to touch the beauty of this (at least what I think).

Let's say we have the color red: HSL(0, 100%, 50%) (remember that S:100% means "full color" or "no grayness"). If I want to have a darker red, I just decrease the lightness.

Red, HSL(0, 100%, 50%):

Darker red, HSL(0, 100%, 40%):

Add some "grayness" to make it look even darker:
Darker red with "grayness", HSL(0, 70%, 40%):

(be careful with the Lightness value, it quite quickly becomes very dark (or white), e.g HSL(0, 100%, 20%)):

Anyway. Perhaps you see what I mean when I say that I think this feels more "natural"? When playing around with nuances of colors I think it's easier to work with HSL over RGB.

Let's say I want to have a red pastel nuance. I think it's quite easy to think how I would create it. First value would be 0 degrees: Red) then I'd add some "grayness", and also make the Lightness value quite high. Let's just try with HSL(0, 80%, 80%):

And voilà! First try. I think it looks pretty good.
It's not equally obvious (in my opinion) how that would've been accomplished with RGB. I would've started with Red 255 (255 is max value (a byte, 0xff, is 255)). But then what? I know that RGB(255, 255, 255) is white. So perhaps RGB(255, 180, 180) would be similar?

Ha! That actually looks pretty good as well. Let's say I'm quite good with RGB values as well ;-) But it lacks a bit of that "grayness" I wanted to have. And... I think I know how I would've achieved that as well (just decrease the Red value a bit). But anyway, working with HSL in this way feels like I can express what I want to achieve in a better way.

Wonder what the RGB value of HSL(0, 80%, 80%) is? It's RGB(240, 170, 170). So, I was pretty close :-) And if you still prefer RGB, it's quite easy to convert. Just google for "HSL to RGB converter" or start Chrome developer tools; there you can shift+click (in the "Styles" tab) on a color to switch between the different color modes.

As an aside, there's also HSLA that just adds an extra Alpha value. 0 to 1, where 0 is transparent and 1 is opaque and 0.5 is semi-transparent.

Hope that explains how the HSL color "mode" works. At least it is how I've come to understand it :-)

#yestimates?

Some time ago I wrote a post about the #yestimates hashtag. A quite uncontroversial post...
Lately I have thought about it. Why is it even needed? I think this tweet frames my thinking quite accurately:

@PeterKretzman on this week on #YesEstimates wisdom:
...

— Patricio Martinez (@pmartineznavia) March 21, 2016

(The tweet points out that the "#yestimates camp" has no wisdom (the "..."). As if we are somehow obligated to come up with our own ideas and, if we don't, we should not question things.)

It feels as if it has me down as someone who just loves estimates. I don't. I'd love to not have to estimate (although I see value in estimating. To quote Dave Gordon "the best estimates open a dialog").
#yestimates didn't even exist before there was #noestimates. In that way it's only meta. It has me down as someone promoting or defending estimates as if it even means anything.
One could also claim that #yestimates is equally binary as #noestimates. As if that means anything (see what this is doing?)

To summarize; without #noestimates there wouldn't be #yestimates. Thus, it isn't needed.

The One Button Approach

A great way to start off a blog post is to tell a story about Steve Jobs. So I will do that. Unfortunately I don't think it's true. Not even slightly. I've only heard it as an anecdote. But let's pretend it's true, it's funnier that way. The story goes like this:

Apple was about to implement a "clone DVD" feature. So a group of people got together to specify and sketch out how this clone feature was going to work. They prepared some documentation and some wireframes for the day when Steve Jobs was going to meet them and approve their work. They felt prepared. And the day came. Steve entered the room where the group sat. They were ready to hand him their work and present it to him. But Steve just walked up to the whiteboard and drew a big button that said "Clone DVD". He then said "This is what you are going to build. Good luck!", and then he left the room, leaving the group staring at the whiteboard.

This little story has got me thinking if it (besides not being true) is a good way to think about how one could "slice" stories. Or split the work into something minimum.
Imagine if all your application had, or some part of it, was just a single button. Not likely, but not the point. Work your way backwards from there, ask "Why isn't it possible to just have a single button?"
I like to use stories as just that: stories. Perhaps just some short note on what we want to achieve. Like "Clone DVD". Just a verb and a substantive. Perhaps you could use user stories as well, but they don't really serve as a button, do they?

Let's take another example. Let's say we have a site or other application where one of the things people can do is apply for jobs. You already have a button:

Why won't this suffice? Well, one obvious thing is that a user doesn't even know what job they would apply for. Another is that we, as a receiver, wouldn't know who the applicant is. And there are lots of other things we could do here to make people want to apply for the job. But still, as a first iteration (or sprint), why not keep just the button? Make up all other things meanwhile. This way we can work on making the whole thing work all the way through the process and actually make a fully working job application. Then keep adding the other features when you know it works all the way through.

Or, this single button could work as a starting point for a discussion. As said previously "Why won't a single button do?" then let the discussion flow, but keep in mind "Do we really need this now?". The ultimate goal is to just have that single button. Wouldn't you love this as a user as well? "Clone DVD" and voilà!

What is the point here?


Update:

After I've got some feedback I feel I wanted to update and clarify.
The feedback was that a button feels like a solution. While this actually can be true (as in that we in a first iteration deliver a single button) it isn't the main point. I'd like to emphasize that it probably never will happen that we deliver a single button at any point.
First of all, the button should have the name of some capability (like "Apply for job") and then act as a conversation for what is required for e.g. applying for a job and how it can be achieved in simplest way. But, most likely the end solution will not even have a button named "Apply for job", it might be just "Save" or "Send" or something.

The button is hopefully a good way to trigger an early conversation about the UX (User eXperience: the user interactions, the flow, the design (although not initially the graphical) etc.). The true value of an application happens in the usage - the interaction that happens "between the screen and the chair". An application won't ever be valuable unless someone uses it and it makes that person more productive or creates better quality work or is faster or is just simply happier or whatever. And the best way is to start (and end) in the use. Having a discussion around the UX is also a great way to create shared understanding of what we want to achieve in general. Hopefully we can also see the value in having a UX designer at an early stage. Perhaps start building "paper prototypes" etc. "Visuals" are usually much better at trigger discussions than just plain text.

So please don't mainly see this as a way to deliver a single button. It's just a conversation starter. You can still read my previous point (it's strike trough to note it is the "old" one.):

It's about simplicity. Do not add more than necessary. I think The One Button Approach can help with this. Perhaps you struggle to come up with what do deliver in the first iteration? Just focus on making it work with the use of one single button. Like a vertical slice. And as I've mentioned already, it could also be used in story discussions (or call it "gathering requirements"). The thing to discuss is "Could the user experience just be a single button; 'Do the thing a user wants to achieve'?". And evolve from there, perhaps add more buttons for all the things a user of the application would want to achieve.

Still valid, though it is mostly confusing perhaps..?

"What can I get for..?"

I've been following some discussions on twitter and read in various blog posts about shifting to budgets (http://neilkillick.com/2013/11/25/how-much-will-it-cost-and-when-will-i-get-it/, http://gojko.net/2014/02/24/budget-instead-of-estimating/, http://ronjeffries.com/articles/015-jul/mcconnell/ I've even written some about it as well: http://kodkreator.blogspot.se/2014/08/my-rules-of-estimation.html). It's not really a shift, because I think budgets always exists in one way or another, but the idea seems to be to move to questions like "What can I get for $X?" or "What is possible for $X?" or even "How much are you willing to spend/invest?", "How much is this worth for you?" (or similar).

These are seemingly great questions (approaches) and it may work really well in some situations. But I sense some problems with it as well, let me explain.

In everyday life, this is probably how we buy things. If I'm interested in e.g. a new TV, then "What TV can I get for $X?" is a common, sensible question. And also a good thing to let the TV salesman know. But buying software isn't really the same thing as buying a TV or a car or whatever. As the famous quote goes "Your job isn't to get the requirements right - your job is to change the world" (Jeff Patton). In other words, we're not selling cars - we're selling "dreams" (sounds epic, right?)
I think, perhaps, it's a better analogy to compare buying software to buying art or (even better?) a pet.
If I want a dog, the main question in my head isn't "What kind of a dog can I get for $X?" or "What is a dog worth to me?". And if a dog breeder told me "How much are you willing to spend on a dog?" that would - to me - come off as a pretty weird question to ask. I have "a dream" of owning a Labrador Retriever (just an example, and I think you can compare with art here as well), not just settling with a dog I can afford (although that might be something someone actually would do). I think the same goes for software in many cases. (I wrote an article in a Swedish computer magazine about the analogy of software and pets: "Så får du it att räcka vacker tass" (Swedish)).

In my experience, the "value part" or "what is this worth?" is quite often not really known (or very hard to predict) or perhaps not even really interesting. Of course, getting to know these things might be worthwhile, and sometimes (often?) it's actually really good to find out/explore these figures. But again, the most interesting question when buying pet/art/software often isn't "What is this worth (in $) to me?". Thus, the first question isn't "What are you willing to spend?" (the car salesman approach). The first question to ask is "What is your 'dream'?".

Then, of course, the inevitable question will come: "What will this cost me?" and whatever we respond, the response to that most likely(?) will be "I can't spend that much!". But what if someone doesn't? Wouldn't you rather have someone having their "dream" fulfilled (or as close as we can get) over getting to know, upfront, what they are willing to spend on something? (I'm stretching the word "dream" here, I know, but I think you get it). And to be honest, I believe the question: "What are you willing to spend?" (or similar) most likely will make you come off as a "car salesman". Not a good start (if you start with that question).

Of course, in business, the difference is that we want to make money. Art/pets won't (not usually, at least) let you do that - and it's (usually) not the goal either. But again, that question is quite often really hard to know; "How will this make me (a lot of) money?" And here I believe that moving to validating assumptions (instead) is a good approach. Like: "How can I grow a sustainable business out of this?" (read more in The Lean Startup. Although there are things to consider as well: Lean Start-Up, and How It Almost Killed Our Company). This is another topic.

Another quite common thing is that some things "must" be done, for various reasons (e.g. regulatory), and then the question: "How much can I get for $X?" isn't relevant either.

Also worth considering is that being explicit with your budget might not be that great (in a "low trust environment"?):

@henebb A friend's small firm just got quoted an outrageous sum for building a really basic WordPress site. 1/2 @KirstenMinshall

— Peter Kretzman (@PeterKretzman) July 31, 2015

@henebb How'd that happen? The CEO inadvertently let slip what the budget was (they'd had no idea of probable cost). 2/2 @KirstenMinshall

— Peter Kretzman (@PeterKretzman) July 31, 2015

My thoughts on "Agile for Humans" podcast

I recently listened to a podcast on the topic of #NoEstimates on the "Agile For Humans" podcast (follow the link for the podcast and the participants).

Overall, I think it was a great podcast! Some good points were raised and the discussions were interesting. It left me with some thoughts I'd like to share here. And I took some quick notes while listening, so I'll share them here.

First of all, on the topic of estimates, I think the discussions were very developer-centered. And there's nothing wrong or strange with that, since the participants are all software developer coaches and similar. But when it comes to the need for and use of estimates, it's not just about the software developers. So, I would have liked to hear a discussion more from a "business" perspective. That's the overall feeling I got.

There was a discussion about the name/hashtag "no estimates". The name was practically praised. Sure, it was briefly mentioned that the name was "controversial", etc. But I missed hearing a discussion of all the "bad" things that come out of it, as I see it: the binary thinking, false dichotomies, Sturgeon's law, that estimates are lies, waste, etc. Things that I constantly see on the topic. Little to none of that was covered. I would have liked to hear some thoughts about how this could be addressed.

And, sure enough. JB Rainsberger soon started to talk about that we were "brainwashed" (yes, he used that word). I actually think that's what the name/hashtag does to you - words matter! From here, the rest of the podcast kind of lost a lot of credibility to me, because no one confronted this. Why was this such a big turnoff for me? I see it like this:

Why do we use the word "brainwashed" and estimates in the same sentence? That's probably the most interesting question of all. Why do we see it like that? Am I really brainwashed with estimates? I suppose if I were, I wouldn't know, right? But am I brainwashed with using seat belts as well? Tooth brushing? Using knives? Salaries? Math? Eating? Does that sound silly? Yes it does. But why does no one see it as silly when calling use of estimates "brainwashing"? I hear you say "It's not the same thing". No it isn't, but I can mention hundreds, if not thousands of times per day when I estimate. Implicitly or explicitly. It can happen in the blink of an eye. Just count the number of times per day you check what time it is. Some might claim that it isn't estimating in a "software sense". Sure. But my point here is to show how natural and ubiquitous estimates are. Just like eating, knives or math. And why do we see the use of them as "brainwashed" just because it relates to building software? I wonder.

As Geert Bollen so nicely put it in a tweet:

you have me down as "pro-estimates", supposing that even means anything. Isn't it silly what this does to us?

Further thoughts. The topic of "How late were we?" was discussed. And it was mentioned that the need to know "How late were we?" wasn't really useful. I'd say yes, it's useful. It's called: learning. If I thought that something would take 10 hours but ended up at 5 or 15 (if the scope didn't change), there's learning there. I agree, there's not much use in knowing that for the specific situation, but learning for the future. "Last time I missed taking this thing into account. I won't miss that again." Or anything. If you have estimated, not learning from the outcome is ignoring the learning opportunity.

More thoughts. "How we always have done it" was discussed. It is a common fallacy that "how we've always done it" shouldn't matter. Often it is connected with "Things aren't the same now as it were back then". Sure. But perhaps we just need to learn why we use the approaches we do? Rather than revolt and redo learning. Sure, sometimes we need to rethink some practices because times change. But things are also how they are because sometimes it's been tested and proven to be a great way to do things. We can actually learn, we don't have to repeat history.

Lot of criticism there :) As I said in the beginning, despite these things, I really enjoyed listening to the podcast and it was really helpful and learning for me. Go ahead and listen to it!

Minimum Viable Product = Maximum Expensive Learning?

The title is quite provocative... Don't worry, I'll explain.

The reason for this post is that I think the concept of the MVP (Minimum Viable Product, as defined in The Lean Startup by Eric Ries - a great book, read it if you haven't) is, in my opinion, a bit misunderstood. I'd claim that validating your business assumptions with software is a very expensive alternative, and hence your least desirable alternative. But MVP is not bound to building software. A product is not only software. One definition of "product" is: something that is the result of a process. (Merriam-Webster). Thus, the result - the outcome - of something you do, might be seen as a product.

Let me explain my thoughts.

One image that floats around on twitter and in various presentations is this image (I think it's originally created by Henrik Kniberg for Spotify):

(Image source: http://www.uxbooth.com)

I know. It's just a metaphor, just an image. And it shouldn't be overinterpreted. But that's actually exactly what I'm going to do now :) Because I think it works for discussing some things, explaining my thoughts.

I'm not going to dwell on the fact that the top steps in the image is actually the wrong, however you'd approach anything. So, let me start by explaining the good parts of this image, and how I think it should be interpreted.

The image is to be seen as a way to start off small. Not building everything upfront. But better; iterate your way to the "final" (nothing is ever "final", right? But it fits the image) version. I assume, myself, that the assumption in the image is that someone needs the capability (it's always about capabilities, that's what business are working for - having a new (or improved) capability, e.g. the capability to fill a market need etc.) of going from point A to point B. Later on we discover more stuff; that it would be great to have a handle to hold on to. Then later the faster bike etc. And finally we end up with a car. And who knows what the next step is...

All great.

But.

I also see potential problems here. This might actually be a very expensive approach. How?

Because software is an expensive way of iterating to a needed capability. Even if building software today is much cheaper than it was some time ago, most capabilities are not cheap enough.
And if your customers really needs cars - all the other steps were actually waste. And. You might end up in a "trap" of not ending up at that car at all.

Because, building a skateboard is not that cheap actually (if looking at it from a software perspective). Even if it's just a month or so for a couple of developers, that's still quite expensive. Of course, in some domains it might perhaps not be that much money, compared to other things, but still; not cheap. Then add all the other steps, the kickbike, the bike, the motorcycle. Expensive. Very. If compared to: asking the right questions. Getting to know your customers and market in other ways than through software. In this, simple, case all you'd have to do is ask a couple of quick questions:
- Where do you plan on going?
- Shopping, vacations, skiing etc.
- How fast would you like to get there?
- Well... couple of hours as a maximum.
- Do you often need luggage?
- Yes, like skies, groceries etc.
- How many people do you want to bring?
- Usually the entire family.
- Etc...
Only one option is now left; the car. Perhaps some other options could've been a horse with a carriage or a helicopter or something. But a rough idea of the cost and/or something else would easily solve that problem.

This is a much cheaper approach than to build all the intermediate steps in between. This is of course not always possible (and where the metaphor/image falls short) and then building these intermediate products is perhaps your only alternative.

But. There's another possible problem. About gathering information, gaining "knowledge", learning. The wrong kind.

In a more complex scenario, gathering data and learning from it is not that obvious. Using the image as an analogy, if we build and deliver skateboards to our customers. We might end up focusing on: people loving skateboards. Thus, we might end up getting feedback about how to improve the ball bearings or how to build a better shape on the board for various tricks etc. And we might lose the focus on our real valuable customers. And we might even lose those other customers (when improving on the "wrong" things) - the ones we really would like to target - those needing cars.

Thus, sometimes (or perhaps even most often?) the cheapest way to learn about your market and customers is to actually get out there. Get to know them. Marketing research and similar. Getting to know them by going straight for building and shipping software is not a cheap approach.

But, when eventually building that capability you need. Do not plan all the details up-front. Iterate.

Getting to know the "right" capability and iterating the details is cheaper than iterating your way to the "right" capability by building stuff. This goes against the idea of "The Lean Startup". But remember, Eric Ries writes in the book that the context is: extreme uncertainty. Things aren't always extremely uncertain. And if it actually is? Well go for it. But if you can ask a couple of questions (or similar activities) and gain similar knowledge - that's your option. Or, it's actually not a dichotomy. Do both. When needed. You know, that context stuff...

To finish off this post. I think this image is a better example on the evolution of an idea, as I see it:

(Image source: http://uxpodcast.com)

This post in inspired by the story here: http://www.infoq.com/articles/lean-startup-killed

"Estimates are waste"

I quite often hear "Estimates are waste" or "They aren't adding value" or "If estimates were valuable, why not do more of them? Why not only do them?" etc.
Quite often it's visualized on a linear "graph" like activities in a similar way:

The red areas are time spent doing non-value adding activities ("waste") and green areas are activities that bring value (e.g "doing the work", like writing code etc). It's quite common to put estimates in the red areas.

This might be all reasonable. Because sure, who would like to only do estimates all the time? And if not, aren't they by definition "waste"?

Is that so?

I don't see it that way. Or I misunderstand. I see it like this; Having some time to stop for a while. Pausing, reflecting. Try to see where we are. Try to see if there's somewhere (else) we should be going. That is: making (new) decisions based on the current situation. Is that waste? Of course, if we spend most of our time there, it's probably not that valuable. And keeping those periods as short as possible is of course an aim.

If we instead of a linear graph had a 2-dimensional graph. Even if we removed all "waste", how would we know we actually created value? It could just as well look like this:

(It could of course point upwards as well. But I'd claim it probably won't).

But if we pause and reflect (to make decisions), hopefully the graph might look like this:

Even if "the value" stalls for periods of time, in the long run it would probably point upwards.

This is all very simplified, I know. But it's aimed at making a point.

Sure, estimating might in the short term seem like waste of time because we're actually not doing any real work. And it doesn't guarantee value, it doesn't even really affect the outcome. That is true. But in the long run - it still brings value.

Take care of your teeth

This is metaphor. It might be a silly metaphor. But if one thinks about it, it's actually quite close. At least easy to relate to estimates (for me anyway).
I feel that taking care of my teeth is a quite boring activity. It's not value-adding at all to me. I'd rather do without actually. In short, it's waste of my time. You know; if it where valuable I would like to brush my teeth all day long, right?

But still. I realize that in the long run, it's highly valuable. Spending some time each day to take care of my teeth will bring me lots of value - even if I can't see it when actually doing it. I still wouldn't want to do it all day long, and it doesn't guarantee healthy teeth. But I'm very sure that not taking care of my teeth is a sure way to make them worse (in the end).

Could we find a way to have healthy teeth without taking care of them? In the future, who knows? That would be great! But this is where the metaphor falls apart. We need to make decisions once in a while (quite often actually). I think we all agree on that. And estimating is what we use when making decisions.

Let me quote the dictionary definition of deciding (Merriam Webster):

: to make a choice about (something) : to choose (something) after thinking about it

: to choose whether or not to believe (something) after thinking about it : to reach a conclusion about (something) because of evidence

: to cause (something) to end in a particular way : to determine what the result of (something) will be

To make a decision we weigh pros and cons. The pros might be real monetary value or just emotional value. The cons are most often the cost of doing something (and possibly when we could get it), or an emotion that we actually don't want to do it (not that common). Those pros and cons are nothing but: estimates.

The #Yestimates hashtag

I didn't invent this hashtag, I heard it in a twitter conversation some time ago. I'm dishonestly stealing the name. Let me state how I look at it. This is just a draft, I might change it later on, but it's a start at least. I think of this hashtag as the more "positive" version of #NoEstimates. I guess they mean the same thing actually, but I feel we need a more "positive" version of it. By "positive" I mean that #NoEstimates can be positive as well, just that some (including myself) might see it as a bit like saying "no", and to me that sounds a bit "negative", but that's just an opinion.

Here it goes:

"Yes, we do estimates! We see it as a way to help our customers make decisions in their hard and difficult situation where they have to make those tough decisions.
Yes, we do everything we can to be transparent and keep an honest conversation and we try to help our customers do the same thing for us.
Yes, we'd like to help them communicate their expectations (or constraints) and we will communicate how we look at things as well.
Yes, we'd like to help them discover where there might be (even more?) value.
Yes, we'd like to help them discover the value by doing the least effort possible.
Yes, we'd like to help them validate their hypotheses.
Yes, we'd like to help them make as quick decision as possible, since delaying value also has a cost.
This way we try to fight all possible dysfunctions that seem so common in the name of estimates."

Some words about decisions

I think a definition is appropriate here. A definition of what we mean by "making a decision".
This is how I define that:

Making a decision means choosing among choices. Each choice have a benefit and a cost. It doesn't have to be a clear monetary benefit, but hopefully it is. Cost is usually always clear monetary in the end. Deciding means "weighing" the available choices and picking one or more of them, or none. In other words "weighing" the different benefits and costs among the choices. That "weighing" is in itself a form of estimating.

That's basically it. Please feel free to help by suggesting improvements/changes or if things needs clarification.

Not estimating can also be problematic

Let me start by saying that I'm all for trying things. Try. Evaluate. Learn. When you've read this post you'll forget I have said this, maybe because I'm contradicting myself. I don't know.

Anyway, I'll tell you a story. I once worked as a software developer at a product company. We developed a hardware firewall/ADSL-modem. I didn't work as a consultant/contractor back then. It was a small company, like 20 people. Around 5-7 software developers working on the product.

Anyway, I almost never estimated the work I was planned to do. It was like "We really need to get this next thing done, please make sure it gets done" (not exactly of course, and in a rather friendly tone, actually). I admit, it sometimes felt kind of nice back then. But it wasn't always good. Because there still were expectations (and that is kind of why my opinion is that "no estimates" doesn't really exist). And when things took a little bit longer than someone (somehow) expected, it felt even worse. Because I "didn't meet the expectations". And I was pretty junior back then. And also because I hadn't really had the chance to say or claim anything about what I thought the effort was. I would probably have felt bad even if I'd had the chance (or not, if my claim about the effort had been close to correct). But not estimating didn't help either.

I don't know if we really were doing #NoEstimates? Probably not (because there were estimates at some level in the end after all). But I did not estimate most of the work I did, so I guess it kind of counts..?

So, if someone is planning on letting go of estimates. I'd advice don't just try it. Make sure everyone is on board with that decision. Someone might actually not like that decision. I guess that's kind of obvious, though. And no one is saying that you shouldn't do that. It's just an advice, or perhaps something to think about at least.

I guess my point is that if "dysfunctions" isn't solved, letting go of estimates might perhaps solve some problems, but you might also create other ones. And also, if you don't estimate, someone else probably will (for you), and that might feel even worse (for some). So, I don't know, probably the entire organization needs to be on board with the decision? I don't really know, it's just my experience. Guess the goal is to always keep a close feedback loop, but I'm not sure that it will remove the "expectations" of "the next thing that really needs to get done"? Or perhaps the solution is to make sure everyone is on board with not having expectations of anything? Maybe the solution is to always say: "I will have something of value to show you tomorrow"? Will that somehow remove the expectations? Or maybe the solution is to say something like "Sit here and help me make sure it gets done". Is that possible? Maybe. Maybe not. Or maybe something completely else?

Please try for yourself! I guess I'm a bit reluctant to try again myself though (coward!). But hey, times changes! :-)

Estimates, decisions, prioritization, inventories

Ideas

In my personal life (or in any organization) ideas are like a flow of things. (This is nothing new for people who knows about lean etc). I see it like this:
I (or an organization for that matter) probably have a lot of ideas, or "things", of what I want to do. It's like I have an inventory of ideas/things. That's great. I hope? (I don't see anything bad with it at least).
The next step in the flow is the "materialization" of those ideas/things. Like: actually working on it, or doing some planning on what needs to be done.
And the final step is the outcome, or the idea/thing actually materialized.
That's basically how I view the flow of things in my life (and even how I see it in organizations as well).
Ideas/things comes at different sizes. I should switch tyres on my car, I should take it to service, I should put up new curtains at home, paint a room, remodel my kitchen, etc etc. One can easily correlate this with ideas/things in an organization (at probably all levels) as well.
But the thing is, I only have so much time to do all these things. Or I can't afford to "add resources" by hiring people who can help me.

Priorities, decisions

I don't need to dwell on this. I need to do these things, you need to do these things, organizations need to do this. We have limited resources/time, thus we need to make decisions, prioritize. And that's good, I'll get to that.
But let's say I need help because I'm not quite sure how to decide/prioritize. The value part is quite given, even though it might be hard to put numbers on them. But I'm not sure the effort of doing some things. I need help.
However someone gives me an idea of that effort/cost/whatever, if they judge, forecast, slice, whatever. I will treat it as an estimate. Because we can't know exactly, and unexpected things always happen.

Being reasonable

When unexpected things happen, I might question if those things wasn't possible to somehow foresee, or why not having some margin for such things. (Usually, in contracts, there are disclaimers for really unexpected things). But if there's a good reason for it, I'll buy that. That's not a big deal. "Shit happens", right? I'll somehow raise more money or stall everything. What can I do? Was it a bad decision? No. Why dwell on that? Let's do what we can right now, based on the information we now have. We made a decision based on the information we had at that moment. That's great! Be positive. I'm glad we at least started something. Now let's finish it. And learn til next time.
Would I have made another decision if I had knew? Maybe. Maybe not. But why dwell on that? It is what it is. Look ahead. Stay positive. And learn!

Feedback

Hopefully some progress will be reported. So I know ahead of time how things are going. So I can steer and adjust and coordinate. Even with the other things I want to do. Best thing is to actually show me progress, not just tell me progress. If I get to see small pieces of value being delivered and ready, I might even start using some of them. I might actually say "Stop, I think that's enough" (who knows?). And if you show me progress I would probably stop asking for estimates during this materialization, I can obviously just look at the progress and see for myself we're on track or not.

Inventory

Let's say I don't want to have an inventory of ideas, or that I want to drastically decrease it. I'd have to get more resources (or time, however that is done?) to get them done. That's fine. But you know what I think will happen? I will just have even more ideas. And we're back on square one. And that's great! It's called: growing.
Or I could just delete most, or all ideas. But that doesn't feel right.
Or I could start working on all ideas/things (and have all of them in the "materialization phase"). But then I'll probably never really finish any of them either... You know - limit WIP.

"Materialization phase"

When an idea/thing is in this "step/phase", I don't really care that much about other things than progress, as I've said earlier.
If the one I'm hiring doesn't feel it's valuable - in their process - to use estimates, that's fine. If they want to not do sprints or sprint planning or planning poker, story points, or if they want to slice or forecast or whatever, I really don't care that much. (Even though I might be interested in how they work). And this is probably where #NoEstimates have its place?
But as long as I, somehow, have an idea of how we're progressing and/or if it seems like we need to plan (or do) something differently, I'm happy.

When someone reports that progress, it's an estimate to me (because they can't possibly tell me it's fact. But if it is - great!). Thanks for those estimates! (Sorry if I've never said that, I should). I feel that's valuable to me.

Bottom line

I think this is kind of basic stuff.
Do I want to change how this works? I don't see any reasons.
Is it a smell of possible dysfunctions? I can't actually sniff any.
In fact I think it's part of living. Both personally and as an organization.

Love! Live! Fight! Learn!

And how do I look upon #NoEstimates?
It's about the dysfunctions associated with estimates. It's not about throwing babies out with the bathwater.
Could it have a better name? Hell, yeah! :-)
But it's like some kinds of "journalism", you have to make some drama to get attention to a topic. One can have lots of opinions of that. Mine is probably as good as yours :-)

ApprovalTests part II (or things I didn't show at swetugg)

I gave a talk at swetugg about ApprovalTests. Swetugg is a conference arranged by Sweden .Net User Group. Thanks a lot for a great conference and all the work you put in to it!

The presentation was recorded so I'll put up the link to that video when it's available. It's in Swedish though.

Anyway, my talk and demo on ApprovalTests was merely a teaser to the tool. So I thought I was going to show some other pretty neat things you can do with it in this post. Especially how it can be used on legacy code. If you haven't seen ApprovalTests before, this post can perhaps be a little bit difficult to understand, it's mostly a follow-up on my talk. But you can watch some introduction to ApprovalTests on the site: http://approvaltests.sourceforge.net/

Nothing of what I show here is anything new, it can be seen and downloaded from other places. This is just my view on it.

Testing Console Application

There's a code kata called "Gilded Rose". The code can be downloaded here: https://github.com/NotMyself/GildedRose

But it can be any Console Application you have or any other program that might log output to some logger (most loggers support Depency Injection, and thus you can grab the output from it from your test). But let's use the Gilded Rose Program.

So, lets start by creating the gilded rose program. Copy the code from the link above in a new class, call it GildedRose.cs or something. Then also download the Program.cs from the link above.

If you run the program you'll see it will render some output to the console. But let's see what we can do instead.

Create a new test fixture class (I use xUnit, but you can use whatever you like). Add the UseReporter attribute to your test fixture (you have to grab ApprovalTests from nuget first of course). Then we can redirect the output to our own StringWriter, like this (sorry about using pictures/screen caps, but I want to show what it really looks like on my machine):

When we run the test, we will now have the output in our "received" file:

Let's approve that. This is production code so we know it works (well... it could contain bugs of course, but that's another story. We don't want to fix those bugs now anyway).

(Another pretty good thing with logging is that we can always add more. Logging doesn't (shouldn't?) break things, just bring you more information on what happens).

Great! Now we can start refactoring our code! Let's - just for fun - try and move this if-statement (we might think that's a good refactoring step?) and see if we break anything:

What happens? Let's run the test:

Nope, that broke it. I like how we easily can spot the difference using the difftool. But we really don't care what actually broke, we just care that it actually did.

Combination Tests, or "Locking code"

This is another pretty neat thing. I've stolen this directly from Llewellyn Falco (modified some, hope it's ok...) There's a video on this, but I'll show it as screen dumps here.

First, download my version of MovieNight.cs from this gist: https://gist.github.com/henebb/a4c3ac25399858234e3f

Create a new test fixture class and first write this:

If you run the test you will get an output that says: "Mr. Henrik should watch A Most Wanted Man, Sex Tape," (thus I will have time to watch "A Most Wanted Man" and "Sex Tape" during my 3.5 hour movie night).

But this doesn't really feel like we've covered much. And yes, if we start a code coverage tool (like the built in Visual Studio: Test > Analyze Code Coverage) we see that all code is not covered.

But we can modify our approval and use what is called a combination approval. It looks like this. Note how we have to change our variables to arrays (all combinations we want to try) and how we moved the function call to our CombinationApprovals:

If we run the test, we know get this output (excerpt screen dump):

The output will have 300 rows (one for each combination). And if we look at the code coverage we can now see we've covered everything. We can now approve this output and thus "lock" it. And we can refactor the code as we please.

That's two more powerful things you can use ApprovalTests for. If you download ApprovalTests you can explore some other nice reporters and approvers you can use for your specific needs.

Don't Do Stupid Things On Purpose - Is it stupid?

"DDSTOP - Don't Do Stupid On Purpose". I came across this by Mr Glen B. Alleman on twitter. You can read some of what he's written on the topic here: http://herdingcats.typepad.com/my_weblog/2014/05/ddstop.html
It's aimed at the #NoEstimates movement. But DDSTOP doesn't seem to originate from that (if you read the post, at least).

DDSTOP sounds good at a first glance. We should actually not do stupid things on purpose. And sometimes it kind of feels like we do, at least I feel that. It happened today actually. We were requested to estimate a change request that wasn't really thought through. At least we had quite low confidence in giving a credible estimate on the effort required. So for a while we talked about how we could give an estimate and what it should be at. Then it struck me; "Wait a minute! Customer collaboration! Let's book a meeting instead and go through this together with them. Why not even let them hear what we think, directly, instead of 'delivering' the estimate." Everyone in the team agreed. Meeting is now booked. To be continued... :-) I call this approach "no estimates", because we made a decision without estimates - we decided to *not* provide an estimate, i.e. "no estimates". We *will* give an estimate. And that leaves me with: "no estimates" is not "never estimate". And we also avoided a "misuse" of them; we avoided a "guesstimate". And doing the estimate in collaboration with customer at the same time as we look at what is to be done, is also much better, in my opinion. But now I'm really off-topic...

I don't really like DDSTOP as an approach or mindset or whatever it is. I feel it has a "blame" tone. Like: "I/You/He/She did a stupid thing, shame on me/you/him/her!". And even if we don't actually say that, we might implicitly set a culture of not wanting to try new stuff; "Oh, I don't dare to try/do this, it might be stupid, someone might even interpret it as me being stupid on purpose... That banner over there says that and all, oh well...". In my opinion, that is not a culture we should foster. In fact, quite the contrary.

I claim we actually *should* do stupid things! It reminds me of a movie quote I love. From The Three Musketeers. D'Artagnan is about to leave his parents to meet the world and seek adventures:

D'Artagnan's Father: There's one more piece of advice.

D'Artagnan: I know, I know. Don't get into any trouble.

D'Artagnan's Father: Wrong. Get into trouble. Make mistakes. Fight, love, live. And remember, always, you're a Gascon and our son. Now go. Go.

(http://www.imdb.com/title/tt1509767/quotes?item=qt1793828)

A wonderful advice!

My take: Try! Fail! Learn! Be creative! Ignore stupid!

And when someone makes an obvious stupid thing, shame on *us* (as a system or organization) for allowing it to happen. See it as something positive! A chance of learning - and improvement - in the organization. And not just wag it off as "that was just X doing a stupid thing, and furthermore on purpose". There is no learning and improvement in that mindset (or whatever it is).

Taking the example from Glen's blog above; a foam filler was used without reading the directions on its applicable.

"Stupid! And on purpose; not reading the directions."

Well I'd say: "Shame on *us* for not educating people on how to use the foam filler instead, and other safety equipment. Maybe we should even arrange other courses on how to perform CPR as well?"

It's "culturally" important to not put any blame on employees. Not even a slight indication that we do. Not even open up for misinterpretation of the concept that might lead in that direction (I obviously might have misinterpreted DDSTOP. But if I have, others will as well). Because it might lessen (or even kill?) the company's most precious recourses; creativity, innovation and learning.

I think that banner was actually a rather bad idea. I think DDSTOP as a way of thinking is a bad idea. Not stupid though... ;-)

#NoEstimates is not #NeverEstimate - my take

This is not a true story, I'm sorry. But I really think this is an approach a company could use. And there are probably companies out there that are doing this, daily. I just want to give an example to state my view.

If you follow the #NoEstimates discussion you might come across the statement that "#NoEstimates != #NeverEstimate" ("!=" is a programmatic operator (in some languages) that means "not equal to"). But what does that mean? In twitter discussions (where most of the discussions happen) it kind of tends to become "defend your point stances" like discussions. What I mean is; it feels like it becomes a "never estimate" vs "always estimate" discussion - even though we say #NoEstimates actually doesn't mean "never estimate" (or that opponents actually thinks that "always estimate" is something great too?).

This is unfortunate in my opinion. It muddles the real topic.

So, to give some "credibility" to my points - because I believe in the ideas/thoughts behind #NoEstimates - I'm going to give an example of what "it doesn't mean #NeverEstimate" means, in my opinion.

These thoughts comes from after reading the book "The Lean Startup" by Eric Ries (http://theleanstartup.com/). Those of you who have read the book will recognise the idea I'm presenting and those of you that haven't; read it! It also has some big influences from the "Impact Mapping" idea (http://impactmapping.org/) - read that book too, if you haven't.

An Example

Let's say I have a customer that wants to "update the design of their web site". There's nothing wrong with that, right? Now they want to know what that will cost and when it can be expected to be finished. They might crank in some additional changes when they are at it, or not. Doesn't really matter here.

Now what happens? Well, first they have to contact some web designer company that have to look at this and give an estimated cost of what a "design update" might cost. When that's done someone has to implement the design into the real web site ("real code"). That's probably another company who does that - they need to give an estimate of cost for the update as well.

Nothing strange going on here. The project might even (unusually) be on time/budget in this example as well. All is fine. All companies involved might even celebrate the "Web Site Design Update" project. A true success! And it is. ...or is it?

I mean, in a project sense it is. We didn't break budget and we released on time. That *is* great. But still... all that time and money spent - was it worth it?

I guess no one really knows.

Because what is the hypothesis? What assumptions about our web site user's behavior have we made? What is it we want to learn about them and their behaviors that will give us a competitive advantage? In what way will they help us earn/save money? And - very important - how can we measure that our hypothesis is correct or not?

Well, we do it by making experiments. Trying/testing our hypothesis. Thinking small. Focusing on how we can gain (measure) that knowledge as cheap and fast as possible - by cutting all waste, that is; remove everything that doesn't contribute to the learning we seek. Doing minimal effort to get to that knowledge.

How can we apply this here?

Well, what's the hypothesis about updating the web site design. Well, that depends on what the company do. But let's pretend that the main purpose of the web site is to steer the visitors to a certain place or doing something special; like "becoming an applicant for X" (there can be many different purposes of a website that gives a company real value - that is $$$, in the end).

I guess the hypothesis then becomes: "If we update the design, more visitors will apply for X".

Now, that becomes: "How can we prove this assumption is correct?" "What's the minimum thing we can do to test it, and how can we measure that what we do is the actually affecting those metrics?"

On a web site, let's do an "A/B test". That is, let half of (or maybe a specific set of) users see and use the new design and let others see the old one. Try it on just the start page or a specific flow. And while having this focus on "experiment", maybe we should look at improving the user experience as well? An idea we might not have come up with at all if we just focused on "updating the design"..?

The outcome of this might be that the new design had no, or little, impact at all on the behavior of our customers/visitors.

Then an update of the *entire* site might not be what we should spend our money on. This "failure" (hypothesis turned out to be incorrect) is great! We have *learned* something about our customers and their behaviors. We can use that to our advantage. "What more can we learn!"

But also. We haven't spend a lot of time and money on all the estimates and the time and money on updating the entire site - which would have proven to be a "failure" in the end anyway; but a costly failure, a late failure.

But - now to the point - there are estimates here (maybe it doesn't really have to..?)

We have to give some judgment on how much to spend (estimate) and how long it will take (estimate) to perform this experiment, because an experiment isn't free :-). But, I rather give an estimate under these conditions. And it's less "sensitive" if a "1 month" estimated cost is "off" then if a "6 months" estimate is.

And what if the assumption turned out to be right; the new design made a great impact on e.g. the number of applicants? Well, either we estimate the cost of updating the rest of the web site, or we iterate with next assumption or whatever we want to learn next. 

If we choose to update the entire site we now have a much better certainty on the effort of doing so, since we have already done some.

But by choosing to do this in small batches there are other benefits as well. Instead of having the design team hand-off their designs to the next team and move on with their next project - we work together. And we will save time and money! Why? Because if the design team move on with another project they might have to be interrupted in that project when the other team have questions on how to implement the design or problems occur. Those interruptions can be costly and cause delays - and most certainly if these interruptions becomes "the norm". 

To quote Peter Drucker (I'm not sure it was actually he who said it, but it's attributed to him):

"There is nothing so useless as doing efficiently that which should not be done at all."

My Rules of Estimation

In this post I'm just going to write down some of the things I've found about estimates. That is: when estimates fill a purpose (some say they *always* do, and I'm more into the ideas of #NoEstimates to lessen the dependency on estimates... But this is off topic in this post).

These are things that apply to me and the situation and context I'm in (types of customers I have, size of projects etc). I'm not saying these are universal truths or are general guidelines. It's merely my opinions. There's no real news in here either, it's rather old stuff. I just want to share them and keep this as a reminder to my future self.

I won't go into lots of details on these items, just list them as shorter notes. I might revisit these items later on and update them.

1. Estimate or commitment?
   Someone buying software (or anything really) aren't that interested in estimates. They seek commitment (promises). So they are probably not asking for estimates, but for a commitment. But don't confuse estimates with commitments, two different things and requires different approaches. Here's a metaphor on the difference I like (by Mike Cohn): http://mountaingoatsoftware.com/blog/separate-estimating-from-committing
2. Find out the budget
   It's there for sure. Then try to discuss what can be built for that amount of money. If they don't want to tell their budget (it's a trust issue really but...) it's rather easy to find it out anyway; Tell them something clearly too high and work your way down ;-)
3. Find out the "roughness"
   Maybe "This year" is okay as an answer? Or "Less than a month"? Don't just assume they want "estimates as you usually do". Probably they don't need precise answers - you just provide it anyway - they need accurate answers (I'll get to this soon). But, if they really seek a precise answer it's a sign of something that is probably a bit risky and you should look out for it.
4. Find out the value
   If the cost is to be estimated, the value must also be estimated. Calculate the Return Of Investment (ROI). If value and cost is close (low ROI value), it's probably time to cut scope. It's a risk anyway, and it should be discussed with customer. Sometimes this can reveal the level of "roughness" on the cost estimates as well (item 3). Maybe cost isn't that relevant (high ROI value)?
   Value always trumps cost!
   Sometimes they can't (or won't - a sign of trust issue?) estimate the value. If so, one could really ask why this project should be carried out at all..? Anyway, go back to item 2 and you probably have the value somewhere...
5. Estimate in collaboration
   Who says we can't estimate together? I've written a blog post that touches that subject: http://kodkreator.blogspot.se/2014/03/what-noestimates-has-taught-me.html
   "Customer collaboration" right? I see no problem in this if there is trust (and maybe even if there isn't?). A customer might have much valuable information to provide when estimating. At least they will learn - and feel they are a part of and/or have opinions about - the estimation process you have and the estimates you come up with. Great value, in my opinion. They might claim it's a waste of their time. But I think it can be very valuable for them. We have nothing to hide, right?
   If it's not possible to estimate in collaboration at least don't present your estimate as a "truth" or "this is how it's going to be". Collaborate! Help. Guide. Tell where there are uncertainties or where you feel there should be margins. Tell them some margins might be used, some don't. It's like inviting people for dinner - you want people to be satisfied so you tend to buy too much food, and it's okay. Discuss risks. Read more here: http://www.leadingagile.com/2014/02/use-agile-build-next-home/
6. Confidence level
   Try to provide your estimates with a confidence level. This is actually not used at all where I work, but claimed to be utterly insane not to in other domains.
   Create a graph (usually in a Weibull distribution form), it doesn't have to take much time to create or use maths. Just use your "best bet" and then min-max values and create a distribution curve by free hand, it's enough to give you an overview of your initial "best bet" estimate. And discuss what you should "commit" to.
7. Don't be an optimist!
   There might be a good reason for you to be... But usually - and especially with estimates - there might not be a reason to be. Ask yourself: "Who will benefit from us being optimistic here and not be pessimistic instead?" There might be reasons, as I said, but usually not. One reason I can come up with is if there is no true "benefit" from doing a software project, like updating to a new version of some CMS or something. But one could really ask why we should do it, if there is no clear "value" in doing it.
   Read some of what I've written here: http://kodkreator.blogspot.se/2012/01/my-estimates-are-too-optimistic.html But always remember "Hofstadter's law": http://en.wikipedia.org/wiki/Hofstadter's_law
8. Preciseness is not accuracy! 
   For instance: "952 hours" is not a good estimate. If anything it might clearly show that it's a sum from a number of other estimates. But, please, stop provide estimates like that!
   It's better to be correct than precise. It's better to say "By the end of this year" or "In august" than to say "2 August". Let the specific date be decided later on. Maybe you don't have to present the exact number of hours you estimated at all? Maybe you even shouldn't? Customer is probably only interested in what it's going to cost and roughly when to expect it.
9. Always keep a deadline - however it was set!
   Okay, this is not true. There might be good reasons to postpone a deadline, but it's a provocative title right :-)
   Anyway, I actually thinks deadlines - often - should be held. Even if they are off. Postponing deadlines can be discouraging for both the team and your customer. And it always feels good to make the "finish line". And you probably have *something* to deploy.
   What do you do? Trim the tail! Read more here: http://www.crosstalkonline.org/storage/issue-archives/2014/201407/201407-Cockburn.pdf
10. Say No (or: don't always say Yes)!
    Even if I like item 9 it doesn't always work (as I've said). There's still something else you should keep doing during project: say "No". Or actually - and better explained - don't always say "Yes!" to everything. If things change (and they will) we have to say "This will make the initial estimate a bit obsolete" and re-estimate (if needed). There's nothing wrong (in my opinion) to re-estimate if things change, even small things might affect schedule (and surely if you provide those precise estimates I talked about). Read more here: http://www.mountaingoatsoftware.com/blog/to-re-estimate-or-not-that-is-the-question
    Real user input is always good and should be encouraged. But all changes comes at a price (when you drive with estimates (or you could think about trying to lessen the estimate driving i.e. #NoEstimates. Damn! Now I'm there again. Sorry.)).
11. Intervals
    Presenting estimates as intervals is okay. And sometimes even preferable to e.g. mark some kind of uncertainty or confidence. It will keep your back safe at least :-)
    But remember that some customers might tend to hear the lower interval while you tend to hear the higher. And you run a risk that the lower value will start traveling in the organisation... (dysfunctional, yes, but there's always a risk).
12. Focus on iterations
    Do everything you can to always try to have something "usable" to deliver. Don't build (arbitrary) parts of the system/application but ask instead: "If we abort this project after the next sprint/iteration and deliver - what will it look like then?" That is, focus on the most important things first.
    Try to have a "beta site" or "beta application" and continuously deploy to it. Let real users see it and use it - get real feedback. Don't listen to *all* feedback, but more is better than less (and one is infinitely better than zero).
13. Prototype!
    You don't have to stop prototyping (and by "prototype" I include things like mockups e.g. in Balsamiq) just because project has started (and please use prototypes before you start the project as well). Don't finish all the nifty little details 100% (see previous item as well); give users something they can see and interact with. It doesn't have to work all the way to database and handle all "edge cases" etc. Read more here: https://medium.com/@ppolsinelli/from-noestimates-to-yesprototypes-1b51f6a63e5d
    Remember that real user input is something good! Change is better than following a plan, right?

Remember, this list is mainly written for my own purpose, and it fits me and my context. But I'll be happy if you would like to provide some comments on your thoughts and opinions.

Capabilities (or why IT projects fail)

When you (as a company/organization/department/whatever) have an idea or a need or a problem you want to solve you may not have the ability to materialize the idea or solve the need/problem. You then need an ability to do it - a capability. That's the definition of "capability" I'd like to use when it comes to software (or IT in general).

If a company have an idea/problem/need that might result in them wanting some kind of capability that requires software.

Now, they want to know what that capability (via software) is going to cost them to get and maybe they need it at a specific date or at least when to expect to have their new capability ready. Nothing strange, who wouldn't?

The software is built. It might unfortunately be over budget (underestimated obviously), late (underestimated obviously) or it didn't provide the capability they needed.
But, I say it really doesn't have to matter. At least why it is a "fail". Maybe it's on (or below?) budget, on time (or maybe early?) and the right capability was provided and it still is a "fail". Why? Because the idea wasn't that good or the need wasn't really something someone actually had or solving the problem didn't really mattered.

So, how can you know before you have the capability? Well, you can't. The only way to know is to actually have it. But. There's a mind shift here. (Some are actually already doing this) Validate. At the end of the day it's all about learning. You want to learn that your idea is good or that the need is actually a need someone has or that solving a problem is worthwhile. And eventually you *will* learn (or not, if you choose not to do it).
And you can only *assume* that the capability will give you that learning.

Now, you can either start thinking about it (analyzing) or you can start acting, creating. That's the mind shift. I'm not saying: Stop thinking! Stop analyzing! But instead of "Let's postpone this to next meeting" (or whatever), think "What can we do today/tomorrow that will bring us learning about this? Is there anything small we can start doing?". I.e. how can we try - and validate - this assumption we have? Anything? Think "small". Think "learn". Think "validate".

If I take it to the extreme, I basically think they have two options (according to The Rule of Three they should have three options and not two, because 1 option is a trap, 2 is a dilemma, 3 is a choice :-) - heard through George Dinwiddie and Jerry Weinberg. But I'll let you ponder on that third option yourself. Or let all the "gray zones" in between these two extremes be those options).

1. Assume there's a software project ahead and start defining it. Gathering requirements, start planning, estimating etc.
2. Assume there's something small that can be started now (or as soon as possible). With the focus on validating that the assumptions are correct. Maybe we can continue iterating from there or at least we are more confident (validated) that the capability will make a difference and can go to point 1 above.

I'm not saying some (most?) companies aren't doing this already. But this is my experience, and the customers/companies I've met don't have much of this mindset. Your experience may differ.

And I suggest that if you have validated that the basic idea or need or problem will "pay off" it might not matter that much if project is over-budget and/or late? It's never something good, I admit that, but we might not consider it a "fail"?

But then again, it feels good being able to "blame" the IT project (and probably the "supplier" - someone else!) for being the "failure" instead of trying to change your own behaviors, seeing your own responsibility..?

Estimates: Lies and Guesses?

Terry Bunio has already written a blog post on this Are #Estimates Lies? #NoEstimates. But I like to give my point of view on this topic as well.

To make a long story (blog post) short: "Estimates are not lies and guesses". There, you can stop reading here if you like :-)

Still here? I'm glad you would like to read more on my thoughts on this :-)

I hear that these statements are something that the #NoEstimates "community" claims to say or hold true. I haven't actually heard so much about it, but if it's true I would like (as a person thinking that the ideas behind #NoEstimates are good) to reject these statements - if so. But... there is a grain of "truth" in there... There is a reason why someone would call them "lies" or "guesses". Let me dwell on it.

Estimates are not lies or guesses - in the unicorn world! :-)

If you look at the pure definition of the word "estimate" (Merriam-Webster) you can see that it's not about guessing or lying. In the the definition you see words like "judge", "tentatively", "roughly", "approximate", "general".

But is this really the only usage of it, in the world of software development? Rhetoric. No.

And this is what #NoEstimates are trying to address. And this is where I think that #BetterEstimates and #NoEstimates share the same "interest". Maybe, in the end, we share the same solution to the problem: Communication! And in "communication" I put in words like "honesty", "transparency", "forthrightly" etc. Things that make communication meaningful and without "smell". Ok, maybe you should never be 100% honest etc? There might be situations. But you get it, nothing is ever 100% "true" or "false".

How does #NoEstimates fit?

In my opinion, I think it fits as a "topic" in this discussion about "dysfunctions" or "smell" associated with estimates. I see the hashtag as a "prefix" or an "abbreviation". I don't seem to get much throughput there, maybe I'm seeing things wrong? What do I know... But it's still my opinion, and I hold myself the right to change it later on, if someone points me at better :-)

But let me explain a bit.

Guesses

Sometimes I actually have no idea on how long time I think it's going to take when asked "How long..?" or "When..?". Usually it's because it's too vague or it feels too "big" to give a credible judgement - or anything else. 

The most honest thing is then to say that: "I have no idea" (or similar) (and when I do, we usually stop discussing estimates).  But when we're doing planning poker, or something else, it might not be easy to say that. Or when faced with some types of customers (you know which ones I'm talking about... :-) ). There's then a risk/chance that you do something that is more comparable with a "guess". Sometimes maybe the planning poker session is "forced" with: "We don't have time to discuss the details here, we must come up with a figure tomorrow" - i.e. "forced" to guess. 

Then I think #NoEstimates fits as #NoneOfThoseEstimates.

Sure, it's "bad management" or DDSTOP. But it fits the conversation, in my opinion. Like: "STOP!" or "NO!" (#No!Estimates?).

Lies

Sometimes, when I estimate, that estimation magically turns into a deadline. I.e. there is no "real" deadline (like market window, synchronization with other things etc), the estimate becomes the deadline. As in "We think we can pull this off in X sprints/iterations." and looking at the calendar that will occur at December 6. And the date is communicated up to the CEO (or whatever).

And in other times, estimates are "gamed". Like "Really that much!?" or "You have to cut that!". Usually in some "bidding" context. But I have actually heard customers say that directly faced with an estimate (and there are other reasons, than the estimates, why they say that).
And in other times, estimates are used because someone "above" needs a number to pass up the chain.
Etc...

In these scenarios you could actually call the estimates more like "lies" than "judgements".

Sure, again it's "bad management", "bad communication" or DDSTOP. But it fits the conversation. Again: #NoneOfThoseEstimates or #No!Estimates.

TL;DR

There are lots of other dysfunctions associated with estimates. All fits the #NoEstimates hashtag. Does it then mean: "Stop all estimations!"? Of course not.

And #NoEstimates also speaks of some "paradigm shift" on how both business and IT approaches software and how it is looked upon. But that's another topic :-)

But, #NoEstimates are centered round the fact that estimates are good if they are valid and used for the correct reason. No one thinks otherwise.