How work can be – Stories of agile & lean

Post Category
→Work Hacks

There are many awesome practices we do at sipgate that I love to share with others. But we’ve also gotten some things very wrong, especially in the beginning in 2010. Let me spill the beans about 3 “do not recommend” things for a change 🙂

Double duty Scrum Masters

All the first Scrum Masters were recruited from existing employees and they stayed in their old role for 50% of the time. I was 50% UX designer and the others were developers. This introduces a huge conflict of interest between SM duties and being part of the development team. And the short term “gotta make the sprint goal” interests will nearly always win against long term “team’s gotta learn and improve” interests. Can’t recommend.

Dedicated Scrum Masters are a far better idea.

Afternoon temp teams

Sometimes you need a few special to work on a small project for a short amount of time. We call these task force teams “temp teams”. In the beginning we had temp team members work in their “real” team in the mornings and the temp team in the afternoons. Yeah, multi tasking late that wastes a lot of brain cycles. Can’t recommend.

Nowadays temp teams work together all day. They finish the project faster this way and return to their “real” team.

1 shared backlog for all teams

We had 5 teams, ~3 products and just one backlog. The product owners wanted to flexibly allocate teams to products depending on their changing priorities. Didn’t work out to well. The teams couldn’t identify with any product nor establish testing or coding styles for themselves. A sprint later another team would continue working on “their” feature and “ruin” it.

Today each team only works on one product. They can make it theirs, learn its ins and outs and own successes and failures.

At the end of 2011 I wrote about what makes an agile mindset (in my opinion) and even made a fancy infographic about it:

It concentrates on how people think about their colleagues as humans vs. cogs; whether they have a growth vs. a fixed mindset; iterative product development vs. extensive planning and more. These are all still valid, but I can add another set of examples today.

The past few weeks I have often thought about how conversations changed at sipgate over the course of the years and why it is much easier and more fun to get things done than in the beginning. So here’s a list of behaviours and how they changed:

“It can’t be done!” -> “We have to take X into account”

In the beginning, many a discussion about potential features revolved around a central theme of what we can’t do. There seemed to be an awful lot of things we couldn’t do, despite the fact that we were working with software. If we created it in the first place, we can also change it. Made me so angry, I ranted about it here.

These conversations have been replaced by “If we want to do that we have to take care of X and Y. Oh, and Z will be tricky, too. From the top of my head we look at a two month effort. Is this feature worth two months to us?” A much more productive conversation!

“Clearly A is better!” “No, B!” -> “Can we just try it?”

We used to discuss options endlessly. Fruitless hypothesizing. Nowadays one of us will rather soon ask something along the lines of: “Can we try it out? (What would it cost to just try? Can we decide this or who else would need to take this decision with us? How easy is it to roll this back if it doesn’t work out? Who might we confuse with this?)”

And the number of theories you can easily put into practice to see what happens is surprisingly high. I’d estimate about 90% of the time we realize that, yep, we could just try it out without repercussions.

? -> “Where’s the value to customers?”

Here I’m not sure what was the focus before. I suspect there wasn’t any focus. But nowadays if you want anything done you’re better prepared to explain how it is of value to a customer. Otherwise, fat chance!

As my colleague Mathias so beautifully put it about how we build websites: “At first we designed desktop first, then mobile first, then content first and finally: Purpose first.” What is it that we want the customer to achieve on a given page? This approach makes decisions and trade-offs clearer and points you into the direction you need to take.

Summary: Appreciative and constructive

In general the whole company’s vibe has become much more appreciative and constructive. There are hardly any cynics left. Instead we’re pointing out what’s already going well and look for solutions where it’s not. Most days, anyway. Nobody’s perfect 😉
It is a highly satisfying way to work!

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.

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.

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.

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.

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 →

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

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 →

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:

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.

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?

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.

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 😉