Estimation: Back to Hours – Menlo #4

[This post is part of a series about Menlo Innovations, the company described in "Joy, Inc."]

Cover of Joy, Inc. At sipgate most teams estimate in Story Points. It was what you did back in the day when we started with Scrum and we’re used to it now. It works well enough for us.

I’m not a great fan of Story Points and the endless sense-making discussions I associate with them so I tried shirt sizes at another company. They seemed to work with fewer debates than points.

Lately, I’ve liked the idea of Ideal Days, as popularized by Rachel Davies. Ideal Days are essentially time based, which we were once taught is a “big no-no” in Agile estimation.

Curiously enough, estimating in time – hours – is exactly what Menlo does. The company formed in 2001, before the Story Points detour.

According to Rich Sheridan Story Points are an abstraction that is an obstruction. They’re desinformation. And their client contacts cannot go to their bosses with points or gummi bears. “Well, how long does it take?” No clue!

I agree. If I had to do it all again. I would give time based estimation a shot. I do see some merit in points (abstracting from the concrete person that will implement it onto the task itself) but not enough to remedy the endless discussions use of points induced for us.

Oh, and if you wanna go #noEstimates on me: Of course, I would estimate! You can build features in varying incarnations. Sometimes it’s not a specific feature you need, but a balanced mix of nice to haves. In these situations, there is wiggle room and as a PO I need at least a coarse guess of how much each solution is gonna cost so that I can take a good decision.

Watching Users – Rebuttal

Have you seen this cartoon lately? With the caption “How it feels to watch a user test your product for the first time”


I laughed when I first saw it. I’m pretty sure I’ve retweetet it from this guy (his source (their source)). Ever since, I can’t shake the feeling that I betrayed my User Experience education. Yes, that cartoon captures what it feels like to watch users try to use something you created. You think you made it obvious, when you didn’t.

But I’d bet that for most people who retweeted the cartoon it seemed to capture what users behave like, thus continuing the “users are stupid” narrative. That’s why I made this:


There, I fixed it. Sorry for the crude drawing. I hope my UX honor is restored.

PS: From the conversations on Twitter it’s perfectly clear that the guy who tweeted it is aware that the designer is to blame. It’s less obvious to people without an UX background.

Scaling through Pairing – Menlo #3

[This post is part of a series about Menlo Innovations, the company described in "Joy, Inc."]

Cover of Joy, Inc. It’s quite common for my colleagues and me to pair. Not just developers, but also UX & dev, PO & UX, Customer Support & PO, … There are many combinations and I usually feel quite smug about our level of pair programming. Until I’ve read how rigorously they do it at Menlo Innovations:

Everyone pairs and they reshuffle the combinations Every Monday. Who pairs with whom is one of their most thought out processes and is assigned by project managers. You only work in your pair. You must not write code while your pair partner is away.

Frankly, to me that feels odd. That some project manager prescribes pairs; that I’m bound to that person and that it will be someone else every week. At sipgate we have stable teams so we always pair with the same few people. And we decide when to pair program and with whom.

Still, what Menlo gains with their rigorous practice is very attractive: The ability to scale. Fast. Up AND down. If they need to bring in more people into a project the existing members are “seeds”. They can all be paired with someone new to the project and effectively double (or half) the (wo)manpower within 1 week. That’s a huge advantage! Plus you avoid the dreaded towers of knowledge that are prevalent nowadays.

We don’t need to be able to scale that quickly because we’re not an agency, but if we were, I’d be reconsidering our pairing approach right about now.

High Tech Anthropologists – Menlo #2

[This post is part of a series about Menlo Innovations, the company described in "Joy, Inc."]

Cover of Joy, Inc. Menlo Innovations is an agency, which means that they do software projects for other companies whose domain they know nothing about. Still they manage to deliver what end users need, to delight them even. How do Menlonians do that, when so few companies in our industry manage that? High Tech Anthropologists!

Anthropology is the study of humans, BTW. Menlo took a leaf out of IDEOs playbook and whenever they start a project, their High Tech Anthropologist swarm out to observe the intended audience interact in a situation related to the project outcome. In Rich Sheridan‘s words:

“You can’t invite users into your office and ask them what they want, because they don’t actually know what they want. It’s not because they are stupid; it’s quite the opposite. They are unconsciously competent at what they do all day, so they can no longer deliver the most important minute details simply because they are unaware of them. The only way to get around this limitation is through keen and patient observation.” – Page 111

For example, when Menlo build they camped in front of kiosk shelves with bridal magazines, wedding fairs and gown shops. They observed and talked to the intended users. Crazy idea, right?

Actually it’s so very obviously a great idea that it’s all the more astonishing that virtually no one elso is doing it. We all seem to think that we magically know what our users need. And we don’t. An online survey doesn’t cut it. (I’m tempted to quote the quote again for emphasis…)

It’s maybe Menlo’s advantage that they truly don’t know the domain and can more easily adopt a beginner’s mind. For an established company that’s been in the domain for 30 years it’s very hard to assume that they don’t know their users. There’s always people who are convinced they know how their users think and what their workflow is. And they can be offended at the notion of going out to observe. You should go out anyway.

From my experience with Usability Tests (not the same, but close enough) I’m happy to report that I’ve learned something new in every single test. That interface you’re convinced works… How do you know? You don’t. Until you watch people try it.

Anyway, I, for one, am already contemplating how I can get to observe our customers. It’s a fair bit trickier than waylaying people who plan a wedding, but it’s not impossible! We’ll figure it out :)

Favorite Quotes from Joy, Inc. – Menlo #1

Cover of Joy, Inc.What a blast! We (sipgate) just hosted Richard Sheridan, CEO of Menlo Innovations and author of “Joy, Inc.”. Both, the real life Rich and his book are very entertaining and inspiring. So much so, that I’ll write a small series. I want to help spread the word about:

For starters, here are my favorite quotes (okay, passages) from the book:

“You can’t invite users into your office and ask them what they want, because they don’t actually know what they want. It’s not because they are stupid; it’s quite the opposite. They are unconsciously competent at what they do all day, so they can no longer deliver the most important minute details simply because they are unaware of them. The only way to get around this limitation is through keen and patient observation.” – Page 111

That’s where High Tech Anthropologists come in handy.

“To truly run an experiment, you need to try something out more than once, because at first -  no matter what you try – it will probably be bumpy.” – Page 132

“[A]n aspect of scaling that no one ever considers: scaling down.” – Page 195

Indeed, when do we ever consider scaling down? “Scaling” in everyday tech use only knows one direction.

“We have always felt that our contracts [...] should be ones we’d be comfortable signing no matter what side of the table we were sitting on. When we receive contractual terms from our clients, many of them are completely one sided; it is left as a difficult exercise for us to add in terms that protect our interests. We see this as incredibly wasteful and a terrible way to begin a relationship between two companies.” – Page 224

In other words, ye olde “Do unto others as you would have others do unto you” is universal, even and especially for contracts :)

Have you read the book? What’s your take on it?

Sketchnotes from ICP 2015

At the end of October I attended the International PHP Conference aka Webtech Conf in Munich. Even though PHP is not my strong suit there were plenty of interesting talks to choose from. Here are some sessions captured as sketchnotes:

20 Years of PHP - Keynote by Kris Köhntopp

20 Years of PHP – Keynote – Kris Köhntopp

Langlebige Softwarearchitekturen von Carola Lilienthal

Langlebige Softwarearchitekturen – Carola Lilienthal

Semper Fi - Leadership Lessons from the Marine Corps - Gordon Oheim

Semper Fi – Leadership Lessons from the Marine Corps – Gordon Oheim

Law of the Hot Shit - Keynote - Frank Kleine

Law of the Hot Shit – Keynote – Frank Kleine

Code Quality for Agile Teams - Frank Sons

Code Quality for Agile Teams – Frank Sons

The Long Way to Lean

Last week I spoke at the International PHP Conference aka Webtech Conf 2015 in Munich.

Corinna speaking - Photo by Peter Rozek

Photo by Peter Rozek

My talk “The Long Way to Lean” was the story of sipgate’s ongoing journey from traditional silo-ed company to agile and lean via Scrum. Find the slides & speaker notes here. There was a camera, so I hope I can eventually add a link to the video *fingersCrossed* Stay tuned :)

You’re qualified to talk! – Public Speaking #2

Okay, say you’re positive that your topic is interesting. Still, you can’t possibly give a talk because you think “I’m not an expert! I’m not qualified to speak about it.”

I don’t know you, so maybe. But that “maybe” has slim odds. In my experience it’s true for about 5% of topic ideas per person. The rest is various grades of fear and impostor syndrome.

I’ve heard  “I’m not qualified” from people who are insanely good at their jobs. People for whom I can immediately think of 5 topics I’d like to hear from them about and that they are more than qualified to talk about. “Qualified” is a very mushy concept anyway.

Let’s turn to Amanda Palmer for a spell. This is what she says about being an artist qualified:

[N]obody ever tells you or hits you with the magic wand of legitimacy. You have to hit your own head with your own handmade wand. And you feel stupid doing it. There’s no “correct path” to becoming a real artist qualified. You might think you’ll gain legitimacy by going to university, getting published,[]…[but] it’s all in your head.

Whether you’re qualified also depends on the context. For example, I did a talk about Esperanto about a year after I had encountered the language. I didn’t even speak it fluently (and never got that far). What I had going were lots of theory, first practical experiences and loads of enthusiasm. I gave the talk at Chaos Communication Congress, an informal, volunteer run IT conference. Most attendants had never ever encountered Esperanto before. I knew more than them. In that sense I was qualified.

Was I an expert? Nope, not by a wide margin. In fact, Martin, one of the other speakers, turned out to be heavily involved in the Esperanto community, speaking the language for 10 years.

But his talk wasn’t about Esperanto in the least. Mine was. No conflict.

He agreed to come see my talk and help answer questions. Worked like a charm. There were 2 questions I couldn’t answer and he could easily help out.

In general, for this whole public speaking thing – whether you consider yourself an expert or not – it helps immensely if you’re comfortable with not knowing everything. Being able to admit “I don’t know right know. Let me think about. Give me your email, I’ll get back to you.”; being okay with someone in your audience knowing more than you about certain aspects of the topic.

Care more about your audience learning something than that they learn it from you and you’re good to go :)

A great way to train are BarCamps. There the audience is part of the presentation and expected to share their experiences.

It’s worth it, going out there with imperfect knowledge! I get about 1 email per 2 years from people telling me that they learned Esperanto because they saw a recording of my talk. That’s impact. That’s changing someone’s life. And that’s just the ones I know about. Sharing knowledge is powerful!

Oh, and by the way, you learn a lot while preparing a talk. If you aren’t already an expert you are gonna get closer.

Your topic is interesting! – Public Speaking #1

Recently I’ve hosted an Open Space session on finding topics and writing abstracts for conferences.

One of the participants remarked: “I’m not sure that anything I know would be interesting to other people. None of it is really new.”

I know that feeling. I’ve shared it. Sometimes still do. Not often anymore, though.

On most days I manage to say “Hogwash!” to that feeling, because your topic is interesting! Every single one of the 7 billion people out there? Nope. But for some people? You betcha!

Woman on stage

CC-BY Nan Palmero

Just pick a conference you’d like to go to and submit that talk. If it is not interesting – to this particular conference committee – they will decline. End of story. No harm done. All you’ve lost is a few hours for writing the abstract. And hey, you can totally re-use your material and submit it to another conf, so I wouldn’t even consider it lost, yet.

Not convinced? Well, if you’re unsure about public speaking, try it out in a smal setting (and in your native language!). What about a local meetup? Offer a talk to the organizers and pick a topic together with them. They can help you zone in on something interesting.

Even if it’s all been said before and better, people have not heard it from you. Your unique perspective, your challenges, your experiences and lessons learned.

Try it! Public speaking will get you to interesting places, meeting interesting people!

[Do I hear you say "But I'm not an expert. Other people know way more about it"? Stay tuned! I'll cover that in my next post.]

PS: For statistics: I can think of a potentially interesting topic for about 90% of the conferences I’d like to go to. About 60% of my proposals are accepted. Because I often submit more than 1 proposal I get to talk at about 80% of all the confs I proposed for.

If you stick with this long enough (about 20 talks?), eventually others start to ask you to talk at their event, which feels really nice.

“What was your favourite session?”

In 2013 I wrote this piece on “Ready-made Conversation Starters – for Conferences“.

It’s a suggested solution for my reluctance to initiate first contact at a conference lunch table. I mean, I’m there to get to know people and yet I don’t manage to casually start a conversation.


In August I’ve been to the US for the first time and at this conference I managed to start conversations. I think that 2 things changed. Firstly, I really wanted to get over myself and secondly the other ones were American. What I know about US culture gave me permission to try to chat people up. When in Rome, do as the Romans do…

Luckily I found out early on that “So, what’s your favorite session so far?” is an excellent conversation starter.

I want to keep that line and to keep making contact. For the mostly German confs I attend, I plan to get my inner American on and get to know people. :)