How to transition from Set the Stage to Gather Data in retrospectives

Here’s another interesting question about retrospectives I got in my inbox, this time from Claudia: 

I just became a Scrum Master and will have my first Retrospective ever. What I find difficult for the beginning – I’m sure this will change after doing some Retros – is the transition from Set the Stage to Gather Data. After setting the stage, how do I go the Gather Data? Do I simply say “thank you, now, we’ll continue to gather data…“ or do I comment anything from Set the Stage to Gather Data.

[If you are new to retrospective and have never heard about the phases you can find out more here.]

Questions like these are great, because they make me examine something that I don’t consciously think about and “just do”. So yeah, how do the heck do I frame the transition? As always, the answer is: It depends 😉

It depends on what I want to achieve with “Set the Stage” (StS). Let’s look at the different cases:

Default case: I want everyone to speak, preferably about something positive and true and relevant to the last iteration

In this case, yes, most of the time it is close to “thank you, now, we’ll continue with gathering data…“ I wouldn’t use that exact phrasing because it implies that the 1st phases content is throwaway, when it reveals something about the last iteration. I can’t remember ever picking a starting activity solely for the fun of it… 

My default opening method is a question that goes around the circle. Here are some of these questions and a transition to “Gather Data” that lends itself to that question:

  • What was your biggest insight during the last sprint?
    -> Thank you! Now let’s look into what other observations you have made with $activity.
  • If the last sprint had been a restaurant, what kind of restaurant had it been
    ->
    Very creative, thank you! Let’s go into more detail now …
  • Describe the last sprint in 3 words
    ->
    Now that we’ve had a summary of the sprint, let’s get more verbose…

Of course, the transition has to also match the activity you’re leading to in “Gather Data” (GD). But yeah, usually the sticky notes from StS just keep hanging on a board and are not re-used. If people have the same point again for GD, they can rewrite the sticky or re-hang the existing sticky note. I don’t care either way.

Special case: Testing the waters – with a new team or in a conflict situation 

When I facilitate for a team for the first time or in a conflict situation I like to test the waters with ESVP: Do people want to be here? How much engagement can I expect from them?

If I expect problems, I might use Constellation  or Team Radar to explore questions like “How likely are you to speak openly?”. It might be necessary to adapt these to a written form that participants fill in anonymously.

The important thing is that you have to be willing to deal with problems that come up. What if half the participants are Prisoners – How will handle it? What if nobody dares to speak openly – What will you do?

In short, you’ll have to have at least a rough idea of a Plan B. The more problems you expect, the more solid your Plan B needs to be.

Btw, “normal” opening rounds and retro activities can also derail, either because something “traumatic” happened to a single person (divorce, sick loved one, …) or the team as a whole (someone being fired, new boss, …) that you hadn’t been aware off. In these cases, don’t try to follow your original plan. The retro is not an item to tick off a list. Stay calm, sometimes it’s okay to just let people talk. But I digress …

Special case: Outcome Expectations

Related to the previous case: Some activities are about the retro on a meta level, e.g. asking for Outcome Expectations. I’ll try to help meet the expectations or at the very least check if they’ve been met or not throughout the retro.

Special case: StS is already data heavy

There are some data heavy StS activities in Retromat that can easily be fleshed out for use in GD, e.g. Amazon Review or Postcards. Don’t be limited by the phase that is assigned in Retromat. There are many activities that can arguably that also fit into a different category.

Actually, when you look at my retrospectives individually, you’ll usually find only 4 to 4.5 distinct phases in them. The middle three phases kind of bleed into each other. Which one I stress varies. But whatever I do, you can spot Lean Coffee in each one of them, just rarely as a standalone technique.

(If you plan your retrospectives with Retromat, you can get around the strict “5 phases” layout by manually changing the IDs in the URL and hitting enter.)

Anyway, the above are all the special cases I can currently think of. Do you have any to add? How do you transitien between StS and GD?

Thank you for the question, Claudia! It was fun to think about this!

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

My most important retrospectives were horrible

I’ve got a confession to make: I think fun in retrospectives is overrated. And I never bring cookies, when I facilitate.

Don’t get me wrong, I prefer having a good time to moping about and yes, I prefer participants to be in a good mood. Light hearted people are more creative and willing to try new things.

But all my most important retrospectives – the ones I still remember years later – were horrible! Or at the very least deeply uncomfortable. That holds true regardless of whether I facilitated or was a regular participant.

All my most important retrospectives were horrible

The important retrospectives, the ones that really counted and made a profound difference were about troubling topics: When something or someone wasn’t working out despite everyones best efforts. They had a big impact like teams dissolving; people leaving teams or even the company. That category of events.

Something like that is decidedly not fun. But it’s necessary to have these conversations. I’m grateful to people who have the guts to bring up the crucial topics even if it hurts in that moment. After the dust has settled everyone is better off, because a harmful situation has turned into a new beginning. And work in general, not just that the retrospective, has a chance to be fun again.

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

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 to deliver a project early

My Facilitation Mindset

It all started with a tweet by Tobias Mayer:

“Don’t make assumptions” says one school of wisdom, “Assume positive intent” says another. I choose the first. You?

I’m a card bearing member of the second tribe (at least I thought I was) so I answered:

The second one. Makes me kinder.

Going into difficult conversations assuming positive intent has rarely left me disappointed.

Or as Gitte Klitgaard so beautifully put it:

I find that I get what I expect. So if I expect good, I get good.

My experience is exactly the same. Whenever I don’t manage to assume positive intent and give in to blaming thoughts it leads to more disappointment. My beliefs always always leak into what I say and how I say it.

That’s why I ask someone else to facilitate / mediate in my place when I cannot honestly assume positive intent for each party.

The “don’t assume anything” school of thought has never helped me to prep angry people for constructive conversations. When someone thinks others to be malicious, countering their theories by saying “You don’t know that. Don’t just assume that” only helps for about 2 seconds:

They rake a hand through their hair and say “Yeah, I guess you’re right. I don’t know that for sure.” Pause for effect. “But I swear, they’re just doing that to fuck with us!” Aaaand, back to square one.

What did help multiple times is giving a couple of scenarios in which the enraging behaviour is a result of good helpful intentions of the other party and doesn’t manifest their evil and / or stupid nature.

Giving examples of how something might have had positive intent opens the door to really talk. I’ve established a possible alternate reality 🙂

What’s really going on is something we can try to find out during the facilitated conversation.

After I laid out these thoughts, Tobias remarked:

Talking “of how this might have had positive intent” is very different to making the assumption, isn’t it?

Huh? Hm, I guess that’s true. Apparently I fall inbetween the two schools of thought and my mindset when preparing to facilitate is “I assume that positive intent is possible (while not actually assuming any particular motive)”. And I can come up with at least 2 positive intent scenario for any given situation.

Assume positive intent is possible

Learned something about myself there. It’s a mindset that has served me well so far. What’s your mindset for crucial conversations?

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.

“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 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

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