How did you introduce pair programming at sipgate?

Recently I’ve been presenting our Work Hacks at a couple of places and talking about pairing up as part of it. Not only do we pair program but we also mob program and pair up across roles: Dev and UX designer, PO and customer support, UX and PO, dev and customer support, dev and … You get the idea. We’ve done just about every combination our very cross-functional teams allow for.

Whenever I talk about this, a common follow up question is: “How did you introduce pair programming?” or “How did you make people adopt pair programming?”

Short answer:
We didn’t. Nobody made a concerted effort to establish pair programming at sipgate.

Long answer:
Not long after we started using Scrum it dawned on us that Scrum alone wouldn’t save us. Only combined with sound software engineering practices such as the ones from XP would we be able to improve our codebase.

Sometimes I hear tales by developers from other companies about management not wanting them to pair program or TDD. In our case the opposite was true. Our management was okay with TDD and pair programming. There just weren’t many people interested in doing it.

Fortunately “not many” is more than “nobody”. There were some curious minds and teams who started to try it out.

It worked well for them so they kept doing it and told others about it. And what do you know, just a few short years later (about three or so) the tables had turned and pairing up was the new normal. Now you were the oddball when you didn’t want to pair up.

To this day it depends a lot on the team. Some teams pair up all the time, some mob, some only pair up for critical stuff. All of that is okay.

We all agree that pairing programming leads to fewer defects and better readability. And pairing up across disciplines helps us keep tight feedback loops and to spread knowledge.

Would you like a coconut?

Last week I attended a very enlightening workshop hosted by solution-focused coaches  Veronika Kotrba and Ralph Miarka. Early in the workshop Veronika introduced a superb metaphor for giving advice that nobody asked for. I’ve written about unsolicited advice before, but the coconut-model does a much better and funnier job.

Let’s start with one of the solution-focused tenets: “Everybody is the expert for their own situation”. Based on our experiences we all see the world differently and can never truly know anyone else’s impressions. We each live on our own island and usually don’t know much about the islands of other people.

Bertram's island and Zili's island

Let’s say there are 2 people on their respective islands, Zilli and Kurti. Zilli’s island sports a glorious coconut tree and Zilli looooves coconut. The meat, the milk, the pina colada – she loves all of it!

Kurti’s island on the other hand has fir trees growing. Kurti has never heard of coconuts in his whole life, let alone seen one. What a sad state of affairs! Zilli wants to share the coconut goodness and saves one of her precious coconuts to throw over to Kurti. What do you think how Kurti will react? Grateful?

Zili throws a coconut

Unlikely. Zilli just attacked him with a big stone. Unprovoked! Why would she do that? Kurti has no choice. He has to defend himself!

Bertram raises the shields

Which in turn will anger Zilli. Kurti lets her gift go to waste! That was an excellent coconut! Pfft, she’s never going to share anything with such an ungrateful person!

Not a good exchange at all. Yet, it often plays out like this when someone tries to introduce change. But Zilli could have done better. She could have asked, whether Kurti is interested in trying coconuts. And if he’s not, accept that. And if he is, all the better! She could have shown him how the crack one. The meat, the milk, the pina colada. Chances are that Kurti would have liked some of it.

Questions build bridges

I plan on using this metaphor a lot in the future. I want to pass on what I learn. I hail from a long line of teachers, I can’t help myself. Heck, this blog is nothing but a big pile of coconuts, so that I have an outlet. You’re here on your own free will, so I hope that’s okay with you. And if we meet face to face and I ask “Would you like a coconut?” you know that I’ve got excellent, excellent ( 😉 ) advice that you didn’t exactly ask for. You can say no. That’s okay. It’s why I ask first 🙂

PS: Thanks to Veronika for the flipchart drawings!

Why didn’t anyone ever tell me that?

After about 2 or 3 years into my agile journey there was a time when I would listen to a talk or read a book and be like “Yeah, it’s exactly like that! I wish someone had told me 3 years ago! It would have helped me a lot! Why didn’t anyone tell me that?”

The specific information provoking that thought was typically something about people, how they behave and communicate, and how change unfolds in an organization.

After even more time I now have the sneaky suspicion that “they” did tell me that. But I wasn’t ready. The factual information didn’t stick, because it was beyond my horizon. I wonder if there are some things you have to experience yourself, mistakes you have to make and only in hindsight you can appreciate the wisdom of others.

Not sure if that is disheartening (I’d rather learn from others than make mistakes myself) or liberating (we are allowed to fail). All I know is that I’m a lot more patient than I used to be. I can now let others make mistakes they need to make in order to learn. And I try to not push advice on others, when they haven’t asked for it. It’s something, I guess 😉

Solve people problems with data

[This post has been a draft since 2013. Not sure why, it was 95% finished…]

At OOP one presenter asked the audience and thus me: “How did you successfully resolve the biggest challenge in your professional life?”

My answer: “Talking”. Every one else’s? “Conversation”, “Communication”, “Face-to-face-meeting”.

In many ways I’m paid for having conversations: As Jerry Weinberg said, every problem is a people problem – I try to solve these people problems by having conversations or making other people have conversations with each other.

But sometimes that’s not enough. It hit me, that my more successful interactions in crucial situations have not just been about exchanging perspectives. I’ve had data with me. Consequences of behavior expressed as numbers and charts, or even as a price.

When you’re leaning towards the “touchy-feely” end of things, it’s easy to forget how data can make the case for you.

For instance, if a Product Owner receives too many feature requests to implement all of them and is not empowered to reject them, the requests will pile up. If that pile is hidden in a ticket tracker, the problem is invisible. The requesters will just wonder and / or bitch why the developers don’t fulfill their requests, whereas the developers will groan under an impossible workload.

If the PO tracks the requests on a board the problem will at least be visible, when the board overflows. The PO can point to it and make their case. Will this change anyone’s behavior?

Sample Graph: Request VolumeWhat if the PO tracks the incoming vs. the finished tickets to demonstrate how much demand and capacity are out of sync: The yellow line represents the accumulating unsatisfied requests. This is a chart to base a discussion on. Much better than “it’s just too many”. The PO and the stakeholders now see that there’s about 3 too many requests per week and that there’s no way for the developers to ever catch up with the pile. Time to take some decisions.

Data is powerful! Especially if the information not hidden in a sea of numbers. If you want to convince people take the time to coax out the information. Make a fancy chart! You know you want to 😉

Sometimes it’s enough to bring a few numbers to put things into perspective: That you’re not complaining unreasonably. It can help counter the opinions (read “not backed by data”) of people higher up in the food chain.

Whenever I encounter a significant problem I think about how to make it accessible, visible or even palpable* for others who I want to help me solve it.

* There once was a team that inflated a balloon for every ticket they got. Within a week they were up to their knees in balloons, communicating to every one that they got way too many requests. Can’t find the original source 🙁

Talking about failure – Long Way to Lean #1

When I give my talk “Thank God it’s Open Friday!” people always tell me how much they liked hearing about our failures on the way to a solution that works well for us.

It’s surprising to me, because our previous trials with a slack day are only loosely related to the very successful end result. It’s the part of the talk for which I always doubt whether it’s interesting to anyone. That part only exists, because I created the talk for Agile 2015 in the “Experience Report” track. If I had created a “normal” talk I would have only presented our shiny solution. Much like other people tend to present their shiny solution and rarely the way they took to get there.

That’s how we end up showing each other our pretty sides, once we have figured it all out and we hide the hard work and multiple failures it took to get there.

That can be quite intimidating for people who just start working in a better / different way. Like everyone else just flipped a switch and they are the only one’s struggling.

Well, you’re not. sipgate is a fantastic place to work. It has been for about 2 or 3 years. But we started down the agile road in 2010. Now 2016 is nearly upon us. That leaves 3 years that were less than stellar. Some times during these 3 years downright sucked. And I want to tell you of the suckage and the working solutions that we surfaced with. Heck, I might even tell you of the things we still haven’t figured out. It’s not like we don’t have problems anymore…

So, “Long Way to Lean” is gonna be a series here in the blog. It’s loosely based on my talk of the same name.

If you’re interested in specific aspects, let me know in the comments 🙂

Replace Rewards or What are you celebrating? – Menlo #5

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

Cover of Joy, Inc. There is an interesting passage in “Joy, Inc.” about change saying that when you take away one reward system you have to replace it with a different reward system – one that encourages the behaviours you’d like to see – as soon as possible.

As long as the old reward system lives, people will fall back into their established patterns. And rewards don’t only mean bonusses. It also means bonusses, but non-monetary rewards are more important, such as being needed, being the hero, etc. You need to replace these rewards – e.g. with the ability to go on an uninterrupted vacation and without huge stacks of work waiting when you come back.

In that vein, Rich told a great story: A research company wanted to work more in teams. Everybody was on board, good people, they implemented new collaborative processes and still… People didn’t “really” work together. And they couldn’t put their finger on why that was. Rich was stumped too.

Until he finally thought to ask: “What do you celebrate around here?” And they showed him their wall of plaques for patents granted. Each plaque with 1 name on it. They celebrated individual achievement, not group achievement and it hobbled their intention to collaborate. It worked out for them after they had torn down the wall.

What does your company celebrate?

What have you learned from what you tried?

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

When somebody asks you for advice, you do ask for what they have already tried, right? Before blurting out all of your brilliant ideas, right?

Screen Shot 2015-08-16 at 5.03.11 PMWhat if I told you, we can do even better?

“What have you learned from what you tried?”

Can you feel how this shifts the focus from unsuccessful tries to the valuable learning gained from them? One small change in phrasing, one giant leap in focus 🙂

Sometimes I’m rubbish at remembering where I picked something up. I’m 80% sure it was Michael Hamman in his session “Helping Executives Become Agile Leaders: Coaching the Executive Leader“.


Coach Demand, not Supply

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

Another nugget of wisdom from Esther Derby and Mike Lowery‘s “Coaching Flow” (the other one being “Reframing“) was “Don’t coach Supply, coach Demand“. So, what does that mean? Let’s say, there’s someone frying bacon and you want them to fry eggs instead.


If there’s someone shouting “Bacon! Baaaaacon!” into the cook’s ear all the time, you won’t get far with your eggplants egg plans.

You’ve gotta change the Bacon shouter’s behaviour first, before the cook has a chance to change theirs.

It certainly rings true for me. That one time at band camp I worked in the tech department of a company and we hardly ever shipped anything. Mostly because the business department demanded STARTING whenever a client shouted. FINISHING, by comparison, wasn’t in their focus. They were upset that none of their requested feature ever saw the light of day, but dropping what you were doing to switch to the latest request was way more important than finishing an old request.

In short, tech had little chance to change with business breathing down their necks and demanding unreasonable behaviour.

I tried to coach the business side, too, but my “authority” was clearly rooted in the tech dept. My influence on the business side was very limited. The overall company was very sales driven anyway. Not much wriggle room.

At that time none of us techies were able to change demand, so the results stayed the same, as coaching supply will rarely have lasting effects.

Maybe today I would do a better job, but back then, not a chance…

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?