What is Coaching anyway?

[This post is one of many inspired by Agile 2015]

The other day I found out that my husband’s definition of what it means “to coach someone” was very different from mine. His was a sports one, i.e. someone who observes and then gives hints what to do differently. It seems to be a popular notion. Last week, Johanna Rothman quoted Consulting Role: Principles and Dynamics of Matching Role to Situation, by Champion, Kiel and McLendon with this definition of a Coaching: “You did well; you can add this next time.”

Mine is different, though and given the high number of coaching related sessions I attended at Agile 2015, I will probably talk a lot about Coaching. Hence it might be good to clarify what I mean, when I use the word.

For starters let me point out that Agile Coaches very often do not actually “coach”. Take this framework by the Agile Coaching Institute:

ACI-Agile-Coach-Competency-Framework

You’ll notice that Professional Coaching is only 1 of 4 possible activities, next to Teaching, Mentoring and Facilitating. At least in the beginning of an engagement Agile Coaches often have their hands full Teaching and Facilitating and that’s okay. Advice and orientation is often what people need and seek.

In contrast, coaching is the act of creating and “holding” a safe space in which the coachee can find answers in and by themselves.

 ”Coaching is life-changing – if it is not life-changing it’s not coaching” – Martin Alaimo

For the most part, for me that translates into shutting the fuck up and doing some serious listening. As a coach you don’t have to have all the answers. But you better bring some pretty great questions! Powerful questions for example. Or clean questions.

How about you? What’s your definition of Coaching?

Coaching Canvas

[This post is one of many sparked by Agile 2015.]

Have you noticed how many canvases are around these days? Business Model Canvas. Lean Canvas. Value Proposition Canvas… Can’t we think of any other approach anymore?

That’s why I was a little hesitant when Olaf Lewitz and Martin Alaimo opened up their “Great Coaching Conversations Workshop” with the “Coaching Canvas“. Yeah, right…

Coaching Canvas

How I regret thinking that! It totally worked! We paired up and took turns being coach and coachee.

We had a list of Powerful Questions to pick from for each field of the canvas. Together with the canvas this was enough rigging so that 100+ people had insightful conversations. Some even had coaching conversations:

“Coaching is life-changing” – Rich Litvin

“If it’s not life-changing it’s not coaching” – Olaf Lewitz

I had one, for example. I had a profound realization about myself and how I view tricky situations. This realization might well change my (career) path sometime in the future. Still mulling it over.

I guess what I’m saying is: If you’ve got a coaching situation on your hand and don’t have much experience in coaching, absolutely do give the Coaching Canvas + Powerful Questions a shot! You’ll be surprised!

Sketchnotes from Agile 2015

[This post is one of many sparked by Agile 2015.]

Note taking helps me to stay focused on a presentation or meeting. I used to produce loads of  densely scribbled sheets that I never looked at again, because I couldn’t find the pertinent points anyway. For Agile 2015 I decided to go the extra mile and sketchnote: to add icons and arrange all information visually. This way I can tell one note from the other, I’m likely to remember more and to actually look at my notes. And they’re likely to be pretty:

sketchnote_super-awesome-problems_hiRes

Sketchnote for Luke Hohmann’s keynote on “Super Awesome  Problems”

Before Agile 2015, with just 1 sketchnote under my belt, I would not have considered myself a sketchnoter. I mean, heck, I can’t draw to save my life (just look at the hand below). But I did train Bikablo for flipcharts and arranged loads of information for Wall-Skills. It seems to have carried over.

sketchnote_improv

Sketchnote for Jessie Shternshus’ keynote on “Individuals, Interactions & Improv”

So now, yes, I do consider myself a sketchnoter! Not a particularly good one, but at least an inspiring one: Shoutout to Tim, Rob, and Kimberly – Have fun! Can’t wait to see yours!

sketchnote_coaching-flow

Sketchnote on “Coaching Flow” by Esther Derby and Mike Lowery

BTW, I wasn’t the only sketchnoter:

sketchnote_conflict-resolution

Sketchnote for Ellen Grove’s highly engaging workshop “Games to learn about Conflict Resolution”

If you’d like to know more about Sketchnotes, check out Mike Rohde’s book. Don’t get analysis paralysis, though. Just start to sketchnote. It takes practise but and It’s fun!

PS: If you’d like to know my tricks, here they are:

sketchnote_sketchnotes

Sketchnote about sketchnotes. Can you say “meta”?

Thank God it’s Open Friday – Agile 2015

[This post is one of many sparked by Agile 2015.]

Oh wow, back from Agile 2015. My first Agile. What a ride, so full of impressions and met so many interesting people! I feel about a gazillion blog posts coming on :)

But for starters, here’s the paper for my talk “Thank God it’s Open Friday!”. I recommend the paper over the slides, because it’s self-contained. The slides miss a lot of commentary, even with speaker notes.

What is this “Open Friday” thing you ask?

“Every other Friday all employees in our company hold an Open Space. It’s how we spread knowledge, solve problems, gather ideas and superseded meetings.” – Me, 2015

What ever happened to XP?

In June InfoQ published a very interesting talk by Rachel Davies “Back to the Future: What Ever Happened to Being eXtreme?

I think Rachel is spot on about a lot of things such as:

  • Some craftsmen care too much about code and too little about what problem it solves
  • There’s a  sad lack of developers at agile confs

While listening I noticed that we do a lot of the XP practices at work. And we introduced them via the backdoor Scrum. By now I’m pretty convinced that (in the software business) Scrum can’t work longterm without XP. But XP probably works fine without Scrum… You may draw your own conclusions. (And yes, I’ve tried to find a job in place where they use just XP to test this theory. At least in Germany I couldn’t find any.)

Anyway, go watch the video. It was time well invested for me: “Back to the Future: What Ever Happened to Being eXtreme?

Rules are made up

Do you sometimes observe something awesome at work which makes you realize how much everybody’s mindset has already shifted towards lean and agile thinking? Lately I have a lot of these moments. I always savour them, because in every day routine it’s easy to see only problems and forget all the things that are already working great. It’s uplifting to not always look at the road ahead, but to take the time to turn around and rejoice in all the ground you’ve already covered. I had one such rejoicing moment 2 weeks ago.

How far we’ve come

I took part in an Inhouse Podojo, i.e. all attendants were colleagues of mine. Spoiler Alert: If you’re thinking of joining a Podojo, please don’t read on! I mean it, shush, go away!

Still there? Okay. Part of the Podojo was the inevitable Lego simulation. In the simulation we had 2 Scrum Teams with 8 people each. Each team had its own lanes of stories and its own table to build on, though we were to work on the same product and had to “integrate” on Team A’s table at the end of each sprint. 3 sprints to go.

In the first sprint planning (3 minutes) our PO went to take a first pick of stories from our 2 story lanes and the team decided how many to take. We got all of it built, but at integration time we found that the other team had built some of the exact same stuff, because their 2 lanes had had some of the same stories. At least we had similar priorities in picking these overlapping stories first ;)

Building stuff twice was the obvious problem to fix during the first retrospective. And that’s where it got interesting: Both team’s independently of each other decided that a) the POs should go pick the stories together and b) we should all work on one table. And so we pushed the tables together to make one big workspace.

It worked great. So great in fact, that neither team had any great complaints or improvement ideas during the last two retros.

Why do I think the table-merging thingy is remarkable?

Continue reading

Wall-Skills: Design the Box, Japanese Terms in Lean, User Stories, less +F

Recent 1-pagers on Wall-Skills.com:

Is the vision for your product rather fuzzy? Design the box is an awesome technique to bring clarity and focus.

If you’re in a Scrum environment you’ll might encounter Lean at one point. Here’s a vocab cheat sheet: Japanese Terms in Lean

User Stories in a nutshell 1 page

Does your job entail keeping an eye on log files? Try less +F for viewing logs

A team has a common goal

At the moment I’m part of a really great team. We don’t even have a proper backlog, but it still works, because we have common long-term and short-term goals and a very clear shared vision.

However, in 2010, we already had teams, too. Well, “teams”. Teams in the name only.  See, back in 2010 we were still siloed. The “teams” were actually just a bunch of people sitting in the same room, doing similar things. We would say “backend team” although everyone in the group build and maintained their own system. To say it with Shakespeare:

Sharing a room doth not a team make.

A team has a common goal. Team members help each other reach this goal. None of the members has an individual goal more important than reaching the team’s goal. If there’s no common goal, don’t call them “team”. Call them “group”. Thank you!