Examples for Swarming beyond the team

When I first learned about Kanban, I also learned about “Swarming”. Swarming is when the whole team pitches in to work on the same thing. That same thing is often a blocking task that WIP limits helped surface. Can’t work on “your” tasks because  you reached the WIP limit? Go help clear that blocking task up ahead!

Swarming with a team is not unusual and works pretty well. Some teams try to always work on only one story together so they’re swarming non-stop. And you can turn up the magic and swarm with large parts of the company.

Swarming cuts a big, intimidating mountain for a few people into realistic hills for many people.

Let me give you three examples of what you can achieve if you join forces and people do tasks outside of their normal job description.

1) Patch all the code

Some years ago we had a legacy product that was in use and earning money while not being actively maintained. Suddenly a wild security hole was revealed. It was a problem for everyone using that version of the specific language we were using. (Yes, you’re right, it was PHP.)

Not fixing the bug would have been irresponsible. How could we make it secure again, given that no team was taking care of the product and nobody really knew the code base anymore?

Drag 3 developers from their teams and go at it for a month? Takes long and these people are missing in their respective teams. And you make these 3 people rather unhappy. No, let’s stop and fix. Let’s take 2 days with all developers, spread the burden evenly and get it over with.

Fortunately the bug was least easy to search for. Two developers prepared a big board with a slip of paper for each and every instance of the bug in the legacy code base.

On Monday morning all developers met and paired up – one person with faint memories of the code base and a newer hire. Each pair took a slip and went on their merry way. All developers together finished that task within 2 days and with a high sense of community.

2) sipgate calling

After handling outstanding payments pretty badly for years, we decided to wow our customers in a commonly negative situation. Instead of passing late payers to a debt collection company we switched to writing friendly “Hey, maybe you forgot to pay us?” emails.

As part of switching from old to new way of handling we wanted to personally call about 200 customers with overdue payments. 200 is a lot of calls for the 3-person team that was wowifying our reminder process. 67 calls per person is daunting.

That’s why they asked the whole company to volunteer. They asked for people willing to help call customers at a certain time and date. They kicked it off with a short training and then some 20 people were calling up customers, nicely asking to update payment details. 10 calls per person is a lot more doable than 67.

3) Got a minute? Answer a ticket

In times of needs you can ask for quick help on Yammer. Sometimes customer support tickets pile up. That can be due to an incident or unusually few people to tackle tickets or both. In these cases you can rally the troops:

“Due to $reasons we have 4 times as many tickets as we normally do. We’re a bit overwhelmed. If you’ve got a spare minute and a Zendesk account, please check if you can resolve any of the tickets in our queue -> link”

At least once, yours truly did have time, read about 30 tickets, decided she could help with about 10 of them. Of these 10 only one popped back open because my answer didn’t help with everything. Which means I closed 9 tickets as a non-customer-support-person. Sweet!

Did I take longer than a proper CS person would have?
Definitely.

Isn’t it wasteful then?
No! Not to me anyway. Sharing your colleagues’ burden in that way strengthens relationships.

Okay not wasteful then, but it’s still inefficient for people to pitch in with tasks they don’t have routine in …
Probably. But then again, I don’t care about being efficient. I care about being effective. And that’s what swarming is. It cuts a big, intimidating mountain for a few people into realistic hills for many people.

And yes, that last example only worked because a lot more people have Zendesk accounts than just customer support people. These licenses are pricey. It’s a trade-off. We opted for the ability to act effectively rather than (money-) efficiency.

To say it with the words of my former choir leader:

Viele Hände, schnelles Ende
Many hands, fast end

Smart chap, that choir leader 🙂

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

Improve your Retrospectives with this 1 weird trick: Liftoffs

When health is concerned, preventing issues altogether is often easier than treating them once they’ve manifested. The same can be said for retrospectives:

In retrospectives we often make up for the fact that we didn't have a liftoff

Either Deborah Hartmann Preuss or Steve Holyer said that in a conversation and it rang true. Very few teams get a proper liftoff and they lose weeks and months of productivity to initial friction. In contrast, a proper liftoff sets up a team for success by laying a solid foundation of agreements and shared understandings. Then the team doesn’t have to spend their retrospectives patching up problems that could have been avoided.

What are liftoffs exactly?

You might know them as kickoffs, jump starts, launches or project starts – a meeting at the beginning of a team coming together and / or starting to work on something. I’m going with the name “liftoff” because of the book by the same name written by Diana Larsen and Ainsley Nies. 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?

Mass Interviews – Menlo #7

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

Cover of Joy, Inc. Menlo does a lot of things different from other companies, Hiring for example. And I don’t mean “different” as in Google, i.e. you get grilled by a succession of 6 people or get interviewed by a good-sized portion of your future team as we do at sipgate. I mean different!

When they decide they need more people they invite 50 people to come interview. All at the same time, regardless of role. They divide the 50 people into pairs and tell them: “The goal for each of you is to make sure your partner gets a second interview.” All pairs get a small task and work on it jointly – only 1 pencil per pair – for 20 minutes. Each of the 25 pairs is observed by a Menlonian. They do 3 20-minute-rounds and rotate pairs and observers each time. After an hour, each candidate paired with 3 different candidates and observed by 3 different Menlonians. The candidates know what awaits them, BTW. They get information describing the hiring process beforehand.

Are you wondering how that works? How can they possibly figure out if someone is good at their job like this? They don’t. It’s not the goal in this first interview. The observers are looking for kindergarten skills: How do you communicate? Can you share? Can you build on someone else’s ideas?

Keep in mind, that at Menlo they pair rigorously. You really don’t wanna be stuck with an annoying pair partner.

Anyway, the candidates return home after the 3 rounds and the Menlonian observers gather. They go through the list of all 50 candidates and their respective 3 observers give a thumbs up or down. All thumbs up? The candidate gets a 2nd “interview”. All thumbs down? The candidate is out. Mixed vote? Discussions of why the vote was cast. At the end of the day, candidates have gotten their feedback.

The 2nd interview is actually a day, during which a candidate pairs with 2 different Menlonians on real work. The third and last round is a 3 week trial run, where they do normal work in the normal pairing rotation (new pair partner every week). Both, round 2 and 3 are paid.

Candidates who make it through all rounds are a really good fit and “bad” hires are very rare.

While the whole process is interesting, I especially love the first role-independent round: You won’t get tempted to bend a “No Jerks” rule for someone who’s technically brilliant. You don’t know whether anyone is brilliant. Jerks get sorted out before we get to role-specific skills.

Walkies – Menlo #6

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

Cover of Joy, Inc. At one point during Menlo Innovations history, the employees decided they would like to stretch their legs and shake up routine by a short walk. Ever since, at 3 pm people gather for “walkies”. A 5-10 minute walk around the vicinity.

AFAIR the book makes no connection to the fact that Menlo resides in the windowless basement of a parking building. I.e. they have no natural light in the office, which makes walkies twice as desirable.

Although my desk happens to be in a spacious, nicely lit overground room that I love, the idea of a daily short walk is very appealing to me. Daylight, extra oxygen, “exercise”, … What’s not to like 😉

 

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.

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? 😉