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!

 

Badass – Making Users Awesome – Book Tip

cover_badassOh wow, where do I even start? “Badass – Making Users Awesome” by Kathy Sierra is a truly enlightening read. It contains ideas I’ve never heard before in the very accessible style of the “Head First” books. Sierra makes the case that in order to build a great product and a loyal customer base you have to make your users better in the use of the domain your product is in. If you make a marketing tool, make your users better marketers. IDE? Help them advance their coding craft.

Badass-Master-Any-Skill_Wall-SkillsTowards that end she devotes about half the book to explain how humans acquire skills and become experts. I got so carried away that I condensed it into a Wall-Skills 1-pagers. But it can’t possibly do justice to the book, so read it. It’s very insightful!

 

Strengths are Weaknesses. Weaknesses are Strengths.

The title is not doublespeak, but something I’ve observed a lot lately. Starting this year, everybody at my work gets feedback every 6 months by 3-5 peers. In the conversations I’ve witnessed so far, there’s a recurring theme:

Our biggest strengths from “What you do great” reappear in the “What you could try” column with a cautionary flag. For example, I’m a generalist. It’s probably my biggest strength. I’m fairly good in a variety of roles. The swiss army knife of employees, if you will. My biggest weakness is that I’m not an expert in anything. Two faces of the same coin.

A colleague of mine had the poles “Very structured. Owning and improving the process” versus “Falling too much in love with the details of the process”.

The feedback conversations nicely illustrate the trade off and sweet spot inherent in any of our traits.

Mark Manson observed the same thing for cultures of countries:

The best part of a country or culture is also usually the worst

What is your strength-weakness pair?

Inspiring Organisation: Premium Cola

Recently I got to see a talk by Uwe Lübbermann. He is the “central coordinator” of Premium ColaHe founded and runs Premium Cola with a so-called “operating system”, which he has already exported to other companies. Well, companies is not really the right term, because they all work very differently from what is considered normal:

  • They don’t have any offices or own means of production
  • They don’t have contracts
  • They treat everyone in their eco system – employees, truck drivers, beverage grocers, Cola production, … – as partners and equals
  • All their costs and revenue is public
  • They limit their annual growth

Within the system of capitalism, they manage to do something completely different. If you like the concept of Buurtzorg , Premium Cola’s operating system should be right up your alley!

Here’s an article with more information about Premium Cola

And if Uwe is ever giving a talk in your vicinitiy, go watch it!

Distributed Retrospectives – Interview with Frank

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 run distributed retrospectives. After the initial interview with Christoph, I present to you:

Frank Deberle, Developer/Coordinator, working in Mainz

frank-deberle tl;dr 1) Don’t fret. Remote retrospectives are not as bad as it may seem. Just try to run one and you’ll see. 2) appear.in works well for us

Full Interview What’s the situation?

I’ve been facilitating retrospectives for 2 years now. For the last 6 months these retrospectives have been remote – every 3 weeks, 60-90 minutes. There’s 3 of us in Mainz and 2 in Stuttgart. We all know each other face to face too, which makes it easier to work together remotely. Two of the team member are immigrants, but they both speak German, so the language barrier is low.

We all work for an agency that in turn works in a big project for another company. I coordinate everyone from our side working on that project and I facilitate the retrospectives in that capacity. That is to say, we are probably a special case, because our retrospective is not the whole team working on that project, but only with the people from our agency, working on that project. They are part of two different Scrum teams (both working on the same project). Phew, that was a little complicated.

Anyway, at first we were all together in Mainz but then we started an office in Stuttgart and suddenly we were a distributed team. In the beginning I was convinced that retrospectives couldn’t possibly work if we were not all in the same room. I was kind of waiting / hoping for the perfect solution to come along. But then we realized we needed to do retrospectives again. We tried it and it just worked. There was no need for me to be so worried about it! Of course, it’s different, but at least you get to do a retrospective at all!

Remote retrospectives? At least you get to do a retrospective at all!
- Frank Deberle (@fdeberle)

How is a remote retrospective different from a co-located one?

It’s very hard to feel everyone’s vibe. In a co-located retrospectives it’s much easier to pick up nuances in voice and mimic and thus read the team’s general mood accurately.

Also everything seems to take a little longer than when co-located. Some part of it is the occasional lag or that Mac microphones’ sensitivity settings spontaneously self-lower. The bigger part is that it seems more chewy in general. Because feedback is less direct, people tend to explain in greater detail. And all of that together leads to slightly longer retrospectives.

What’s your setup? 

We use appear.in video chat. It’s super easy to set up. Once you’ve installed a Chrome plugin all you have to do is send around a link, no special code or password required. The quality is well enough, certainly better than Skype. We’ve never tried Hangouts.

Ideally we use 1 laptop in Stuttgart (for 2 people), and 2 laptops in Mainz (1 for the whiteboard, 1 for 3 people).

Sometimes we enhance this setup with our agency’s bluetooth speaker and standing mic. That improves the sound quality, but we only use it, if it’s already set up.

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

Not really. That is, I don’t plan differently, but I noticed that in the distributed retrospectives we tend to do fewer activities. I think it’s because of the slower pace and more explicit explanations I mentioned before. 

Any tipps for new facilitator’s of remote retrospectives?

Just try it out! It’s really not that big a deal! Oh, and vary what you do. Otherwise it’ll get boring soon. Retromat is cool for that! Okay, that last one was more of a general tipp ;)

Thank you very much, Frank!

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 ;)

Product Owner in der agilen Transition – Podcast

[English summary: Popular podcaster Toby Baier and me talk about the Product Owner during the initial transition / adoption / ignition / <find a better word> to Scrum in his podcast series "Agiles Produktmanagement”.]

toby-baierDie POs unter euch kennen wahrscheinlich schon Toby Baiers Podcast “Agiles Produktmanagement”. In Folge 14 unterhält sich Toby mit mir über den “Product Owner in der agilen Transition”. Dem geht ein Exkurs über die Unzulänglichkeiten des Wortes “Transition” voraus :)

 

Die Folge bekommt ihr hier. Viel Spaß beim Hören!

Distributed Retrospectives – Interview with Christoph

Because of Retromat people assume I’m knowedgable about retrospectives and ask me questions. Which is fine! I am knowedgable about retros and I am happy to answer questions. Unfortunately I could never answer the single most asked question: How do you best run a remote retrospective with a distributed team? I have been fortunate enough to only have worked with co-located teams, so I have no idea. Of course that’s not helpful for the people who ask.

In order to remedy my ignorance in that area I decided to ask people who actually run distributed retrospectives to share their insights with me (and thereby you :) )

Meet Christoph Sperle, Scrummaster from Basel

I very grateful Christoph agreed to answer my questions. Without further ado 


tl;dr 1) You don’t need to plan a remote retro differently from a co-located one. 2) WebEx works well. 3) Use the inbuilt audio.

Full Interview

What’s the situation?

I have facilitated retrospectives for the last 18 months and remote retrospectives for 9 months.

The remote team consists of several people in Basel and 3 remote team members that are in Poland, UK and the US respectively. All remote people have at one point been to Basel and met the Basel team, but not the other “remotes”.

The different time zones (US) and the language barrier add additional layers of difficulty.

Outside of the retrospective the team communicates mostly by chat.

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

I used to plan them differently, for example doing brainstorming and a Learning Matrix in Trello. But this approach completely killed the vibe of a retrospective. Everybody was just staring into their computers. No real exchange.

Today I plan remote retrospectives the same way I plan co-located ones.

What’s your setup?

We use WebEx to have all remote team members with us in the room on a big screen. The remotes see our whiteboard on their screens. We do all activities as you would normally do. Whenever the remotes share their stickies, I write them down and put the on the board. That’s the most stressful part for me.

We tried lots of different things with audio. The telephone was not a good option. Low quality and it was confusing that the voice did not come from the screen. Now we just use the WebEx audio and the speakers from the TV screen that shows our colleagues. That works well for us.

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

None that I can think of. Technology is always hassle and makes it more difficult to address things. Our team members are familiar with each other by now. For fresh teams it’s harder to speak their minds.

 Thank you very much, Christoph!


Do you facilitate remote retrospectives? If so, I’d like to ask you some questions :)

Pink stickies considered harmful & other arcane facilitation tidbits

There are some odd tidbits of experience you pick up when you work with whiteboards and stickies for a longer period of time. Here’s a random collection of my tidbits that might be nice to know for beginners:

pink-sticky-stainsBeware, 3m pink stickies leave pink stains on most non-whiteboard surfaces. Walls, doors, tables, … Especially when wet / moist.

3m sticky notes are still the best ones, i.e. the stickiest ones that are least likely to fall off your board. AFAIR there are differences between the colors. The light yellow, archetypical notes are the stickiest.

We’ve tried out a lot of cheaper stickies and it just led to autumn being year round (= the “leaves” falling down a lot). Among the sticky note copycats I remember Tesa to be the best one.

The usual way to tear off a sticky (upwards) will make it stand off of the board at an angle. If you peel them off left to right, they’ll stay flat. Despite this knowledge I can’t rewire my muscles to tear off to the sides. My stickies always curl :/

Blue Edding boardmarker (most common brand in Germany) becomes non-dry-erasable after a few weeks. Really annoying! That’s why we’ve stopped using blue marker all together.

You can remove dried up writing on a whiteboard by retracing the lines with another whiteboard marker and then wiping. The solvents of the new line also solve the old writing. If you don’t want to whip out the whiteboard cleaner, that’s a working alternative.

Do you have any tidbits to share?

Ritual Dissent

At sipgate we sometimes are too nice to each other. That might sound like a luxurious “problem” if you’ve have to weather a tough company climate, but it can indeed be a problem. As in, we don’t shoot down ideas that aren’t that well thought out. Or we proceed with projects that only one person is really excited about and all others think “Meh” quietly to themselves.

What has really helped us to challenge and improve ideas is a technique called “Ritual Dissent”. It works like this:

One person pitches their idea to the others. Then the pitcher turns around, so that their back is to the group. The others then have to point out weaknesses and flaws in the concept (dissent) or can suggest alternatives (assent). They are not allowed to say anything positive!

Of course, the dissent should be something the pitcher can work with. “This is the worst concept I’ve seen today” fulfils the rule of “not positive” but the pitcher can’t use it at all. It’s bad how? In what aspect? Only speak if the pitcher can use your feedback to improve instead of slumping their shoulders in defeat.

The great thing about Ritual Dissent is that it a) absolves feedback givers from having to find positive aspects for a “sandwich feedback” and b) it gives you permission to criticize. It’s what we want here! You’re not a nagging nay-sayer if you point out flaws!

Usually you do Ritual Dissent when several people will present there respective ideas. One person pitches. The others dissent. Next person pitches.

It’s less personal if you know that after you it will be another one’s turn. This is also the official reason why the pitcher turns their back to the group, i.e. that it will feel less personal. My hypothesis is that as the pitcher you have to just absorb the feedback and aren’t tempted to argue your case. And as the dissenter it’s easier to say hard things because you don’t have to see the pitcher’s face twitch when you point out that their “baby” has three legs and no arms.

I find this to be a very valuable technique to improve ideas, concepts and designs in an environment reluctant to voice harsh criticism. Have you tried it?