There’s a lot to learn from trainings and books, but there’s a difference between hearing and reading about what an agile workplace is like and experiencing the reality of it. That’s why I contacted my PO friends at my former employer to see it they would let them take a peek. They would. (Thank you!)

A crate of Füchsen changed hands and N. and N. got to observe a planning meeting and afterwards asked scores of questions. They returned completely psyched: “So that’s what it’s like, when it’s ‘finished’!”

Then at last week’s agile meetup, Sven mentioned that he’d like to do a similar exchange, but that it can be difficult to find a partner, if your company doesn’t have several people in the same role and you lack connections to other agile companies.

Wouldn’t it be great to have a place to look for such exchange partners? Our neighbors, the Software Craftmen, are already talking a lot about craftsmen swaps. We could copy that and make it more broad. Swapping jobs for weeks might work for Coaches and Scrum Masters, but is probably difficult for Product Owners. For them Pairing or even just passively observing are more viable options that still provide valuable insights. And while we’re at it, let’s include the lean practitioners as well!

There are many ways, such a platform could work. Here’s my concept:

To collect exchange partners for this not-yet-built platform, I created this form. I thought, that even if I never get around to building a proper website, a public spreadsheet with possible exchange partners would still be helpful.

Sadly, no one has submitted the form yet, although the “exchange platform”-idea got a very positive echo on Twitter. I’m wondering why that is…

1. People like the idea, but nobody wants to really use it
2. The idea is great, but the form is a poor implementation
3. The “public” bit is the repellant. If the spreadsheet wasn’t public, people would get listed like crazy
4. Everybody wants to check with their workplace first, before getting listed

Is it one of the above? Which one? Or something completely different? Please tell me in the comments.

I don’t want to build something that no one is going to use. As Sven pointed out, there are simpler ways to create a go-to-place, such as a Xing-/LinkedIn-/GoogleGroups-Group.

What’s important to me is, that people don’t have to look at 5 different sites to check whether there’s someone in their area with whom to team up. The more people concentrate on one platform, the more valuable that platform is to all of us.

That being said, I’d like to build the platform as pictured above. My current – not yet elaborate – plans are here. If at least 5 people list themselves until May 17th, 2013 (1 week from now) it will vastly increase my resolve to build it
And if you’re interested in the exchange thing, but not in getting listed, I’d like to know why and what alternative you will support.

• Frequent
  Giving feedback only at quarterly or yearly reviews wastes a lot of time during which people could already have improved. Weekly One-on-Ones (that I recently proclaimed my undying love for) are a great opportunity to provide or get feedback.
• Timely
  You don’t have to wait for the One-on-One. Give feedback when the event occurs and both parties still remember what it’s about.
• Specific
  “The was a great presentation!” is not as helpful as “The part with the examples was great!” is not as helpful as “The part with the examples was great! I think this helped everyone to orientate and get started quickly.”

The “specific” bit is the one I struggle with the most. Fortunately the following three feedback models help me with that:

1) Situation – Behaviour – Impact

Applicable after you’ve witnessed specific behaviour. Even suited when you do not have formal authority with someone, because you’re not telling them what to do. You merely mirror their behaviour back to them as factual as possible.

Examples:

• In the meeting, when you started to sketch on the whiteboard you really helped getting everyone on the same page.
• In the meeting, when your cell rang and you answered it, it distracted us all a lot.

2) What worked well – Even better if

Applicable if you already like someone’s actions and want them to become even better.

Examples:

• When you started to sketch on the whiteboard you really helped getting everyone on the same page. It would be even better, if you wrote a little bigger next time so that people can also read it from the back of the room.
• When you started to sketch on the whiteboard you really helped getting everyone on the same page. You should definitely take initiative like that again. I think, it would be even better, if you could encourage the others to also come to the front and draw on the board.

3) Noticed – Appears – Why?

Similar to 1), because there’s nothing specific you want the other person to do. You just want to understand them and volunteer your interpretation of the behaviour before asking for the real reason. This method is more suited to observations you’ve made over time (instead of a single instant) than method 1).

Examples:

• I’ve noticed that you’ve often been late to the standup. To me it appears as if you don’t get along well with the other team members. Is that it or is there a different reason?
• Lately I’ve noticed that you quickly raise your voice in meetings. It appears to me that you are either angry or frustrated. Would you tell me, why you’re getting louder? (Were you even aware of that?)

Your turn

If you have little experience with giving feedback, this is your chance to practice! Look at the following situations, pick a method for each and phrase your feedback:

• Your direct report Camillo has documented a new feature. He used a lot of developer jargon, although the documentation is meant for clients.
• Your peer Rolf invited you and 4 others to a meeting. It took half an hour longer than expected.
• Your direct report Clara has given a presentation with very convincing content, but she seemed insecure while delivering.
• You’re the Head of Development and one of the Scrum teams rarely updates its Burndown Chart.

If you do have experience, do you employ models like the above? Do you have a favorite one?

• 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:

• Influence – Give feedback
• Build trust – O3s give you enough time to truly connect to your counterpart
• Coach and grow your team members

I love O3s in both roles, manager and team member. I think they are a great way to influence people. One example where you need all the influence you can get is during an agile transition. But I hardly ever hear about O3s within the context of agile transitions… Curious!

Over the last months I’ve developed a theory about why O3s are uncommon in Agile. Probably several factors come together:

1. Traditional management models emphasize the individual: Tasks for individuals, individual performance reviews, individual bonuses and so on. Agile emphasizes teams and collaboration. It also emphasizes feedback loops, but it’s usually feedback for the whole team as they are “in it together”.
2. One of the underlying beliefs of the agile community is that the environment determines 95% of an individual’s performance and only 5% are actually up to the employee. I wonder if the agile movement is currently overcompensating for management models past. I once subscribed to the “It’s the system, stupid”-tenet, but lately I’m not so sure. Yes, the system plays a huge role, but I’ve also seen poor performance independent of environment.
   
3. There’s a faction in the agile community that is highly skeptical of hierarchies and managers. They seem to think that management is inherently bad. I disagree with that faction. A good manager a) connects their team members to the company and b) looks out for their well-being and growth. See also Google’s take on middle managers’ contribution.

I’m convinced additional O3s would be super-helpful, at least when starting with Scrum and probably other methods, too. Think about it: An agile or lean transition means a lot of new concepts that often fly in the face of people’s old concepts. I think it’s a lot easier to address concerns individually in O3s. Plus you avoid groupthink.

Pierluigi Pugliese’s experience when building teams seems to support this. He writes:

… so I started to apply more and more one-to-one coaching techniques as they are targeting directly a change in an individual instead of “averaging” the intervention through a group process.

To my surprise the teams started to grow an effective teamwork quicker than I’ve seen in the past. So I tried even more with other teams… and it kept becoming faster!

He ascribes this to:

… in a one-to-one setting there is a much bigger “arsenal” of tools that can be used, tools that enable change at a much deeper level than what is achievable in a group setting, especially when somebody in the group does not want/like/accept to work.

Although I’ve never done regular O3s as a Scrum Master, I came in really early / stayed real late to catch people alone, when I wanted to change team dynamics. This sometimes helped where preceding retrospectives hadn’t.

What do you think? Have you ever done One-On-Ones during a transition or even afterwards? In which role for which other role? Do you think it might conflict with self-organization?

Wir alle freuen uns über gute Doku, wenn wir etwas Neues lernen. Doch wie sieht es mit der Doku für unsere eigenen Projekte aus? Ist sie a) vorhanden und b) verständlich geschrieben?

Gut zu schreiben kann man lernen. Darum gebe ich am 13. April einen Workshop in dem wir “fertige” Texte in mehreren Schritten verbessern. Bring also gerne Deine vorhandenen Texte mit! Es muss auch nicht unbedingt eine Dokumentation sein, da die meisten Regeln für alle Arten von Text gelten. Für alle die noch keine Texte haben bringt Corinna Übungstexte mit.

Das Überarbeiten geht am besten mit einem Laptop. Alternativ kannst Du auf totem Baum mitmachen.

Zeit: Samstag, 13. April 2013 – 15 Uhr
Ort: Chaosdorf, Hüttenstr. 25 in Düsseldorf

Spoiler: Der Workshop orientiert sich an diesem Artikel von Su-Shee

Heute habe ich zum zweiten Mal eine Liste aller agil angehauchten Stammtische in meiner Umgebung zusammengestellt. Sobald ich etwas zwei Mal mache, wittere ich ein Pattern. Vielleicht ist die Liste ja für noch mehr Leute interessant. Here we go:

• Agiler Stammtisch in Düsseldorf – Mein Heimat-Stammtisch
• Limited WIP Society in Köln
• Scrumtisch Köln
• Agiler Stammtisch in Bochum
• Cologne Lean Coffee
• Agile Meetup in Bonn

Allen die sich auch für CleanCode und Software-Craftsmanship interessieren, lege ich die Softwerkskammer Duesseldorf ans Herz, mein zweiter Heimat-Stammtisch.

Ausserdem gibt es jeden Tag mindestens drölf IT-bezogene Treffen rund um Köln auf Nerdhub.

Viel Spaß bei einem der Stammtische! Vielleicht sehen wir uns ja mal

Along came the book “Lean Startup” by Eric Ries:

The Lean Startup is about learning what your customers really want. It’s about testing your vision continuously, adapting and adjusting before it’s too late.

Makes sense, doesn’t it? You’ve got an idea, test it, implement a minimum viable product, hone it and are hopefully successful. And yes, it does make sense, but it still has the premise of “idea first”; even if it incorporates that your initial idea and the product you end up with, won’t have much in common.

Last month I discovered that you can also arrive at a successful product from a very different starting point: Amy Hoy makes a case for choosing your customers first and then creating a product for them. Instead of a Minimum Viable Product find Minimum Viable Customers! *mind blown*

Think about it: Whatever you build, you’ll have to support it. Which means that you will have extended contact with your customer group. If you want to be happy, make sure you can stand your intended customers. Then find out what they need and are willing to pay for. Give it to them. Become rich and famous!

Watch Amy’s talk if you want to know more

The official part of this post is now over. Welcome to the unofficial part!

As you might have guessed, I took Amy’s advice to heart. So, who do I like? Who can I imagine to service for an extended period of time?
Lean and agile folks!

And within this group, what’s a pain that might need alleviating?
Hm, maybe starting out as a Scrum Master? That wasn’t easy and I would have appreciated more pointers.

What do you think? Is there a helpful product in there somewhere? If you are or were a Scrum Master I’d really appreciate your feedback on this:
Sure, I can spare 3 minutes to tell Corinna what would have helped me, when I was a newly-minted SM

Kennt ihr schon Henrik Knibergs exzellentes Video zur Rolle des Product Owners? Falls nicht, lege ich es euch sehr ans Herz. Jetzt sogar auf mit – frisch übersetzten – deutschen Untertiteln:

• Entweder direkt auf YouTube angucken oder
• die Untertitel-Datei (.ass) herunterladen

Ich bedanke mich herzlich bei Cédric Chevalerias für die französische Datei als Vorlage und hinterher das Video mit eingebetteten Untertiteln.

In his superb video explaining the role of the Product Owner Henrik Kniberg chooses “Number of completed stories” to measure the teams capacity (velocity). He mentions story points, but chooses a less widespread measure. Why did he choose it? Don’t know. I only know that I would make the same choice:

Any metric can be gamed. Story points are especially easy to game, as the amounts are only meaningful within one team. And it takes just one ill-timed “Why isn’t the velocity going up?” to kick-off story point inflation.

But hey, can’t “Number of completed stories” be gamed just as easily? The team just has to make the stories smaller.

Why, yes. Precisely! It’s a metric I want teams to game!

In my experience it’s difficult for “fresh” agile teams to cut stories down. It’s a skill that grows with practise. People not accustomed to splitting stories into nice vertical slices tend to think it’s not possible. And they often don’t see the value in it, so they don’t really try.

Pointing out the value I see doesn’t necessarily help, although small stories…

• … are more thought-through
• … have less open questions
• … have a lower probability to turn out way bigger than expected
• … contain less uncertainty and bad surprises
• … have a higher chance of being completed in one sprint
• … are more focused on value-adding functionality
• … easier to talk about

Pointing out that “small” is even in the INVEST acronym that good stories try to adhere to doesn’t help either

Usually teams need to work with a few bloated as well as bite-sized stories to experience the difference and witness the advantages of the latter over the former.

[Clarification: What do I mean, when I say "small"? Well, I'm used to 4-7 people dev teams and 2-week sprints. In this setting I consider a story "small" if it can be accomplished:

• by at most a 1/3 of the team
• in at most a third of the sprint time.

If these parameters change, so might my definition.]

Anyway, I feel that knowing they’ll be measured in stories gives teams an incentive to try and split stories. If the team doesn’t game the metric / doesn’t learn how to bite-size stories, I get an accurate velocity. That’s fine, too. But I’ll prefer leaner, clearer stories and a learning team anytime.

What if a team takes it to far? Cutting stories down into meaningless bits? Well, a story is still supposed to add business value, isn’t it? So, if the team can’t resist, let “Adds business value: Yes/No” and the PO be your safety net.

From what I’ve seen, stories that are too small are significantly rarer than stories that are too big. And the too small ones are much less of a problem.

What’s your experience?

Related Article:

• While we’re at it … – Scope creep

Today was tutorial day. These are the two I attended:

Transport Knowledge and Values with Story Telling

Humans are hard-wired for stories – in the traditional sense, not just user stories. We remember stories much better than lists of facts. So stories suggest themselves to capture knowledge and to relay values to new employees. A story about what collaboration could look like and how it saved the day that one time is a tad more meaningful than a motivational poster with “Collaboration – It’s one of our core values!” on it.

Anne Hoffmann and Andrea Herrmann introduced the arc of suspense and phases a story usually covers:

1. Set the scene: When? Where? Who?
2. Introduce the problem
3. Present the solution

To practise, we took turns in groups of 5, telling 3-sentence-stories – one sentence per person. One such story could be:

• 1st person: On the ISS a scientist is pouring water on the plants.
• 2nd person: As there’s no gravity, the water is floating away and the plants stay dry.
• 3rd person: So the astronaut moves the plant pots to catch the water bubbles.

It was a fun excercise! And the story above can even be interpreted as transporting a value. Which would you guess it is?

Last tip: The stories have greater effect if the audience can identify with the hero/ine. So with a semi-fictional story adapt the main person to match characteristics of your listeners, the better for them to identify

Thank you, Anne Hoffmann and Andrea Herrmann!

The Product Partnership: Using Structured Conversations to Deliver Value

7 Product Dimensions

This one was a little different from what I expected. I thought it would be something akin to dialogue sheets, but it was about a conversation along the 7 dimensions of a product. You can use them like a funnel to progressively narrow your focus on what’s adding value. Unfortunately we were a bit short on time. I’d like to have explored the application some more.

Along the way Ellen Gottesdiener grazed a few modeling techniques that sounded interesting to follow-up on:

• Context diagram to model user interface inputs and outputs
• User role maps (couldn’t find a good link)
• Data model

Thank you, Ellen Gottesdiener!

This time we tried out the “Lean Coffee” approach to facilitate a discussion in the whole group about a range of topics.  As the meetup takes place in a brewpub for Düsseldorf’s typical type of beer “Altbier” we dubbed it “Lean Altbier” and it went down like this:

• Everyone writes down topics they’d like to discuss on stickies (1 topic per sticky)
• Stickies are collected and read out. The person who wrote it describes the topic in 1 or 2 sentences
• We put all stickies on a cardboard menu and passed it around the table so that everyone could distribute 2 votes
• Order the stickies according to votes
• Start with the topic of highest interest

Originally we thought we’d just talk about each topic until the discussion dies down, but it seems that discussions rarely completely die. Just more and more people detach until only 2 or 3 keep talking. So I’ve started to set a timer and once the time is up, people give a quick thumbs up or down. Majority of thumbs up gives the topic an additional time box, thumbs down moves the discussion on to the next topic. This makes sure that the discussion stays interesting for most participants.

We covered topics as diverse as

• Agile Management
• Experiences with Kanban-Pizza Game
• Agile QA
• Why ScrumMaster (“default” in Germany) and not a Coach (“default” in USA)?
• and more

Debate was lively and at least one regular participant declared our “Lean Altbier” evening it to be the “most interesting, most valuable meet up evening yet”.

Lean Coffee lived up to its intention of being “the least structure necessary for a coherent and productive meeting. No more, no less.” Previously I’d even participated in conference calls using Lean Coffee and it worked! It’s like a one-track mini-open space. My husband gave me the idea that we could also organize an evening of 5 minute lightning talks with it. Oh, and I could turn this into an activity for the Retr-O-Mat! So many possibilities!

What can you think of? Or have even tried out?