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!

Thank you Olaf & Martin!

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

What does it take to succeed with agile?

sipgate, my employer, has come a long way since introducing Scrum in 2010. Overall I’d consider our journey a successful transformation. Today, we can ship much faster with better code quality and information is readily available to every employee – to name a few advantages.

Of course there are many factors that contribute to a successful agile transformation (yep, you got me, the title is clickbait), but if I had to pick one single most important factor and draw a diagram to represent it, it would be this:

roomsize

What do you think this might depict? Take a few seconds to come up with a guess, before you scroll down.

Continue reading

Questioning the status quo without stepping on toes

Remember my “Resistance Against Change as a Way to Save Face” post? James described an interesting situation in the comments:

Here’s the thing. Im my organisation call centre workers are managed based on adherence to roster. The roster is a plan, based on a forecast of customer demand, telling staff when to be available to take calls, and organising when they can spend there time on other activities. Managers believe that this is a customer focused approach. They seek to maximise adherence to roster, and they reward staff for doing so. However it takes no account of real demand – just forecast demand. I would argue that when the forecast is wrong it is right to move away from the plan to help the actual customers, but this systems prioritises the hypothetical customers in the forecast above the real customers on the phone (or any other change in circumstances not accounted for in the plan.)

It’s idiotic. Any suggestions about how to address this folly without making those who implement it feel foolish.

James asks about a process, not someone’s individual ways, which is similar but not the same. For this scenario I do have ideas:

Be curious

Why is the current process the way it is? Become a researcher and find out. This works best if you are new to the company or the department.

Caution, for this to work you have to be genuinely curious and prepared to change your mind. People can smell a hidden agenda. And who knows, maybe the current process makes perfect sense if seen as part of a bigger picture.

Do you know who came up with the current process? If they’ve left, this will make your life easier. If not, talk to that person first. Alone, so there’s less reason for them to be defensive. Be careful how you phrase your question and offer your observations. Words like “folly” and “idiotic” would rub everyone the wrong way. [I don’t really think you’d put it like this with them 😉 ]

I’d try it like this: “Do you have a minute for me? I’ve noticed something surprising in the way we handle things and would like to understand why we do it like this.”

Best case scenario: There was a reason to do it the current way which doesn’t apply anymore. This becomes apparent to others while you research the history of the process and you change how agents are rewarded, because the current way causes pain.

Very important aspect that, the pain.

Who feels pain?

If no one in the company feels the pain, there is no reason for them to change*. Continue reading

Resistance Against Change as a Way to Save Face

Every once in a while I have an epiphany/experience of the “Oh. So THAT’s what it feels like…” variety, such as the one about giving unsolicited advice. This January I had the (mis)fortune to have another empathy epiphany handed to me on a silver plate:

It was a Wednesday evening and my company was having its monthly Knit Night. A Knit Night consists of lots of yarn and people knitting or crocheting. And beer. Banisters might end with a knitted cozy as a result.

I had just (re)joined the company and it was my first Knit Night. In the middle of it, one colleague glanced over at me and was like: “You’ve got a weird way of knitting. What ARE you doing?”

“Um, stockinette stitch (German: ‘glatt rechts’)? Knit one row, purl one row, knit one row, …?”
As my colleagues were quick to point out, it wasn’t “normal” knitting, but twisted [sic!] knitting (German: ‘rechts verschränkt’).

Colleague 1: “Who taught you knitting?”
Colleague 2: “No one, apparently.”

Ouch! That hurt. A lot. Which is surprising given that knitting does NOT define me in any important  way:

  • I have not invested years of my life into practicing it
  • I’ve never earned money with it
  • I’ve never considered myself an expert
  • If someone asked me to describe myself, I wouldn’t even consider “knitting”. It’s just something I’ve “always” been able to do. Or not 😉
  • I’ve only knitted minor stuff like scarves and such. My biggest knitting accomplishment is this Scotty hat for my husband:
    scotty-hat_kl

So, if finding out that I’ve done something wrong my whole life that is not important to me or my self-image drags me down for 4 days, what must it be like for professionals when a consultant or coach swoops in? Continue reading

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

cover_power-of-habit

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.

 silo

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.

 scrum-team

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 Mail-Skills.com 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 🙂