Thank God it’s Open Friday – FAQ

In my current talk “Thank God it’s Open Friday” I describe our experiences at sipgate with holding an Open Space every other week.

If you’ve missed it, you can watch a recording (55 minutes) or read the paper. There are also slides, but they are not self-explanatory.


So far, I’ve given it at Agile and FrOSCon. Both times I’ve gotten great questions! In this post I’d like to collect questions and answers:

  • How would you do Open Friday it with a distributed team?
    Probably less often 😉
    Is there a time when people meet anyway? Then, then.
    Do only a few people work remotely? One attendee said that remote people attend via a laptop, which their “local” colleagues carry around.
  • What do you do if you’re few people (in this case: 6)?
    Depends on what problem you want to solve with OF. If it’s knowledge transfer, try brown bag lunches. Invite outside people. Maybe pair up with another small company, if you don’t do supersecret stuff.
  • How do you ensure people pitch sessions?
    In BarCamps you have to pitch a session, if you’re attending a BarCamp for the first time. Not the route I’d go, though. I’d try to ask people individually, to pitch a session and help with finding topics. I’d make sure there’s at least 2 people ready to be the first pitchers so that other feel comfortable following.
  • How often should you run an Open Space to try to establish it?
    Not just once. At least 2 or 3 times. Before the 1st one I’d hang up these 1-pagers explaining Open Space, so that  people know what to expect.
  • How long did it take for people from all departments to take part?
    People from product teams joined first. They were used to self-organizing as well as the slack day. The others joined bit by bit and it took at least 2 months (= 8 OFs) and several encouragements that, yes, “everybody” did mean “everybody”. Now the OF opening ceremony has 50 (summer holidays) – 80 participants (out of 120 employees).
    Continue reading

What is Coaching anyway?

[This post is one of many inspired by Agile 2015]

[Update: After reading Johanna Rothman’s comment, a better title for this post would have been “What is Reflective Coaching anyway”.]

The other day I found out that my husband’s definition of what it means “to coach someone” was very different from mine. His was a sports one, i.e. someone who observes and then gives hints what to do differently. It seems to be a popular notion. Last week, Johanna Rothman quoted Consulting Role: Principles and Dynamics of Matching Role to Situation, by Champion, Kiel and McLendon with this definition of a Coaching: “You did well; you can add this next time.”

Mine is different, though and given the high number of coaching related sessions I attended at Agile 2015, I will probably talk a lot about Coaching. Hence it might be good to clarify what I mean, when I use the word.

For starters let me point out that Agile Coaches very often do not actually “coach”. Take this framework by the Agile Coaching Institute:


You’ll notice that Professional Coaching is only 1 of 4 possible activities, next to Teaching, Mentoring and Facilitating. At least in the beginning of an engagement Agile Coaches often have their hands full Teaching and Facilitating and that’s okay. Advice and orientation is often what people need and seek.

In contrast, coaching is the act of creating and “holding” a safe space in which the coachee can find answers in and by themselves.

 “Coaching is life-changing – if it is not life-changing it’s not coaching” – Martin Alaimo

For the most part, for me that translates into shutting the fuck up and doing some serious listening. As a coach you don’t have to have all the answers. But you better bring some pretty great questions! Powerful questions for example. Or clean questions.

How about you? What’s your definition of Coaching?

Coaching Canvas

[This post is one of many sparked by Agile 2015.]

Have you noticed how many canvases are around these days? Business Model Canvas. Lean Canvas. Value Proposition Canvas… Can’t we think of any other approach anymore?

That’s why I was a little hesitant when Olaf Lewitz and Martin Alaimo opened up their “Great Coaching Conversations Workshop” with the “Coaching Canvas“. Yeah, right…

Coaching Canvas

How I regret thinking that! It totally worked! We paired up and took turns being coach and coachee.

We had a list of Powerful Questions to pick from for each field of the canvas. Together with the canvas this was enough rigging so that 100+ people had insightful conversations. Some even had coaching conversations:

“Coaching is life-changing” – Rich Litvin

“If it’s not life-changing it’s not coaching” – Olaf Lewitz

I had one, for example. I had a profound realization about myself and how I view tricky situations. This realization might well change my (career) path sometime in the future. Still mulling it over.

I guess what I’m saying is: If you’ve got a coaching situation on your hand and don’t have much experience in coaching, absolutely do give the Coaching Canvas + Powerful Questions a shot! You’ll be surprised!

Thank you Olaf & Martin!

Rules are made up

Do you sometimes observe something awesome at work which makes you realize how much everybody’s mindset has already shifted towards lean and agile thinking? Lately I have a lot of these moments. I always savour them, because in every day routine it’s easy to see only problems and forget all the things that are already working great. It’s uplifting to not always look at the road ahead, but to take the time to turn around and rejoice in all the ground you’ve already covered. I had one such rejoicing moment 2 weeks ago.

How far we’ve come

I took part in an Inhouse Podojo, i.e. all attendants were colleagues of mine. Spoiler Alert: If you’re thinking of joining a Podojo, please don’t read on! I mean it, shush, go away!

Still there? Okay. Part of the Podojo was the inevitable Lego simulation. In the simulation we had 2 Scrum Teams with 8 people each. Each team had its own lanes of stories and its own table to build on, though we were to work on the same product and had to “integrate” on Team A’s table at the end of each sprint. 3 sprints to go.

In the first sprint planning (3 minutes) our PO went to take a first pick of stories from our 2 story lanes and the team decided how many to take. We got all of it built, but at integration time we found that the other team had built some of the exact same stuff, because their 2 lanes had had some of the same stories. At least we had similar priorities in picking these overlapping stories first 😉

Building stuff twice was the obvious problem to fix during the first retrospective. And that’s where it got interesting: Both team’s independently of each other decided that a) the POs should go pick the stories together and b) we should all work on one table. And so we pushed the tables together to make one big workspace.

It worked great. So great in fact, that neither team had any great complaints or improvement ideas during the last two retros.

Why do I think the table-merging thingy is remarkable?

Continue reading

What does it take to succeed with agile?

sipgate, my employer, has come a long way since introducing Scrum in 2010. Overall I’d consider our journey a successful transformation. Today, we can ship much faster with better code quality and information is readily available to every employee – to name a few advantages.

Of course there are many factors that contribute to a successful agile transformation (yep, you got me, the title is clickbait), but if I had to pick one single most important factor and draw a diagram to represent it, it would be this:


What do you think this might depict? Take a few seconds to come up with a guess, before you scroll down.

Continue reading

Questioning the status quo without stepping on toes

Remember my “Resistance Against Change as a Way to Save Face” post? James described an interesting situation in the comments:

Here’s the thing. Im my organisation call centre workers are managed based on adherence to roster. The roster is a plan, based on a forecast of customer demand, telling staff when to be available to take calls, and organising when they can spend there time on other activities. Managers believe that this is a customer focused approach. They seek to maximise adherence to roster, and they reward staff for doing so. However it takes no account of real demand – just forecast demand. I would argue that when the forecast is wrong it is right to move away from the plan to help the actual customers, but this systems prioritises the hypothetical customers in the forecast above the real customers on the phone (or any other change in circumstances not accounted for in the plan.)

It’s idiotic. Any suggestions about how to address this folly without making those who implement it feel foolish.

James asks about a process, not someone’s individual ways, which is similar but not the same. For this scenario I do have ideas:

Be curious

Why is the current process the way it is? Become a researcher and find out. This works best if you are new to the company or the department.

Caution, for this to work you have to be genuinely curious and prepared to change your mind. People can smell a hidden agenda. And who knows, maybe the current process makes perfect sense if seen as part of a bigger picture.

Do you know who came up with the current process? If they’ve left, this will make your life easier. If not, talk to that person first. Alone, so there’s less reason for them to be defensive. Be careful how you phrase your question and offer your observations. Words like “folly” and “idiotic” would rub everyone the wrong way. [I don’t really think you’d put it like this with them 😉 ]

I’d try it like this: “Do you have a minute for me? I’ve noticed something surprising in the way we handle things and would like to understand why we do it like this.”

Best case scenario: There was a reason to do it the current way which doesn’t apply anymore. This becomes apparent to others while you research the history of the process and you change how agents are rewarded, because the current way causes pain.

Very important aspect that, the pain.

Who feels pain?

If no one in the company feels the pain, there is no reason for them to change*. Continue reading

Resistance Against Change as a Way to Save Face

Every once in a while I have an epiphany/experience of the “Oh. So THAT’s what it feels like…” variety, such as the one about giving unsolicited advice. This January I had the (mis)fortune to have another empathy epiphany handed to me on a silver plate:

It was a Wednesday evening and my company was having its monthly Knit Night. A Knit Night consists of lots of yarn and people knitting or crocheting. And beer. Banisters might end with a knitted cozy as a result.

I had just (re)joined the company and it was my first Knit Night. In the middle of it, one colleague glanced over at me and was like: “You’ve got a weird way of knitting. What ARE you doing?”

“Um, stockinette stitch (German: ‘glatt rechts’)? Knit one row, purl one row, knit one row, …?”
As my colleagues were quick to point out, it wasn’t “normal” knitting, but twisted [sic!] knitting (German: ‘rechts verschränkt’).

Colleague 1: “Who taught you knitting?”
Colleague 2: “No one, apparently.”

Ouch! That hurt. A lot. Which is surprising given that knitting does NOT define me in any important  way:

  • I have not invested years of my life into practicing it
  • I’ve never earned money with it
  • I’ve never considered myself an expert
  • If someone asked me to describe myself, I wouldn’t even consider “knitting”. It’s just something I’ve “always” been able to do. Or not 😉
  • I’ve only knitted minor stuff like scarves and such. My biggest knitting accomplishment is this Scotty hat for my husband:

So, if finding out that I’ve done something wrong my whole life that is not important to me or my self-image drags me down for 4 days, what must it be like for professionals when a consultant or coach swoops in? Continue reading

Clean Questions and the Power of Metaphors

A year ago I blogged about Non-Violent Communication as a means to avoid judgement and find needs. Now I think I found something even more radical (once again via Andrea Chiou): Clean Questions / Clean Language.

With Clean Language, not only do you forego judgement, you don’t even offer interpretations. It’s a bit like the game “Taboo”: You can only use words that the other person has used first. (As Clean Language was developed by therapist David Grove, the “other person” is usually a client.)

Examples of Clean Questions – X is a something said by your client:

  • And that X is like what?
  • Where is that X?
  • And is there anything else about X?
  • And what needs to happen for X?

Here’s a list of all common Clean Questions. (For my fellow German natives: Clean Questions auf deutsch)

While asking these simple, repetitive questions, you look out for metaphors used by the other person and take them literally. Metaphors make it possible to access, talk and possibly resolve very deep, semi-conscious things that would be hard or impossible to address directly:
If a client feels they don’t make progress at work, then “It’s like smashing myself head-first into a brick wall” vs. “It feels like running on a treadmill, going nowhere” describe very different experiences.

Here’s an excellent TEDx Talk on how Caitlin Walker used Clean Questions to help under-privileged teenagers to deal with anger:

I’m still on the lookout for an opportunity to try this out. If you’d like to try, here’s a great article on how to apply Clean Questions in a business context.

What do you think about the concept of Clean Language? Have you already used Clean Questions? How did it go?

The Power of Habit – Book Tip


When the insanely insightful Amy Hoy is smitten with a book, I read it. And “The Power of Habit” did not disappoint!

It’s an entertaining journey through cases that helped scientists uncover how habits (and willpower) work and how you can change them. Understanding why and how our automatic actions play out is highly important, given that they govern about 40% of all our daily actions – A staggeringly high amount.

I highly recommend reading the book! As an appetizer, here’s an excerpt on how to change a habit by changing the routine within the Cue-Routine-Reward loop.

Let’s close with some quotes I highlighted during reading: Continue reading

Evolution of team setups

Ever since my employer adopted agile some 4 years, ago, we’ve developed our products with a variety of team “configurations”. Here’s a short overview of what we’ve tried and why product teams take the crown so far.

Pre-Scrum: Silos

In pre-Scrum times there were no real teams, but rather groups of people with a similar skill set who shared a room. Everyone had their own tasks to work on. We had a room full of web developers, one with perl hoshis, another one where the project managers sat, and so forth.


The seperation was unfortunate. A nice example dates back to 2010: There is a page that lists all groups in a customer’s sipgate team account. This page had agonizingly long loading times. I’m talking minutes here. Upon closer inspection it turned out that the page requested lots of information from the backend, although it only needed to show little pieces of the requested data. There wasn’t a backend function that delivered precisely what the web page needed. And as web developers and backend developers were working separately the web developers collected the data they needed from methods that were already available, rather than wait for a method to be custom made.

Scrum: Cross-functional Teams

Today it would go differently, because in 2010 we adopted Scrum: We build real, cross-functional teams, consisting of web devs, backend devs, a designer or UX person and a product owner (a re-purposed project manager). One of the devs doubled as scrum master in each team. Such a team worked on shared tasks and could build a complete piece of new functionality.


With this setup we were already developing much faster than before. Pre-Scrum feature development had often dragged along. Now the 5 product owners were hard pressed to come up with enough work for all teams. So far, so good.

Continue reading