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.

PS: Like what you're reading? Join the Finding Marbles newsletter to get new blog posts in your inbox!

“I just can’t get her to engage!” – Gnarly Retrospective Problems

A Scrum Master from the financial industry shared a gnarly retrospective problem with me:

My gnarly problem is that I have one member of my team that doesn’t like to participate in our ceremonies. Her body language shows it, but her words never do. She doesn’t really talk during any of the ceremonies, just tells our manager that she thinks they are a waste of time.

 

I keep trying to play games and spice things up and I’ve tried the boring, to the point method of: works well, not so well, and needs improvement …

 

I just can’t get her to engage! Any help on this?

This seems to be a very common problem. I’ve certainly had it. That’s why I want to share an edited version of my answer here. I try to keep a focus on retrospectives although it seems to be a larger problems.

In a live coaching situation there are loads of good questions to ask: How does the team react? Was there ever a retrospective during which she was engaged? What is she like outside of the retros?

Without knowing many of the specifics, here is some generic advice.

Prologue: We can’t force agile on people

In general, I’ve stopped forcing people. As Marshall Rosenberg said, you cannot make people do anything. We certainly can’t make them “be agile”. If she doesn’t want to be there, she won’t engage. What would happen if she didn’t have to come? How would that affect the team? How does it affect the team now that she’s not engaging?

I’ve often seen teams invest a lot of energy trying to include someone who didn’t really want to be part of it. Not everybody is cut out for agile. Not everybody can be won over. That’s okay. Time will tell if she wants to work in an agile team or not. Sometimes it’s best for everyone if someone leaves the team – As graciously as possible: Let everyone save face. Certainly no mobbing!

But we’re not there yet. Everybody deserves a fair chance and we’re trying to include someone.

Make it worth her time

She gave a reason for her disengagement, at least to the manager. And it’s a valid reason. Veronika Kotrba and Ralph Miarka taught me: “Everybody is the expert for their own situation”. If she thinks it’s a waste of her time, then it’s a waste of her time. Period. The question is: What would make it worth her while?

Continue reading

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 is also available in English.

PS: Like what you're reading? Join the Finding Marbles newsletter to get new blog posts in your inbox!

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

Agile is about usability. So is Clean Code.

Maybe it’s because usability was such a strong focus of mine for such a long time but I feel like most good ideas boil down to usability. It’s kind of my “grand unifying theory of good practices”. To me, Agile Software Development is about providing good usability to the customer (not necessarily the user). Clean Code is about good usability for other developers. They’re both about going the extra mile to make someone else’s life easier.

Agile Software Development is about providing good usability to the customer

Not convinced? Well, I hope it’s easy to see how Clean Code will make code more usable for its future maintainers. That’s why I’ll concentrate on making the case that agile software development is for product development what usability is for product. Continue reading

How to get a very dirty whiteboard sparkly clean

When you let the writing on whiteboards stay on for long enough – say, a couple of month –  dry-erase markers stop being “dry-erase” and start being “leave unwipeable shadowy traces behind”. You’re left with an unsightly board, no matter how often you wipe. Water doesn’t help, at least not against dried up German Edding markers.

Even worse are traces of the slim tape that some teams use to create tables on their boards. Its remains are stickier than candy floss and way uglier.

wepos-kunststoffreiniger Fear not, my colleague Frieda has the miracle cure: Clean your whiteboard with “Wepos Kunstoffreiniger” (= Wepos plastics cleaner) and it will become perfectly clean and smoother than a baby’s butt. Way smoother, actually.

That’s also the catch: After wiping your board with the cleaner you have to wipe it with water. Otherwise no sticky note will stick to the board. Try it, it’s quite fascinating. The sticky notes fall right off of the infinitely smooth surface.

If you don’t have tape traces you can also get rid of the old marker markings with a wet microfibre cloth. Again, kudos to Frieda for finding this trick.

The very last resort, for people without any equipment, is ye olde overwriting trick: Retrace the old writing with a whiteboard marker. The solvents in the marker’s color will also work on the old markings and make them wipeable again. It’s works, it’s just tedious.

Do you have any neat tricks for cleaning dried-in markers?

PS: Like what you're reading? Join the Finding Marbles newsletter to get new blog posts in your inbox!

What can you do if retrospectives repeatedly go sideways?

Not all retrospectives go well. When you support a team as a Scrum master, there are all kinds of strange behaviours or team dynamics that can make retrospectives go sideways, time after time. A facilitator can’t always prevent that. At least I can’t. Not always. Got lots better, though. Over the years I’ve picked up several different angles to get retros back on track (what I think is the “track” anyway). Enjoy:

Choose specific activities

When I started out as a Scrum master I thought my only option was to carefully choose activities to nudge people into the direction I thought they needed to go. And for some situations that works well.

The team acts the victim. Others need to change, there’s nothing they can do? Try Outside In, Circles & Soup, If I were you, …

There is a specific “weak” area they don’t like to look at? Communication Lines for (surprise!) flow of information, Quartering for Tickets, Company Map for Power Dynacmics, …

Talk to individuals

Then I started to address individual behaviour in spontaneous 1:1s whenever I could snatch the person alone. For instance: “I’ve got the impression that you often address me during the retrospective (/standup/…). The information is not for me, it’s important for the others. I would love for you to try to look at the others more.” 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

Need an idea for your next agile retrospective? Or 127? Retromat eBook!

Wow, this was a looooong time in the making, but it’s finally here: The Retromat eBook! So, if you’ve ever wanted to front-load your brain with each and every activity in Retromat, check out the Retromat eBook!
Cover Retromat eBook

Find the perfect fitting activity for your team and situation! Never run the same retrospective twice. Unless you have to bring one back due to popular demand 🙂

While I was at it, I updated and included a lot of useful information around retrospectives, such as the basics, a default planPhase 0 & increasing follow-through on action items and the interview series about remote retrospectives. I hope the result is useful to you 🙂

PS: If you’re the source or submitter of one of the activities currently in Retromat you get a free copy! Just email me! Check the green box below for contact details.)

PPS: Interested in retrospectives? Sign up to the Retromat newsletter to get related news and tricks!

Phase 0 – Checking follow-through in retrospectives

You are probably familiar with the 5 phases of a retrospective, as described in Agile Retrospectives by Esther Derby and Diana Larsen. For years now I sometimes have a block before these 5 phases. I call it “Phase 0” and use it to check up on what happened to the action items the team agreed on in the last retrospective.

After all, retrospectives serve a purpose. In the long run, we want to improve and that means trying out things. If all that ever happens is talking and nothing ever changes due to retros, then why do them? Plus, teams quickly learn to resent retros in this case.
Change happens

I got the idea for Phase 0 from a team that was amazing at follow through: Each retro they added all action items and rule changes (we didn’t know about working agreements back then) to a big on-going flip chart. Each item had a “revisit”-date attached to – the date when the team thought they’d be able to judge the effect (usually 2, 4 or 6 weeks). At the beginning of each retro we would go down the list of all open items that had reached the revisit date and inspect them. Did the team do it? Did it work as intended? If yes, rule changes were made permanent and actions crossed off. If not, the items were consciously dropped or changed.

They had continuous improvement down to an art. It was a joy to facilitate their retros. They devoted a huge chunk of time to this process – 20-30 minutes out of 60. That sounds like a lot (it is!) but it worked very well for them. By the time they had analyzed the list, they usually had covered a lot of the things that bugged them.

I’ve never again seen such consistent follow-up. My Phase 0 is very bare bones compared to this: I bring the list of last retro’s agreements and ask what happened with them, boiling it down to 5 minutes.

This accomplishes several things:

  • It lets the team know that someone cares about what happens. (Whenever I remember to, I’ll also ask during the iteration – genuinely curious, not annoyingly!)
  • I can spot problems with follow-up early. And hopefully the team will notice them too

With a mature team, I’ll do this every once in a while. If I think there’s a problematic pattern, I’ll do it more often. I try my damnedest not to be accusing, but if the team consistently does very little of what they agreed to do, that’s indicative of a problem. Phase 0 lets us find this so that we can work on the lack of follow-through.

Curiously enough, I’m not the only one to come up with an extra phase before the 5 phases of lore. At least two other people have developed similar concepts: Marc Löffler and Judith Andresen. I’ve only recently heard about Marc’s ideas. I’m told it’s also something with checking follow-through but I’m relying on hear-say. I’m much more familiar with Judith’s work and her “Intro” is more elaborate than my Phase 0: She does an Intro at the beginning of every retrospective and it consists of the Agenda, restating the Vegas rule & the Prime Directive, and checking follow-through & team rules.

So, there’s at least 3 people who independently arrived at the concept of checking last retro’s agreements at the beginning of the next one. And those are just the Germans! Is anybody else doing this?

PS: Interested in retrospectives? Sign up to the Retromat newsletter to get related news and tricks!