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