What’s the point of agile retropspectives? Why do them?

Yesterday I got a question I thought me and others had answered quite exhaustively: “Why would you do retrespectives? What purpose do they serve?” Picture me surprised to come up empty handed after a quick search here on Finding-Marbles. Turns out, I haven’t answered the question here. Which is ironic given that this is the very first topic I cover in my Retrospective workshops for teams that want to get started. I mean why would you learn HOW to do retrospectives if you don’t understand WHY they are beneficial?

So, let’s look at it now. What’s the point of agile retrospectives? Why do we do them? Or more precisely, why do I do them? Why do I think they are valuable?

If I had to answer in one word I’d pick: “Change

The point of a retrospective is to enable change. Improvement. It’s reserved time to look at how we are working together as a team and tweak that. Retros deal with the mushy, human side of work and how to collaborate better. In my opinion, retrospectives enable that in 3 major ways:

  • Allow time for (self-)reflection
    During the daily grind it’s incredibly hard to sit down and ponder your ways of working. Reserved time helps.
  • Create shared understanding in the team
    Everybody sees the world a little bit different. In retrospectives we can find out how differently from me my team mates perceive and interpret events
  • Agree to try new things: action items (or updates to the working agreement)
    Retrospectives give room to think through several improvement ideas and pick one that all team members commit too

If done well, the retrospective itself is already a pretty powerful meeting. Sometimes the increased understanding between team members – knowing what makes the others ‘tick’ – is already a great leap forward. Though, most of the time you will want to end up with concrete action items i.e. experiments. Small things that the team will do to see if it helps with one of their problems.

During any given retrospective you don’t know if an action item will be an improvement. You have to try it out. If it turns out to be an improvement you keep it and build on it. If it’s not, you stop doing it and try something else if the original problem still needs solving.

Attention: implementing action items takes time. If you do retrospectives but nobody ever has time to follow up on the action items people will quickly grow disillusioned. They will stop doing retros because, frankly, there’s no point if nothing ever changes as an effect of the retros. (BTW, Scrum recognizes that and prescribes that the most important action item from the retro is automatically part of the next Sprint Backlog.)

To recap, the benefits of retrospectives are: time to reflect, creating shared understanding and agreeing on action items. All of which hopefully lead to improvements in how the team works together. Doing retros frequently will often allow you to catch and address problems while they’re small and still manageable 🙂

Do the benefits sound good to you? If so, you might be interested in the WHAT of retrospectives now.

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

Scrum Masters and Agile Coaches need an Emergency Fund

Scrum doesn’t fix an organization’s problems. It makes problems glaringly obvious so that you they have a chance to fix them themselves. 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 expanses 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 the Finding Marbles newsletter to get new blog posts in your inbox!

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!

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

Would you like a coconut?

Last week I attended a very enlightening workshop hosted by solution-focused coaches  Veronika Kotrba and Ralph Miarka. Early in the workshop Veronika introduced a superb metaphor for giving advice that nobody asked for. I’ve written about unsolicited advice before, but the coconut-model does a much better and funnier job.

Let’s start with one of the solution-focused tenets: “Everybody is the expert for their own situation”. Based on our experiences we all see the world differently and can never truly know anyone else’s impressions. We each live on our own island and usually don’t know much about the islands of other people.

Bertram's island and Zili's island

Let’s say there are 2 people on their respective islands, Zilli and Kurti. Zilli’s island sports a glorious coconut tree and Zilli looooves coconut. The meat, the milk, the pina colada – she loves all of it!

Kurti’s island on the other hand has fir trees growing. Kurti has never heard of coconuts in his whole life, let alone seen one. What a sad state of affairs! Zilli wants to share the coconut goodness and saves one of her precious coconuts to throw over to Kurti. What do you think how Kurti will react? Grateful?

Zili throws a coconut

Unlikely. Zilli just attacked him with a big stone. Unprovoked! Why would she do that? Kurti has no choice. He has to defend himself!

Bertram raises the shields

Which in turn will anger Zilli. Kurti lets her gift go to waste! That was an excellent coconut! Pfft, she’s never going to share anything with such an ungrateful person!

Not a good exchange at all. Yet, it often plays out like this when someone tries to introduce change. But Zilli could have done better. She could have asked, whether Kurti is interested in trying coconuts. And if he’s not, accept that. And if he is, all the better! She could have shown him how the crack one. The meat, the milk, the pina colada. Chances are that Kurti would have liked some of it.

Questions build bridges

I plan on using this metaphor a lot in the future. I want to pass on what I learn. I hail from a long line of teachers, I can’t help myself. Heck, this blog is nothing but a big pile of coconuts, so that I have an outlet. You’re here on your own free will, so I hope that’s okay with you. And if we meet face to face and I ask “Would you like a coconut?” you know that I’ve got excellent, excellent ( 😉 ) advice that you didn’t exactly ask for. You can say no. That’s okay. It’s why I ask first 🙂

PS: Thanks to Veronika for the flipchart drawings!

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

Why didn’t anyone ever tell me that?

After about 2 or 3 years into my agile journey there was a time when I would listen to a talk or read a book and be like “Yeah, it’s exactly like that! I wish someone had told me 3 years ago! It would have helped me a lot! Why didn’t anyone tell me that?”

The specific information provoking that thought was typically something about people, how they behave and communicate, and how change unfolds in an organization.

After even more time I now have the sneaky suspicion that “they” did tell me that. But I wasn’t ready. The factual information didn’t stick, because it was beyond my horizon. I wonder if there are some things you have to experience yourself, mistakes you have to make and only in hindsight you can appreciate the wisdom of others.

Not sure if that is disheartening (I’d rather learn from others than make mistakes myself) or liberating (we are allowed to fail). All I know is that I’m a lot more patient than I used to be. I can now let others make mistakes they need to make in order to learn. And I try to not push advice on others, when they haven’t asked for it. It’s something, I guess 😉

Solve people problems with data

[This post has been a draft since 2013. Not sure why, it was 95% finished…]

At OOP one presenter asked the audience and thus me: “How did you successfully resolve the biggest challenge in your professional life?”

My answer: “Talking”. Every one else’s? “Conversation”, “Communication”, “Face-to-face-meeting”.

In many ways I’m paid for having conversations: As Jerry Weinberg said, every problem is a people problem – I try to solve these people problems by having conversations or making other people have conversations with each other.

But sometimes that’s not enough. It hit me, that my more successful interactions in crucial situations have not just been about exchanging perspectives. I’ve had data with me. Consequences of behavior expressed as numbers and charts, or even as a price.

When you’re leaning towards the “touchy-feely” end of things, it’s easy to forget how data can make the case for you.

For instance, if a Product Owner receives too many feature requests to implement all of them and is not empowered to reject them, the requests will pile up. If that pile is hidden in a ticket tracker, the problem is invisible. The requesters will just wonder and / or bitch why the developers don’t fulfill their requests, whereas the developers will groan under an impossible workload.

If the PO tracks the requests on a board the problem will at least be visible, when the board overflows. The PO can point to it and make their case. Will this change anyone’s behavior?

Sample Graph: Request VolumeWhat if the PO tracks the incoming vs. the finished tickets to demonstrate how much demand and capacity are out of sync: The yellow line represents the accumulating unsatisfied requests. This is a chart to base a discussion on. Much better than “it’s just too many”. The PO and the stakeholders now see that there’s about 3 too many requests per week and that there’s no way for the developers to ever catch up with the pile. Time to take some decisions.

Data is powerful! Especially if the information not hidden in a sea of numbers. If you want to convince people take the time to coax out the information. Make a fancy chart! You know you want to 😉

Sometimes it’s enough to bring a few numbers to put things into perspective: That you’re not complaining unreasonably. It can help counter the opinions (read “not backed by data”) of people higher up in the food chain.

Whenever I encounter a significant problem I think about how to make it accessible, visible or even palpable* for others who I want to help me solve it.

* There once was a team that inflated a balloon for every ticket they got. Within a week they were up to their knees in balloons, communicating to every one that they got way too many requests. Can’t find the original source 🙁

Talking about failure – Long Way to Lean #1

When I give my talk “Thank God it’s Open Friday!” people always tell me how much they liked hearing about our failures on the way to a solution that works well for us.

It’s surprising to me, because our previous trials with a slack day are only loosely related to the very successful end result. It’s the part of the talk for which I always doubt whether it’s interesting to anyone. That part only exists, because I created the talk for Agile 2015 in the “Experience Report” track. If I had created a “normal” talk I would have only presented our shiny solution. Much like other people tend to present their shiny solution and rarely the way they took to get there.

That’s how we end up showing each other our pretty sides, once we have figured it all out and we hide the hard work and multiple failures it took to get there.

That can be quite intimidating for people who just start working in a better / different way. Like everyone else just flipped a switch and they are the only one’s struggling.

Well, you’re not. sipgate is a fantastic place to work. It has been for about 2 or 3 years. But we started down the agile road in 2010. Now 2016 is nearly upon us. That leaves 3 years that were less than stellar. Some times during these 3 years downright sucked. And I want to tell you of the suckage and the working solutions that we surfaced with. Heck, I might even tell you of the things we still haven’t figured out. It’s not like we don’t have problems anymore…

So, “Long Way to Lean” is gonna be a series here in the blog. It’s loosely based on my talk of the same name.

If you’re interested in specific aspects, let me know in the comments 🙂