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.

Demo time – How to stay up to date with 10+ teams

[This post first appeared in German.]

At sipgate, we’re more than 10 teams that work (more or less) independently of each other. Each team is self-organizing. Together we deliver more than 20 updates of our services to our customers. That makes it hard to stay up to date with all improvements. That’s why the Scrum-prescribed „Review-Meeting“ evolved into a synchronisation meeting for us. During the “demo” we update each other and reach a shared understanding of where we are.

Stefan demoing (Credit: sipgate / Oliver Tjaden)

Every second Thursday we meet at 3pm. Representatives from each team take turns presenting their results. Results = stuff customers can do, that they couldn’t do 2 weeks prior. The teams get to bask in applause for their successes. Just don’t dare show work in progress that’s not live yet! The demo is reserved for things that customers already benefit from. “99% done” doesn’t cut. It’s not of value yet and not worth mentioning.

Logistically the turn taking is easy-peasy, thanks to Google Slides. Whoever first feels like creating slides on the morning of demo day copies last demo’s slide deck and shares the link with everyone else. Then it’s on: massively parallel slide editing with up to 20 people creating slides at the same time.

Come 3pm we all gather and walk our way through the slide deck. The representatives come to the front and present their part. Teams get gold stars for live demos of new features 🙂 BTW, the representatives are not fixed. They change from demo to demo.

The latest beautiful trend is that teams working on the same product have banded together to present in one go for their shared product instead of presenting team-based.

It takes 10 to 15 people 30 minutes or less to present. That’s all we need to update each other about the latest changes in our products.

PS: The demo is one of the “24 Work Hacks” in our book of the same name that will soon be available in English.

How teams form and break up when there are no managers

Self-Selecting Teams” and “Dynamic Reteaming” are a big topic in my timeline thanks to the books by Sandy Mamoli & David Mole and the upcoming book by Heidi Helfand respectively.

This made me relize that I’ve written about the composition of our teams over the course of the years but not about how people join and leave teams. Let’s take a look at this now.

Crude self-selection into initial teams

We made the switch to Scrum and cross-functional teams in 2010. Tim (the CEO) asked two designers and me into a meeting room. There was a board with a table in it. Three empty columns headed Team 1 | Team 2 | Team 3. The teams would start with Scrum one after the other with two weeks (= one sprint) in between and we each should pick a column.

The three of us were the first ones who got to choose a column, so I just picked the first one. I was looking forward to getting started with this whole Scrum thing. I still think that many of the people looking forward to Scrum self-selected into that first team. It was certainly fun to be part of that team. Continue reading

My friend, the time clock

This little exchange happened on Twitter:

twitter_no-overtime

I thought the topic might be worth elaborating on, as “no overtime” seems to be a rare thing. It’s time to confess my undying love for our time clock:

Time Clock

Obviously, it’s not its looks that secured the clock my affection. In fact, whenever I take visitors on a tour through the sipgate offices, the time clock is an unexpected sight. An young-ish company with foosball, ping pong and hammocks and then a time clock? Isn’t that a bit backwards?

No, the time clock is what prevents me from working overtime! When I was working trust-based hours, I always did overtime. When there was something to finish, I would stay to finish it, but I wouldn’t leave earlier, when there was nothing immediate to do. I didn’t really keep track of my overtime so I was unsure, when it would have been okay to leave.

At my current workplace, whenever I swipe my little card in front of the time clock to check in or out it tells me if I’m on track for 40h a week or not. You see, the 40h week did not come about because factory owners in the early 1900s thought how nice it would be if everybody got home at a reasonable hour and had 2 days of weekend. No, it happened because Ford’s tests showed that humans have about 40h of productive work per week in them. Working more does not lead to more results. At least not middle and long term. That’s why we don’t want overtime at sipgate at all.

And we follow up on that directive. We talk to colleagues who work too much. Sometimes we force people to take their annual leave (which is 30 days btw. It’s beyond me how anyone gets by with less than 25 days of paid leave. Poor US folks…)

Despite the time clock we don’t have core hours. Everyone can arrive and leave at any time they want. That’s super practical for doctor’s appointments and such. You just have to co-ordinate with your team. Missing the daily stand up should be an exception, because otherwise it’s difficult to work together 😉

Some of our customer supporters works in shifts, staffing a hotline. They have to be on time for their shift. But other than that, we’re pretty free to distribute our time as it fits ours and the company’s needs.

What system is in place at your work? Do you like it?

Letting go of decisions

When building self-organizing teams, one of the hardest things for their (former?) managers is to pass power on to the team. Power as in “the possibility, ability and duty to take decisions”. If you pass a decision on, you have to let go of your “solution”. There are infinite solutions out there. Don’t expect the team to pick the exact same one that you would have. The chances are rather slim.

Unfortunately this is how I sometimes see it go down:

Manager thinks: “The solution is obvious. But I’m supposed to empower them, so I can’t just tell them what to do.”
Manager to team: “It’s your decision. Figure It out. You can do it.”
Team goes and figures it out.
Team to manager animatedly: “Look, here’s our solution :)”
Manager: “Umm, no. No, it ain’t. <Some leading questions> It’s your decision. Figure It out.”
Team goes and figures it out. Again.
Team warily: “Sooo. Here’s our solution attempt.”
Manager: “Umm, wouldn’t it make sense to … <Some more leading questions>”
“Together” they arrive at a new solution.
Team is quietly steaming.

This is the opposite of empowerment. Having to reverse engineer a fixed solution by trial and error is painful, disheartening and teaches a terrible lesson. As someone who used to be on the receiving end of this, I’d love for the manager to just straight out say what they want. They are the boss. It’s okay for them to dictate the solution, if there’s no wriggle room. But making teams guess over 3 rounds, because they don’t want to dictate a solution? That achieves the opposite of want they intended. Plus, they blur the line. It becomes harder for teams to tell when they really own the solution and when they secretly don’t.

Sometimes the solution mismatch stems from the manager having more information than the team. As the team, strive to become good at asking questions about constraints.

As the manager pass information on to your team as soon as you notice they’re missing. If it’s classified information, you probably shouldn’t that particular decision on to the team.

And check out Delegation Poker. It can help managers and teams figure out, how much power is really conveyed for each pending decision.

Inspiring Organisation: Premium Cola

Recently I got to see a talk by Uwe Lübbermann. He is the “central coordinator” of Premium Cola. He founded and runs Premium Cola with a so-called “operating system”, which he has already exported to other companies. Well, companies is not really the right term, because they all work very differently from what is considered normal:

  • They don’t have any offices or own means of production
  • They don’t have contracts
  • They treat everyone in their eco system – employees, truck drivers, beverage grocers, Cola production, … – as partners and equals
  • All their costs and revenue is public
  • They limit their annual growth

Within the system of capitalism, they manage to do something completely different. If you like the concept of Buurtzorg , Premium Cola’s operating system should be right up your alley!

Here’s an article with more information about Premium Cola.

And if Uwe is ever giving a talk in your vicinitiy, go watch it!

Ritual Dissent

At sipgate we sometimes are too nice to each other. That might sound like a luxurious “problem” if you’ve have to weather a tough company climate, but it can indeed be a problem. As in, we don’t shoot down ideas that aren’t that well thought out. Or we proceed with projects that only one person is really excited about and all others think “Meh” quietly to themselves.

What has really helped us to challenge and improve ideas is a technique called “Ritual Dissent”. It works like this:

One person pitches their idea to the others. Then the pitcher turns around, so that their back is to the group. The others then have to point out weaknesses and flaws in the concept (dissent) or can suggest alternatives (assent). They are not allowed to say anything positive!

Of course, the dissent should be something the pitcher can work with. “This is the worst concept I’ve seen today” fulfils the rule of “not positive” but the pitcher can’t use it at all. It’s bad how? In what aspect? Only speak if the pitcher can use your feedback to improve instead of slumping their shoulders in defeat.

The great thing about Ritual Dissent is that it a) absolves feedback givers from having to find positive aspects for a “sandwich feedback” and b) it gives you permission to criticize. It’s what we want here! You’re not a nagging nay-sayer if you point out flaws!

Usually you do Ritual Dissent when several people will present there respective ideas. One person pitches. The others dissent. Next person pitches.

It’s less personal if you know that after you it will be another one’s turn. This is also the official reason why the pitcher turns their back to the group, i.e. that it will feel less personal. My hypothesis is that as the pitcher you have to just absorb the feedback and aren’t tempted to argue your case. And as the dissenter it’s easier to say hard things because you don’t have to see the pitcher’s face twitch when you point out that their “baby” has three legs and no arms.

I find this to be a very valuable technique to improve ideas, concepts and designs in an environment reluctant to voice harsh criticism. Have you tried it?

Open Friday – Lernende Organisation mit Open Spaces

[English summary: I’ve translated my experience reports about regular, company-wide Open Spaces into German.]

Bei sipgate haben wir supergute Erfahrungen mit regelmäßigen (alle 2 Wochen) Open Spaces gemacht. Auf Englisch habe ich dazu schon mehrfach gesprochen und geschrieben. Inzwischen gibt es den kompletten Erfahrungsbericht auch auf Deutsch, bei der Informaktik Akuell. Wenn Dich nur das Ergebnis und weniger der Weg dahin interessiert, findest Du im sipgate-Blog eine kürzere Variante.

Open-Space-Unconferences_Wall-Skills

 

 

Eat together!

A friend of mine works in an engineering company with 2 offices. The big original one where the founder roams and a smaller, newer one, where my friend works. The 2 offices aren’t far apart geographically, but far enough to develop separate culture.

Her office has a Theory Y mindset, the big one a Theory X one. For example in her office people take a joint breakfast break and often also take lunch together. Her boss frowns on the breakfast break as a waste of time.

It’s too bad he hasn’t yet seen the value of informal time spent across all roles of the company. All the little things that never become problems because people clarify them over tasty dishes, often without noticing. The hours of frustration you save because a colleague gave you the exactly right hint over lunch. The latter one alone easily makes up for the time wasted invested.

Lunch at sipgate

I’m lucky enough to work in a company that values social experiences. So much so, that we build a restaurant. And shot a video about it. For the German speaking among you: Enjoy!

Did I mention we’re hiring? 😉

Thank God it’s Open Friday – Agile 2015

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

Oh wow, back from Agile 2015. My first Agile. What a ride, so full of impressions and met so many interesting people! I feel about a gazillion blog posts coming on 🙂

But for starters, here’s the paper for my talk “Thank God it’s Open Friday!”. I recommend the paper over the slides, because it’s self-contained. The slides miss a lot of commentary, even with speaker notes.

What is this “Open Friday” thing you ask?

“Every other Friday all employees in our company hold an Open Space. It’s how we spread knowledge, solve problems, gather ideas and superseded meetings.” – Me, 2015
Update: Here are the questions people have asked me about Open Friday. The answers, too 😉