Host Leadership is the better metaphor

Whenever someone mentions “Servant Leadership” it triggers an almost Pavlovian reflex in me to say: “Have you heard of ‘Host Leadership’? IMHO it’s the much better metaphor for Scrum Master work.”Host-Leadership

Part of SM work is enforcing rules. How can you do that as a servant? The metaphor breaks. As a host it makes perfect sense: You have to make sure that everybody is having a great time and not one person ruining it for many. As the host you set house rules.

Despite being a big fan I haden’t even mentioned Host Leadership in this blog, yet. Until now :) If you’d like to know more, here’s the 6 roles of Host Leadership and the official webpage for Host Leadership.

Open Up Solution Space by Reframing

Last year I shared Reframing advice from Esther Derby, about how you can change your own thinking about “difficult” people.

This year it’s advice from Veronika Kotrba and Ralph Miarka about how to open up solution space in other people’s thinking:

When someone says “My boss never listens to me” this is a very definite statement. “Never” and “always” imply that it’s a done deal, no use trying. You can open up possibilities by reframing this to “Aha, up until now, you  have not succeeded having your boss listen to you.” “Up until now” introduces the idea that this can change. There’s hope, hooray!

Mein rechter, rechter Platz

[English summary: Armin Schubert suggested a super nice "Set the stage" activity for Retromat that doesn't translate well, so I present it in the original German.]

Immer wieder bekomme ich tolle Vorschläge für Retromat, die ich schweren Herzens ablehnen muss, meistens weil es bereits eine sehr ähnliche Aktivität im Retromaten gibt. Bei der folgenden Idee von Armin Schubert war der Grund, dass die Aktivität nur auf Deutsch funktioniert. Aber wozu habe ich ein Blog ;)

Hier kommt also Armins “Mein rechter, rechter Platz”: Diese Aktivität ist für den Anfang einer Retro und läuft wie folgt ab:

Die Teilnehmer sitzen im Kreis und starten mit dem bekannten Kinderreim “Mein rechter, rechter Platz ist leer, ich wünsche mir den $Name her!” mit einer entscheidenden Änderung im Text:

“Mein rechter, rechter Platz ist voll und der $Name, der ist toll!” Dann noch drei positive Eigenschaften des rechten Nachbarn und schon ist derjenige selbst dran.

Die Idee dazu ist in einer Retrospektive entstanden, weil wir einen schnellen aber positiven Einstieg gesucht haben. Das wirkte am Anfang etwas hölzern, war dann aber ein grosser Erfolg, auf dem im Nachgang immer wieder referenziert wurde.

(Falls jemand den (neuen) Kollegen rechts von sich nicht kennt, kann er gerne die anderen Anwesenden um Hilfe bitten. Hat bei uns mehrfach super funktioniert!)

Thanks for sharing with us, Armin!

My friend, the time clock

This little exchange happened on Twitter:

twitter_no-overtime

I thought the topic might be worth elaborating on, as “no overtime” seems to be a rare thing. It’s time to confess my undying love for our time clock:

Time Clock

Obviously, it’s not its looks that secured the clock my affection. In fact, whenever I take visitors on a tour through the sipgate offices, the time clock is an unexpected sight. An young-ish company with foosball, ping pong and hammocks and then a time clock? Isn’t that a bit backwards?

No, the time clock is what prevents me from working overtime! When I was working trust-based hours, I always did overtime. When there was something to finish, I would stay to finish it, but I wouldn’t leave earlier, when there was nothing immediate to do. I didn’t really keep track of my overtime so I was unsure, when it would have been okay to leave.

At my current workplace, whenever I swipe my little card in front of the time clock to check in or out it tells me if I’m on track for 40h a week or not. You see, the 40h week did not come about because factory owners in the early 1900s thought how nice it would be if everybody got home at a reasonable hour and had 2 days of weekend. No, it happened because Ford’s tests showed that humans have about 40h of productive work per week in them. Working more does not lead to more results. At least not middle and long term. That’s why we don’t want overtime at sipgate at all.

And we follow up on that directive. We talk to colleagues who work too much. Sometimes we force people to take their annual leave (which is 30 days btw. It’s beyond me how anyone gets by with less than 25 days of paid leave. Poor US folks…)

Despite the time clock we don’t have core hours. Everyone can arrive and leave at any time they want. That’s super practical for doctor’s appointments and such. You just have to co-ordinate with your team. Missing the daily stand up should be an exception, because otherwise it’s difficult to work together ;)

Some of our customer supporters works in shifts, staffing a hotline. They have to be on time for their shift. But other than that, we’re pretty free to distribute our time as it fits ours and the company’s needs.

What system is in place at your work? Do you like it?

Cluster stickies next to each other

Here’s another tiny facilitation coconut for something I’ve handled wrong suboptimal in the past:

When it’s clustering time, related stickies often ended up on top of each other. Veronika Kotrba and Ralph Miarka remarked that this is not very appreciative of the bottom sticky and its author. It’s just a tiny detail but it makes sense to me. Most people probably don’t mind, but some might, especially in power imbalanced situations. Since it’s not making things worse for those who don’t mind and makes it better for those who do, I vow to cluster related stickies next to each other from now on.

This will also create a more accurate visualization of support for a topic :)

Letting go of decisions

When building self-organizing teams, one of the hardest things for their (former?) managers is to pass power on to the team. Power as in “the possibility, ability and duty to take decisions”. If you pass a decision on, you have to let go of your “solution”. There are infinite solutions out there. Don’t expect the team to pick the exact same one that you would have. The chances are rather slim.

Unfortunately this is how I sometimes see it go down:

Manager thinks: “The solution is obvious. But I’m supposed to empower them, so I can’t just tell them what to do.”
Manager to team: “It’s your decision. Figure It out. You can do it.”
Team goes and figures it out.
Team to manager animatedly: “Look, here’s our solution :)
Manager: “Umm, no. No, it ain’t. <Some leading questions> It’s your decision. Figure It out.”
Team goes and figures it out. Again.
Team warily: “Sooo. Here’s our solution attempt.”
Manager: “Umm, wouldn’t it make sense to … <Some more leading questions>”
“Together” they arrive at a new solution.
Team is quietly steaming.

This is the opposite of empowerment. Having to reverse engineer a fixed solution by trial and error is painful, disheartening and teaches a terrible lesson. As someone who used to be on the receiving end of this, I’d love for the manager to just straight out say what they want. They are the boss. It’s okay for them to dictate the solution, if there’s no wriggle room. But making teams guess over 3 rounds, because they don’t want to dictate a solution? That achieves the opposite of want they intended. Plus, they blur the line. It becomes harder for teams to tell when they really own the solution and when they secretly don’t.

Sometimes the solution mismatch stems from the manager having more information than the team. As the team, strive to become good at asking questions about constraints.

As the manager pass information on to your team as soon as you notice they’re missing. If it’s classified information, you probably shouldn’t that particular decision on to the team.

And check out Delegation Poker. It can help managers and teams figure out, how much power is really conveyed for each pending decision.

All eyes not on you – Chain Question

As a facilitator, I think it is my job create opportunities for others to speak. I try to keep in the background as much as possible, which isn’t always easy. Participants focus on me more often than I’d like. That is to say, not only when I talk about meta information like instructions, but also when they themselves talk about the subject matter.

One simple technique to connect participants to each other, rather than to you, is to create a questioning chain. This works well when the group forms a circle and there’s a question everyone should answer. As the facilitator you can start it of by asking the question to your neighbour. Then they ask their neighbour on their other side. It works best, when the asker actually waits and listens to the answer ;)

Just like Role Play for One this technique is popular with language teachers. I relearned it in Veronika Kotrba and Ralph Miarka’s workshop on solution-focused coaching.

I hope it’ll help you get attention off of you and on the content your participants bring to the table.

Do you have tricks you’d like to share?

Distributed Retrospectives – Interview with Philipp

People ask me: “How do you best run a remote retrospective with a distributed team?” and I have no idea. I’ve only ever worked with co-located teams. That’s why I started to ask people who actually do run distributed retrospectives. After the interviews with Christoph and Frank I present to you:

Philipp Flenker, Product Owner from Münster

tl;dr A) Most online retro tools are bad. Just try something simple like wikis, Google Docs, etc. before wasting time with research on specialized tools. B) There are activities that don’t work remotely, e.g. anything with movement or anonymity.

Screen Shot 2016-05-25 at 00.02.10

Full Interview

What’s the situation?

Our team consists of 5 people including me. We cover 3 time zones (3 people in Germany, 1 US east coast, 1 US west coast) and 2 languages. We speak English at work.

I’m the PO but since we don’t have a Scrum Master (don’t ask …) I facilitate the retros for our team.

Sprints used to last a month. Last month we switched to 1-week-sprints.

We meet every 6 months to see each other in person. That really helps with “individuals and interactions over processes”.

Do you prepare differently for a remote retro than a co-located one?

Yes, there are a lot of activities that don’t work in our setting:
Anything with metaphor, because of the language barrier. For instance, when using Speedboat, the US colleagues would use all the nautical terms and us Germans couldn’t follow.

Anything with movement is out.

And nothing is anonymous. This one I miss the most. Anonymity is great to have, e.g. for ESVP and we can’t really achieve that. Each input has a name attached to it.

One activity that works well is Learning Matrix. It’s easy to learn and fits a wiki page.
About twice per year we meet in person. I plan these retros very differently! I plan for more honest and more difficult subjects. Participants tend to be too polite in remote retros. There’s very little healthy conflict.

What’s your setup?

First, everybody writes notes on their own computers. We discuss everybody’s notes and then we all paste our notes into a wiki page that I prepare in advance.

We can hear each other, but we don’t have video. We just can’t get a good video feed across 4 company VPNs. Hangouts don’t work at all in the company network. Skype is not very good. [At a former employer we had one remote guy and used Lync. That worked okay.]
The audio works most of the time. We only lose someone’s audio connection once in about 10 retros.

Our biggest challenge is the different time zones. We hold the retro at 5pm German time. One of the German guys is an early riser, so by that time he just wants to be done and head home. In California it’s 8am, in Colorado 9am. And the Colorado guy likes to sleep in. The bio rhythms don’t work out here. Concentration is difficult to maintain. The retro needs to be short, 90 minutes max.

When you’re co-located you can easily spot when someone is wool gathering. In a remote setting you can’t. Especially if you only have audio and people frequently mute themselves.
Retros are still valuable to us. Small changes are better than stagnation.

Do remote retrospectives have any advantage over co-located ones?

No, remote retros are not better than normal ones in any way. But they are better than losing a team member all together by not allowing remote work.

Any tipps for new facilitators of remote retrospectives?

Most tools suck. There are a lot of retro tools out there and I haven’t found any good ones. You just waste time trying them out to assess what they can and cannot do. The wiki page we ended up with, was better than most. Next retro we’ll try out Google Docs. In a Google Doc you can see the others’ cursors and it’s a fair guess that the cursor is where people are reading. So we’ll have more information than with the wiki page.

Thank you very much, Philipp!

You can follow Philipp on Twitter!

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!

Too much of a good thing? Why you don’t have to take part in every method craze.

This post is written by Petra Wille and only translated by Yours Truly. When I read her original German post, I felt vaguely guilty. I loooove methods! Read about them, try them, create summaries and books about them… I want people to know about a lot of possible solutions so that they can pick one that can help with their problem. But I don’t mean for every one to try each and every new method on the block. Let Petra tell us why: 

Are you sometimes lost in a forest of methods? Don’t panic. We’ll offer orientation and 8 tips for your method tool box and point out why it might be good not to try every new method that comes along.

There are more methods than ever

For a product manager in digital product development there are more method and process models to pick from than ever and new ones are added all the time. Be it Business Model Canvas, Product Field, Personas, Story Mapping, Lean User Research or Design Thinking – just to name a few.

The raw attraction of new methods is still strong. You feel their pull and the need try them. The promises of salvations that accompany them raise the bar even more. Maybe that new method is THE ONE. The silver bullet that solves all your problems. THE ONE that just makes everything easy.

Just fill out the new canvas and *zippityzip* your successful product goes online.

We all know: it ain’t that easy.

Despite the host of methods digital products don’t just create themselves. It is work. Because the main job is: “Find a product that’s worth becoming reality, specify it, implement it, and check its success.” That’s a lot of steps and no tool can lessen that burden. “One swallow does not make a summer” so to speak.

Those methods and processes don’t help at all?

Sure they do. They help us. They are support and guide us in product development.

But I daresay that the multitude of methods on offer distracts us from the actual task. On top of that I daresay that frequently switching methods deprive individual POs of something important: The chance to truly learn and improve.

Because you need to use a methods many times over, in different contexts and for different product ideas, to learn their true strengths and weaknesses. And only given time you can gain important insights and deep unterstanding. “Practise makes perfect.” is not a saying for nothing.

Even if you’re not going to invest the 10.000 hours described by Malcolm Gladwell in his book “Outliers: The Story of Success”, it makes sense to try a method more than once.

Let’s assume you pick Storymapping. You could start by using it during a discovery phase to structure requirements. With the next product you can use it to create a roadmap or use the storymap for status updates. Little by little you understand what a method can and cannot do, if you like it and if its effect lasts.

For that reason alone it’s not a good idea to drop everything to try a new way. The agile manifesto continues to hold: “Individuals and interactions over processes and tools” – meaning real work with the team, users and stakeholders should always take precedent before constant experimenting.

I know from consulting in product organisations that it’s not always easy. The latest method is a status symbol to some extent.

But how do you keep the balance? What methods do you really need?

An approach – 8 tips for your method tool box

To guide through the forest of methods I’ve made the following list. It’ll help you figure out whether your tool box is already well equipped or if you’ve got a void to fill.

Starting – building a new product

1. Pick a method das gives a structure and steers you in a certain direction. These methods should help to cover all important steps in product development. Examples: Produkt Design SprintUser Experience Design ProcessProduct Discovery

2. As soon as you’ve set the course you have to ask the right questions. Again, there’s cheat sheets for that – Beispiele: Business Model CanvasProduct Field10-Question-Business-Assessment

Structure – kill complexity!

3. It’s an important PO job to slice complex requirements and sequences until they are doable.  You need a method for that. Examples:  StorymappingJob-to-be-done.

4. Additionally you should choose a method to prioritise transparently. Examples: Priority PokerKANO-AnalysKosten/Nutzen-Bewertung.

Telling stories – Images in our heads

Here I go into detail about why this is important <LINK>. Long story short:  you can only create a vision of your product in other people’s heads if you’ve got one in your own. And that’s the prerequisite to eventually holding a finished product in your hands.

5. To ease the transfer of visions from head to head, it helps to have a method to speak about users as vivid and lively as possible. Examples: PersonasUsertests – the audience: the whole team.

6. Additionally you should make your product palpable. For this you can use: clickable prototypes, designs. Of course these have to be accessible for team members and stake holders!

Track progress

7. Choose a method that helps visualize the current state of the project / product development. What is done and what is still left to design or implement. Examples: Outcome or Output Product RoadmapsTaskboards, Storymaps.

Inspect & Adapt

8. Inspect & Adapt is an agile principle <LINK> and should also apply for your chosen methods: Try it, observe what changes / improves, try it in different situation and choose carefully whether to permanently keep this method in your tool box or to discard it. And when a method proves its merit, it may well stick around for a while.

Conclusion

Properly using a method do not a finished product make and those who want to truly understand a method have to stick with it and use it more than once.

Relax, if you create great products with your favorite methods you can safely ignore most of the latest methods trends.

If you like this post, you can follow Petra Wille on Twitter!