Expect turnover – Agile transitions and changes in the work force

The other day, I’ve had 3 visitors from a large corporation. Since one of them was from HR we talked a lot about these topics and exchanged our hiring processes. One hidden criterium of theirs is that people must be “leidensfähig” to a certain extent.

“Leidensfähig” is a beautiful German word that literally translates to “ able to suffer”. If you’re leidensfähig, you are able to put up with a certain amount of (corporate) bullshit without quitting. We cast for the exact opposite. If something sucks, it’s your responsibility to go fix it.

Expect turnover

It reminded me of how much hiring criteria differ between companies and that it’s really no wonder that turnover is to be expected during any big change. You’ve hired people to work in a certain way and – boom – now you ask them to work in a different way. Not all employees can and want to work in a new way. It’s not their fault either. It’s just people and companies going their separate ways. It’s not them, it’s not the company. They are just not a good match for each other anymore .

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

“Too many topic ideas leave too little time to talk in-depth” – Gnarly Retrospecive Problems

Scrum Master Ellen wrote me about a problem with running out of time during retrospectives:

“I have a team that is quite elaborate in their retrospectives especially in the gathering data and insights part. Perfect, but this leaves less time for deciding what to do and transforming problems we face into action. Do you have suggestions on how to keep the teams focused on only the really important things they want to fix in the next sprint? The thing I try now is to minimize the number of post-its each person adds, but I would love to have some other suggestions.”

Yep, I definitely know that problem quite well. As I facilitate short retros (45-90 minutes) time is always an issue. Even small teams can come up with a multitude of topic ideas. And the more topics a team suggests, the fewer it can actually talk about.

Regarding minimizing stickies, there are at least 3 different ways to do it, all with their own disadvantages:

A) Give only very little time to write down topics
Con: Stresses some people

B) Limit the number of stickies to write (“Write 3 stickies with your most important topics”)
Con: Gives some people analysis paralysis

C) After writing, tell people to go through their stickies and only keep a certain amount (“Please count your stickies. If you’ve got more than 5, only keep the 5 most important ones and discard the others”)
Con: People have to throw away some of their work

I choose depending on the team, i.e. which con I think they can best live with. (I use C) most often.)

Alternatively, you can try to shorten the time that people take to present their topics. By 1) making them aware of the time problem and 2) intervening whenever people dig into a problem pre-maturely and start discussing instead of moving on to introduce the next sticky.

In my context (mature teams, very short retros of 60min every 2 weeks) “Gather data” is strictly for broadcasting: Everybody hangs up their sticky ideas, says one sentence per sticky and that’s it. Clarifying questions are okay, but no going into detail. Participants are great at reigning themselves in, when they go too deep into a topic. Everybody’s used to postponing until after dot-voting and then discuss the important topics.

That’s certainly learned behaviour. I’ve recently started to freelance on the side and now sometimes introduce retrospectives in other companies that are new to it. I noticed how easily participants get into details before it is clear, which topics are the most important ones. I stepped in a number of times. That’s when I realised how rarely (if ever) this happens at “home”.

One way to help a team help each other stay on track is with Jeff Patton’s Cups.

Hopefully, some of these ideas help you carve out more time for the important topics 🙂

PS: Now I wonder what a “normal” amount of topics per retro is. Across several teams I found we typically cover 2-3 topics in a 45-75 minute retro. It’s 2 way more often than 3.

I think it used to be more when we were less mature, but that’s might also due to the less than optimal method we used back then…

How many is “normal” in your retros? And how long are those retros?

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

How we take decisions without managers and teamleads

We don’t have any middle management at sipgate. There is still a boss – bosses even, plural – and we look to them for strategy and long term planning, but they are not involved in day to day decisions. In our ~12 product teams no one is the boss of anyone else. This often prompts the question “So, how do you take decisions around here? Who decides things?”

That’s an excellent question that I had absolutely no answer for, the first time I got it. I had never thought about it, because decisions just … get taken. But how? And by whom?

Once I started thinking about it, I realized that the answer is not straightforward, because it’s always different groups of people that take any given decision. The guiding principle is:

We want decisions to be taken by the people who have the most information to make a good decision.
Sometimes that is a single person. More often it’s a pair or a team. Decisions that are more far-reaching but affect mostly one job role can be taken by this role’s community, e.g. all developers or all UX designers.

What happens when people can’t agree?

Our teams have many degrees of autonomy to take decisions about “their” product. Most decisions are taken together. When the team can’t agree the decision falls back onto the most appropriate role: The Product Owner has last say on product feature, time budget etc. Developers have last say on technical implementation etc.

A smart team and Product Owner take care not to force too many issues, because that always leads to trouble down the road. Resentful people are not doing their best work. Fortunately, we can usually agree at least on a general direction

What about company-wide decisions?

In most cases, the group that can take the best decision overlaps with the group of people that will be affected by the decision. The smaller the overlap, the more you need to consult with the people that will be affected.

A popular way to decide something with the input of many people is to discuss it in an Open Friday session. Let’s look at a decision from about 2 years ago:

At sipgate teams can go out on team events to foster team spirit. A typical team event is an activity (escape room, cooking class, minigolf, …) + restaurant + booze. Up to a certain amount, this is on the company’s dime.

Now, our colleagues in accounting had noticed a worrying trend and pitched the following session: “Last year, we’ve had 1 team building event in the whole year. Now it’s April and we’ve already received 5 team building events. We suspect some of these to be regular ol’ team events but we can’t and don’t want to decide which is which. We’d like to talk about how to handle this.

Wait a minute! “Team building event”? How is that different from a “team event”? Turns out, a team event is is your own private fun, whereas a team building event counts as company time, i.e. you can go home earlier if your team building day is longer than usual.

Anyway, at the time of the session, about 12 people from all over the company met and a short Q&A and some discussion we came up with a list of criteria so that every team can decide whether they are planning a team event or a team building event.

[A team building event is for teams that are in trouble. They typically last a day. You probably aren’t looking forward to them (see “team in trouble”). A team event is typically in the evening and you are happy to invest your own time because your team is awesome!]

Took less than 1 hour and those criteria still stand.

You made a money-related decision just like that?

Well, in this discussion a new colleague wanted to “delegate” the decision to a higher level: “Management has to decide that! That is not something that we can decide!”.

Not true. I could vividly imagine what would happen if we really bothered a higher level with that. The higher level would have been C-level, since there’s only 2 levels, C-level and everyone else. They would have looked at us like we’re crazy people and told us to decide for ourselves. They don’t want to think about minor operational stuff like that.

The same applies to at least 90% of issues that I’ve heard the “someone higher up has to decide that” bit by newbies. We absolutely can take many of these decisions and we do. We usually have more information and are also the ones affected.

It’s part of acclimatizing at sipgate to stop relying on higher ups. You can take your own decisions. You also have to. With great power comes great resonsibility.

What are the drawbacks of this distributed decision-making?

Problems arise, whenever it’s unclear who are the best people to take a decision. Depending on  personality some drop issues, others talk to a looot of people to try to reach a decision.

Another is that we are used to great autonomy. When team decisions are overridden by C-level it’s usually not taken well.

You might think that “You have to discuss, so this approach takes longer” is also an issue. I don’t think it  slows you down for two reasons:

  • A lot of decisions affect only 1 or 2 people and you can take those without asking anyone. You need a software tool for 50 bucks that will save you 1h per month? Buy it! The time to run this by anyone else is more expensive than the tool
  • Execution is faster, because we all agreed on what we want to do, instead of dragging our heals on executing something we had no say in and think is a stupid idea by someone ignorant

Would I trade this for a traditional top-down decision making process?

Hell, no! I admit, there were times (~2011) when I longed for someone to swoop in and just take a decision so that we’re done discussing. Now, I’m very happy that the powers that be deliberately created a decision vacuum until we had all learned to take widely supported decisions together.

Overall, I think this appoach makes us faster and results in much better decisions.

Addendum: I’ve just realized that this can only work because we’ve got a strong sense of “how we do things around here”.

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

Enjoy the Silence

My proudest moment as a facilitator was when I did nothing.

Well, outwardly I did nothing. Inwardly I held the silence. I’m a chatty person. Shutting up is hard for me. Letting silence be. Enduring it. I counted from 10 to 20 in my head and when I had reached 20 I started over. I looked at them intently although they had technically already spoken about the problem. And then the magic happened!

The person that had talked before spoke up again. An additional thought on the topic that made her very concerned. We spend quite some time talking about what she had brought up. It was that important.

I don’t think she would have addressed the issue at all without that long pause. We would have nodded at each other in agreement, closed the topic and started another one, with that issue simmering on. Festering.

Very interesting things happen when you don’t fill an awkward silence with chatter. You’ll hear things that others wouldn’t have come forward with on their own. You’ll give others space to think through thoughts they hadn’t thought through before. It’s magical. Enjoy the silence!

What was your proudest moment as a facilitator?

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

Mistakes were made – 3 things not to do when going agile

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.

What are things that didn’t work out for you? What do you do now?

The Missing Manual for Retromat: 5 tricks that might come in handy

Every once in a while I realise that others aren’t aware of certain features in Retromat. These feature are not exactly hidden, but they are not super obvious either. I’d like to share them with you, just in case there’s one you didn’t know.

0. Step through all activities in a phase with the arrows

For completeness sake, let’s start with the most obvious one. I won’t even count these as a trick: The arrows:

Because in a random plan the activtities will not work with each other, the arrows let you step through all activities in a given phase. Pick activities that fit with each other. If you’re a beginner, try this plan.

1. Click on a phase’s name to see all its activities

The arrows are too slow? You want to quickly scan all activities in a phase? Just click the phase’s name.

2. Check out a single activity by clicking on its ID

Let’s say you want to share a single activity with a colleague: Click on its ID and voila 🙂

3. Click those buttons!

Noticed the row of buttons?

This one generates a new random plan:

It’s supposed to be a wheel of fortune, in case you were wondering.

And then there’s the search buttons:

The left-hand button is just there to be a visible way to search for a specific ID.

The right-hand button lets you search for words and IDs. The search algorithm looks at  titles, summaries and descriptions. If you enter more than one word any one of them is enough for a match. It’s an “or” search, not an “and” search.

As soon as you enter a number as part of your search term, you’ll get the activity of the same ID among the search results.

I’ve been wanting to kick out the ID search button for years but have never really gotten around to it. It’s not really needed.

4. Change the ID to get the activities into a custom order

From the moment I first conceived Retromat I wanted plans to be easily shareable. That’s why each plan has an ID. And you can change the order of activities by changing the ID around. You can change the ID either in the browser’s URL field or by clicking into the Plan ID:

This comes in really handy, when you want to break out of the 5 phases. You see, Retromat is somewhat limited in that each activity can only belong to one phase, although many of them arguably fit into several. If you want to repurpose an activity for a different phase than I sorted it in, go ahead, change the IDs around and press enter!

5. Something completely different – An Easter Egg

There’s another way to forgo phases: Did you know that Retromat has a secret phase called “Something completely different”? You’ve got a 1 in 25 chance of getting a plan with just 1 single activity – one from this extra phase.

Wanna take a peak at these unconventional activities? Here’s a list of all activties in “Something completely different”. You’re welcome 😉

Were any of these new for you? Did I not mention something you would have liked to see? Tell me in the comments!

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

And what else?

Have you ever had to broach a difficult topic? You prepare, you make notes and you head for a 1:1. You start by talking about various smaller topics. You avoid the big fat whopper of a topic that you’ve been worrying about. Time is ticking by. You’re stalling. Then at the end of the – inconsequential –  conversation, there’s this little pause when you would usually leave and you have that inner debate on whether to mention THE TOPIC or not.

Well, I can’t help you with plucking up the courage to mention the topic. But I can help you if you’re on the other side of this potential conversation. That is, I’ve got advice for you if you would you like to hear about a serious problem sooner rather than later.

"And what else?” teases out difficult topics

It’s simple. Ask “And what else?”. Ask it often. It invites hesitantly shared information.

Oh, and yes, “And what else?“ is a better phrase to use than “Is there anything else?” It’s open instead of closed and errs on the side of implying that there is indeed something. So, sharing is more likely to happen 🙂

It doesn’t just work in this particular situation. “And what else?” is a great phrase in general, because it gives others the opportunity to reflect and dig a little deeper than the top of their heads. I picked up in an excellent workshop on solution-focused coaching by Sinnvoll Führen.

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

So what? – Look for the real problem

Recently this statement raised my inner alarms: “We’ve got lots of problems! For example, nobody is pair programming.”

Why would this rub me the wrong way? That nobody is pair programming? After all, I am indeed a huge fan of pairing up. I witness this practice’s many benefits every single day at work. But no, that’s not the point. My alarms went off because “lack of pair programming” was presented as an actual problem. It’s not.

Let me repeat that: As much as I love pair programming, not doing it is not a problem in and of itself. Rather, pair programming is a possible solution to a host of problems an organization might be having such as:

And depending on the actual underlying problem there are different solutions available, one of which could be pair programming.

Nobody who’s not already a convert will start pair programming just “because”. Instead go looking for the actual problem. Ask “So what?” That phrase is magical and you can use it repeatedly. Just like there’s the Five Whys, dig deeper with five “So what’s”:

“Our problem is that nobody’s pair programming!”
“So what? Why is that a problem?”
“Nobody knows anybody else’s code. It’s 1 system = 1 developer.”
“So what?”
“Whenever a developer is sick or on holiday development in their area comes to a screeching halt. And there’s always someone sick or on holiday. Makes us super slow to release. And I dread the day someone quits.”
“Well, that does seem like a pickle…”

Okay, it weren’t five “So what’s” because I suck at making up examples but you get the point.

"So what" is a magical phrase to find an actual problem

This is not specific to agile practices either, though Agile folks have a reputation for dogmatism. Here’s a recent example from the field of web analytics: “We’ve got a huge problem: We can’t do cross-domain tracking.” Soooo …? What are the questions I want answers to and that we can’t answer because we lack this?

I’ve learned “So what?” in the context of Henrik Kniberg’s Cause-Effect-Diagrams and have since used it whenever I suspect that a “problem” someone presents is actually their (preferred) solution. It’s the same as with product features:

“Love the Problem, Not Your Solution”
Ash Maurya

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

What is an Agile Mindset? Six years later

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!

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

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!