Is this blog dead?

Let me check: Last post is from August 2018. More than a year ago. Wow, that’s worse than I expected. And that post isn’t even there anymore. It moved over to retromat.org. I guess that settles it, this blog is dead 🙁

It’s not for a lack of topics. I’ve got about 10 drafts and at least another 30 topic ideas I’d like to write about. sipgate (my employer) is a huge source of inspiration! I find something blog-worthy almost every day.

Alas, a day has 24 hours. I’ve got a job and 2 kids and very little energy left once these are taken care of. For a while there it got really bad. The only reason I’m not burned out right now is my excellent doctor (thank you Dr. Enzel!). She practically threw herself in front of me with a big red flashing stop sign.

So yeah, I’m doing much less these days and I’m doing much better. If I figure out a way how my side projects can sustain themselves (i.e. earn money so that I can reduce hours at my real job), I’d love to return to blogging, Retromat and 1-page summaries.

I probably won’t blog here, though. All content related to retrospectives and facilitation will eventually end up on retromat.org/blog. Give me another 5 years (give or take) to move it over …

As for the other posts… No clue where they’ll go yet. I might create a personal website. I’ve already bought corinnabaldauf.de. Now I just need to figure out what I want to do with the site. In the end finding-marbles.com will forward to the new site. One fine day.

I just wanted to make it official. Thank you for your input and coming along for the ride!

All the best, lots of energy and take better care of yourself than I did! Sustainability is key,

Corinna

PS: Just for the record: My job is not stressful and not to blame for the near-burn-out. In fact, I like all aspects of my life. But when you combine all of them, it’s just to much. Used to be more than 100%. I’m aiming for 80% now. Gotta have some slack!

Are you aware of the stories you tell yourself? – Clean Feedback

Have you ever wondered how discussions escalate into shouting matches? Into a series of accusations and “I never said that!” “Yeah, you did!”

Us humans have a tendency to think that the stories we tell ourselves in our heads are the actual factual truths. We are rational beings after all. Or are we? At least we can trust our perceptions, right? Not really, either. We make stuff up all the time.

Point in turn: This – only tangentially related but super-awesome – twitter thread on the brain making shit up. Read it, I’ll wait:

https://twitter.com/Foone/status/1014267515696922624

On a more abstract level it is hard for us to separate between the things we actually see and hear and the story we tell ourselves about it.

A great way to think about this is with the Clean Feedback model by Caitlin Walker. It separates feedback into three components:

  • Evidence
    This is about observable behavior. What have you seen or heard? There is no judgement here.
  • Inference
    What meaning do you make of it? How do you interpret the evidence? What is the story you tell yourself?
  • Impact
    How does that make you feel and behave?

Here’s an example:
“When you are absent-minded in the meeting, the meaning I make of this, is that I’m not important enough to pay attention to, which makes want to avoid you.“

Could you identify the different components? I hope not, cause that was a trap. Being “absent-minded” is not a real observation. It’s already an interpretation. So what are the actual things I’ve seen and heard?

Lets try again:
“When we’re in a meeting and you look on your mobile a lot and pick it up and use it, I assume that I’m not important enough to you and in turn I want to avoid meeting with you. It also makes me sad.”

The tricky bit is that we often think of our inferences as the evidence. But it’s worth it to try to separate it into parts.

Unpacking thoughts like this makes it easier to judge less and stay curious. When shared with the other party it’s easier for them to understand how you arrived at your interpretation of events. And they can set things straight and say what they really meant.

Have you ever tried Clean Feedback? What happens in your conversations when you do?

(I’ve learned about Clean Language and Clean Feedback in this online course by Judy Rees and Olaf Lewitz. It originates in the book “From Contempt to Curiosity” by Caitlin Walker.)

PS: Like what you're reading? Join Corinna's Retromat newsletter!

Ad-Hoc Leadership

[This topic in German will be part of the upcoming 2nd sipgate book \o/].

We don’t have any middle management at sipgate. In our teams nobody is anybody else’s boss. Hearing this, visitors often assume we’re without leaders. In fact, the opposite is true.

(Disclaimer: We do have a hierarchy. It only has 2 levels but it’s there. Our not-so-called C-level sets strategy and everyone else is trying to execute it.)

The roles of Scrum Master and Product Owner have elements of leadership in them. Product Owners have authority about what is being build. They do not have authority about people, their jobs, how the team builds something or the broader organizational setup.

Because nobody gets to lead solely by the power vested in them by some management title, everybody takes the lead sometime. If something is important to you and you don’t take the lead, there’s a chance nobody will. Fortunately, the issue that’s important enough to take action is a different one for different people. So it distributes nicely.

Some people will now object that there is always an informal hierarchy in a team anyway. And someone at the top. After pondering this for months and qualitative surveys at the coffee machine I can’t confirm this. Who’s on top is ever-shifting. Within any given team there are several people that lead, depending on the area in question. UX? Dan. Java? Lara. JavaScript? Kim. We follow their lead because we trust them to best judge the long term consequences of any decision. And yet, they usually don’t decide on their own, but together with others.

I’m pretty sure that half my colleagues would be team leads in other companies. They’ve got all the skills you’re looking for: take responsibility, present results in front of 100+ people, give constructive feedback, facilitate discussions and they’re reflected.

Btw, this post isn’t called “Agile Leadership” for a reason. In my experience, when managers talk about “Agile Leadership”, they babble about “empowerment” while keeping the existing hierarchy and its reporting structure as it is. Yeah, right. Wash me but don’t make me wet, much?

And what do we get from having a flat hierarchy? Everybody takes responsibility. We can take decisions fast. We don’t waste time on political games. Instead we can add value.

PS: Like what you're reading? Join Corinna's Retromat newsletter!

Scrum Masters and Agile Coaches need an Emergency Fund

Scrum doesn’t fix an organization’s problems. It makes problems glaringly obvious so that they have a chance to fix them. Except that “glaringly obvious” is relative and sometimes you still need someone to point to the steaming pile o’ shit of a problem and say it out loud. Sometimes to someone that has the authority to fire the messenger.

As a Scrum Master or agile coach it is part of your job to speak truth to power if necessary. And while it’s certainly a good idea to work on delivery, and phrasing hard truths in a way that make it possible for the recipient to accept and stomach them, there’s still a risk involved.


That’s why you need to have a certain level of independence. And a big part of that independence is money. How can you expose someone to an uncomfortable truth, if that person can fire you from a job you depend on? Depend on for rent, for food, for insurance. For your kid.

It’s a whole lot easier to “have guts” if you have an emergency fund, e.g. 3 to 6 months of living expenses in cash in a bank account. How many months you need depends on how fast you think you can land another job. Ultimately it depends on what you need to feel secure. My need for financial security is high, so we’ve got 12 months. This is just living expenses, not fancy vacations. Not that it’s necessary at my workplace but it’s still a very comforting feeling and helps me not be afraid to say what I think needs saying.

If you don’t have an emergency fund, why not start now? If you can’t save big chunks, chip away at it. Small contributions will also help. Having some money in the bank will make you more effective in you job. And it’ll let you sleep better at night.

PS: Like what you're reading? Join Corinna's Retromat newsletter!

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 Corinna's Retromat newsletter!

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 Corinna's Retromat newsletter!

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?

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 Corinna's Retromat newsletter!

Trump, sad, glad

There are a lot suggestions for Retromat that I can’t  include. Most commonly I decline because an activity is a variation of one that’s already in – just like the following one. I thought it was a fun one (gotta keep a sense of humour in trying times …) and asked its creator Leszek Blacha to publish it here so that you, dear readers, might use it. Those of you outside of the US, anyway.

Trump, sad, glad

This is a variation of “Mad, Sad, Glad” based on a certain Mr. Trump who has a distinct way of talking. Therefore the new categories are “Total disaster”, “So sad”, and “Great (again)”.

Let us know in the comments whether you got laughs for that one. Thank you for sharing, Leszek!

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