Clean Questions and the Power of Metaphors

A year ago I blogged about Non-Violent Communication as a means to avoid judgement and find needs. Now I think I found something even more radical (once again via Andrea Chiou): Clean Questions / Clean Language.

With Clean Language, not only do you forego judgement, you don’t even offer interpretations. It’s a bit like the game “Taboo”: You can only use words that the other person has used first. (As Clean Language was developed by therapist David Grove, the “other person” is usually a client.)

Examples of Clean Questions – X is a something said by your client:

  • And that X is like what?
  • Where is that X?
  • And is there anything else about X?
  • And what needs to happen for X?

Here’s a list of all common Clean Questions. (For my fellow German natives: Clean Questions auf deutsch)

While asking these simple, repetitive questions, you look out for metaphors used by the other person and take them literally. Metaphors make it possible to access, talk and possibly resolve very deep, semi-conscious things that would be hard or impossible to address directly:
If a client feels they don’t make progress at work, then “It’s like smashing myself head-first into a brick wall” vs. “It feels like running on a treadmill, going nowhere” describe very different experiences.

Here’s an excellent TEDx Talk on how Caitlin Walker used Clean Questions to help under-privileged teenagers to deal with anger:


I’m still on the lookout for an opportunity to try this out. If you’d like to try, here’s a great article on how to apply Clean Questions in a business context.

What do you think about the concept of Clean Language? Have you already used Clean Questions? How did it go?

The Power of Habit – Book Tip


When the insanely insightful Amy Hoy is smitten with a book, I read it. And “The Power of Habit” did not disappoint!

It’s an entertaining journey through cases that helped scientists uncover how habits (and willpower) work and how you can change them. Understanding why and how our automatic actions play out is highly important, given that they govern about 40% of all our daily actions – A staggeringly high amount.

I highly recommend reading the book! As an appetizer, here’s an excerpt on how to change a habit by changing the routine within the Cue-Routine-Reward loop.

Let’s close with some quotes I highlighted during reading: Continue reading

Evolution of team setups

Ever since my employer adopted agile some 4 years, ago, we’ve developed our products with a variety of team “configurations”. Here’s a short overview of what we’ve tried and why product teams take the crown so far.

Pre-Scrum: Silos

In pre-Scrum times there were no real teams, but rather groups of people with a similar skill set who shared a room. Everyone had their own tasks to work on. We had a room full of web developers, one with perl hoshis, another one where the project managers sat, and so forth.


The seperation was unfortunate. A nice example dates back to 2010: There is a page that lists all groups in a customer’s sipgate team account. This page had agonizingly long loading times. I’m talking minutes here. Upon closer inspection it turned out that the page requested lots of information from the backend, although it only needed to show little pieces of the requested data. There wasn’t a backend function that delivered precisely what the web page needed. And as web developers and backend developers were working separately the web developers collected the data they needed from methods that were already available, rather than wait for a method to be custom made.

Scrum: Cross-functional Teams

Today it would go differently, because in 2010 we adopted Scrum: We build real, cross-functional teams, consisting of web devs, backend devs, a designer or UX person and a product owner (a re-purposed project manager). One of the devs doubled as scrum master in each team. Such a team worked on shared tasks and could build a complete piece of new functionality.


With this setup we were already developing much faster than before. Pre-Scrum feature development had often dragged along. Now the 5 product owners were hard pressed to come up with enough work for all teams. So far, so good.

Continue reading

The Product Owner’s tasks according to the Dev Team

One of the questions that inspired is: “What do you expect of a PO? What are her tasks?”

As always, the answer is “It depends”. One major influence on what I expect from a PO is maturity. Not the PO’s, the Dev Team’s.

A team that’s recently started using Scrum usually expects a user story to come with a subset of the following:

  1.  detailed description
    • sometimes with a specific solution
  2. further details as acceptance criteria
  3. list of test cases
  4. Photoshop mockups of all interfaces
  5. everything clarified with stakeholders

Can you feel the remnants of a compartmentalized, planning-heavy process?
Yet, I wouldn’t try to shake all of the habits right away. A PO trying to share those duties with the team rightaway will often be seen as not doing her job. “That’s what YOU’re here for, aren’t you? Do we have to do your job, too?”
Heaven forbid that the dev team have to clarify details with a marketing guy themselves…

The trick is for everyone to slowly evolve from “everything’s pre-chewed” to “we can and want to do this together – results will be better”.

A PO that fulfills none of the above can actually be a great PO – to a mature team. Much better than one who stifles the team’s creativity by over-specifying everything: Continue reading

Be the Change you want to see

Yay, I’ll go back to work in January. I’ll return to my ex-ex-employer and it feels like going home. I’m looking forward to being part of a team again. I’m also a bit frightened, because I’ll be a web developer once again. Something I haven’t done full-time for 10+ years. It’s not going to be easy. But I know there are great people in my team that I can learn a lot from, so I’m more excited than scared.

As an added benefit I’ll raise a few numbers I want to see rise, namely “female developers” and “developers at agile meetups”. And I will finally (have to) practice what I preach. Adopt ALL the XP practices!

If all works out well, the focus of this blog might shift towards development topics.

PS: A big thank you to everyone who offered me a job 🙂

Join the Advent Calendar!

Have you ever heard of “Testing on the Toilet“? I hadn’t until Roland presented it at the Düsseldorf Agile Meetup: Some Google testers wanted to improve the (automated) testing done across the company. That’s why they started to hang up tips for testing in the toilets for people to read in their “leisure” time. They exchange the tips weekly.

Roland copied the idea for his company, not with testing but with all kinds of other topics such as “10 Tips for Maintainable Code”, “Admin Zen”, “9 Tips for Better Presentations”, “Agile Mindset”, “10 Vim Tips”, etc.

I liked the idea so much that I convinced him to team up, create a nice layout for these 1-pagers and make them publicly available. Just a few weeks later, we present to you:


There we’ll collect 1-page PDFs or images on Agile, Lean, development, devOps, system administration, Scrum and Kanban – ready for print out.

Right now, we’ve only published two sample posts, because we want to kick off the collection with an Advent Calendar. Although we’ve got ideas for most of the 24 slots, we think a greater diversity would be more interesting. Maybe you’ve got great, suitable content in your blog? Wonderful! Tell us about it – Contact us on Twitter or via email. (Please be quick and submit until next Monday, the 25th so that we can prepare everything for December.)

What do you think? Would you give it a try in your company? It’s not mandatory to display the bulletins in toilets 😉 Refrigerators are perfect targets, too!

Don’t miss our first post on December 1st, 2013 – Subscribe to the RSS feed

Trickle me softly

Everyone knows todo lists and GTD. But do you know Trickle Lists?

Todo lists are tactics. The items differ from day to day. Some might be large tasks. In contrast, Trickle Lists are strategy. The same teeny tiny steps – every day – toward a long-term goal.

I’ve learned about Trickle Lists and Trickle Theory a few years ago. If you don’t want to explore the – excellent! – original articles, here’s the gist:

There are a lot of areas where constancy rules and 1 big effort just doesn’t cut it. For example, as a boss you can’t establish good relationships with your directs by dumping concentrated feedback on them at the first of the months. Instead a little feedback every other day makes a huge difference.

Doing a little every day helps building a habit. Trickle Lists are training wheels that help form those habits.

Trickle Lists in Practise

Trickle List Take a sheet of paper and create a table. The columns are all the things you want to do regularly, the rows are the days of the months. You get to check a cell, if you’ve done that “trickle” on that day. After a while it’s self-reinforcing – You don’t want to break the chain.

A trickle typically takes about 5 minutes. I recommend against trickles that takes longer than 15 minutes.

To be doable, don’t try too many trickles at once. More than 5 is rather ambitious. I achieve more if I have at most 3 trickles. If I have more, I’ll just won’t get around to 2 of them. “Drawing for 5 mins” is one such failed trickle. “Catch someone doing great and praise them” worked out great, though 🙂

As you can see, my current list contains: Continue reading

Just say “don’t”

Motivation, willpower and discipline are fascinating to me. How much is within our control and what is not, e.g. because of decision fatigue? I’m equally fascinated with language and how the words we use shape our world. Every once in a while the two spheres intersect:

If you had a goal such as “exercise daily” and you could raise the chances of following through from 30% to 80% (or maybe even from 10% to 80% depending on your current strategy), would you want to know more? Apparently the magical words are “I don’t [skip exercise]” instead of “I can’t“.

“I don’t” puts you in the driver’s seat. “I can’t” stresses limitations and resolve wavers. Fascinating stuff.

Read the whole “Scientific Guide to Effectively Saying No” at Lifehacker


Body Language – “Fake it, till you become it”

You know that people smile when they are happy. Chances are, you also now that when you smile your mood lifts, i.e. you can change your state of mind by a physical act.

It gets even better: You can raise your confidence and lower your stress levels by taking “power poses”, such as “wonder woman stance” and “arms raised in victory” for 2 minutes. Watch Amy Cuddy’s astonishing Ted Talk to on how they researched it and how you can use it in your daily life:


Before the next challenging situation sequester yourself for 2 minutes to take a power stance. Or in Amy Cuddy’s words:

Fake it, till you become it

One-on-Ones in Agile (Transitions)

Have you ever had regular One-on-Ones (“O3s”)? If not, I think you’re missing out. Mark Horstman and Mike Auzenne describe them as:

  • 30 minute conversation every (other) week
  • Between a manager and one of her team members. (Each team member gets their own O3 each week.)
  • Default time division: 10 minutes team members topics, 10 minutes managers topics, 10 minutes for coaching or mentoring

Now that I finally experienced O3s, I agree with Mark and Mike that they are the “single most effective management tool“.

Here’s what I think is awesome about O3s for the team member:

  • It’s a very close feedback loop – You always know whether what you’re doing contributes to the company’s overarching goal
    • Which for me goes hand in hand with “Having Purpose”
  • Validation – You are important enough for your boss to take time to listen to you
  • Guaranteed sync point – You don’t have to disturb your boss because you know there’s a time to tackle all non-urgent issues in the O3

As the manager you can: Continue reading