Archive for June, 2009

Facilitation Antipattern: Repetitor

Musings | Posted by Doc
Jun 29 2009

RepetitorMotto: It’s worth repeating. It’s worth repeating. It’s worth repeating.
Belief: You’ll only understand if I say it at least three times.
Behavior: Says the same thing repeatedly, frequently in somewhat different words, frequently two, three, or more times.
Characteristics: Articulate, filled with conviction, perhaps lacking confidence

In my last post, this would have sounded like this:

It’s about the subtleties. You know – it’s about the little things. It’s about the stuff that’s not so obvious – the subtleties… the things that others hear in what you say whether you were aware of it or not…

Repetitors are usually articulate. They are able to express themselves. In the positive way, without the unneeded repetitions, a Repetitor would be an Articulate. By repeating themselves, without checking to see whether the listener is understanding, the Repetitor turns a Pattern into an Antipattern.

Dealing with a Repetitor is as simple as a variant on the Facilitation Four-Step: Interrupt, Ask, Redirect, Commit.


“Excuse me, Frank.”


“Do you mind…”


“…if I check in with the others for a moment?”


“We’ll get right back to what you were saying.”

Action (yes, a 5th step 😉 )

“Sue, just so we’re clear, can you tell us what Frank’s point was?”

In this way, I validate that others have heard Frank, check to make sure that they’ve understood Frank, and break the pattern of repetition.

Related Pattern: Articulate

It’s the subleties

Coping and Communicating, Facilitation, Musings | Posted by Doc
Jun 28 2009

How many times have you found yourself feeling angry or hurt or amused, and yet been unable to put your finger on just what it was?

“He insulted me!”

“She hurt my feelings.”

“That was ridiculous.”

And the other person is confused, surprised, or hurt by your reaction. Why is that?

As attuned as I try to be to subtleties, I still find myself surprised at times.

One of the more common subtleties that I try to remain aware of is using comparative and judgmental words unintentionally, especially when facilitating meetings/discussions.

For instance, one person offers a comment, to which I say “thank you.” The next offers a comment, to which I respond “That was good.” Another offers a comment to which I say “Excellent!” What’s the impact on the first person? After all, I didn’t say their comment was good or excellent, so was their comment not as good as the other two? Did I somehow just slight that person? And the second person – did I imply that the third person’s comment was even better than theirs?

I can hear folks now saying “Are you telling me, Doc, that I have to think about every word I say before I say it? I mean, won’t that be a lot of work?”

Yes, and yes. Especially if you are in a position or role where your words have power and influence.

I haven’t forgotten my own philosophy – that It’s All About Me – that I’m not responsible for my listeners’ behavior or feelings.  But I also remember that part of my thinking is that I can choose to be aware of the impact that my behavior may have on others, and choose to modify my behavior.

When I facilitate, I struggle to be aware of how what I say may impact those present, and to choose my words with care. I try to avoid comparatives (“better”), and judgmental terms (“good”, “thoughtful”). As a facilitator, it’s appropriate for me to recognize someone for speaking (“thank you”) and acknowledge them, but not to judge them or compare them.

Yo! Pass the potatoes!

Agile & Lean | Posted by Doc
Jun 11 2009

Many of us have seen, and firmly believe, that co-location works for agile teams. The freedom to interact any time, all the time, is intensely powerful. The value of being able to see and hear one’s teammates is incalculable.

Working with a distributed team on my current project, we’re seeing how challenging it is for the folks over in India. The team here talks to each other all the time, expresses and resolves issues, jointly decides on architectural challenges, and overall is just more effective.

What’s particularly joyful for me is watching this team go from completely non-co-located and struggling to being mostly co-located and effective. It’s impressive and gratifying.

The level and quality of communication has gone up.

The number and severity of problems has gone down.

The “customer” is thrilled with the amount of communication and his understanding of what’s going on.

Perhaps best is that the project manager’s manager wandered in and asked the lead developer to show him the system. The lead developer did. The manager, after bouncing up and down with joy, proceeded to show some of the members of the user/customer community the system, and they are thrilled too.

Co-location works. Give up your walls and partitions and privacy. Embrace the connection with your teammates, greater productivity, greater satisfaction, and the joy of being siginificantly more effective.


Nine women, one month

Agile & Lean | Posted by Doc
Jun 11 2009

Among the other things we talk about so frequently in the Agile community is commitment. Do you know the story of the Pig and the Chicken?

Commitment is about being there.  Commitment is about being available to your teammates.  Commitment is about having a roughly equal level of investment in the project.

In too many organizations, “they” treat team members as if they don’t need to be committed.

“Oh, you can work on that project and these other two. You can handle it.”

What they ignore are two things:

  1. Multitasking doesn’t work. Research has been done, reports have been written, and it just doesn’t work. The individual gets frustrated and stressed, and doesn’t do their best on either/any.
  2. It’s not just about the individual, it’s about the team.

Here are some writings and thoughts about multitasking, particularly in the Agile world:


Without much effort you can find more.

So why is it that it’s so obvious to so many of us that multitasking is not effective and not efficient, and is actually detrimental to the individual and the team, and yet still the “leaders” seem to push it and push it?

If it’s gonna take a month to do something, and a month to do another something, then one person will probably take more than two months if they try to do them both at the same time. On the other hand, if they are allowed to focus on one at a time…

I’m not saying that organizations shouldn’t do multiple projects. I’m saying that individuals do their best work when they can focus on one project/task and work it to completion. Anything else is self-defeating.

Here’s your gun, there’s your foot

Agile & Lean, Coping and Communicating | Posted by Doc
Jun 10 2009

Being timely is a significant aspect to Agile.

Too many people make the mistake of thinking Agile means unstructured, loose.

Flexible does not mean “I don’t need to show up on time.”

Flexible does not mean “I don’t need to meet my commitments.”

Agile does not mean “I can do what I want when I want, as long as I’m communicating.”

What brings this up for me today is the experience of attending a showcase, and having the lead developer, who was to present the showcase, show up 15 minutes late.

We have a room full of customers and project members, and we’re all sitting around with our thumbs up our butts waiting.

This is not Agile. This is failure. This is BAD PR for the project and for Agile.

It reminds me of the last speeding ticket I got (1996, in case you’re wondering).  I went to traffic school to clear the ticket.  The fellow teaching the class was a California Highway Patrolman. He said “Many times, when I stop someone for speeding, they tell me that they were rushing because they were late. I tell them ‘start leaving five minutes earlier.'”

Showing up late shows disrespect for everyone, and wastes a lot of time. Wasting time also wastes money (everyone is getting paid to sit there).

Leave five minutes earlier. Plan to arrive early, not just barely on time.

Multiple roles

Agile & Lean | Posted by Doc
Jun 07 2009

When we talk about the roles on an agile team, we’re generally pretty clear about what we mean. Not perfectly clear, of course, but pretty clear.

So imagine my surprise when I get to a client that has one person filling the roles of Product Owner, Business Analyst, and QA. In fact, this organization does not do formal QA nor have a QA role.

Oh my!

Add into the mix the fact that this individual is on multiple projects in these roles, and it could be a recipe for disaster.

Fortunately, he’s excited about agile, is really absorbing the ideas quickly, and is willing to put in the effort to make it all happen.

As we’re moving forward, he’s learning. It was really interesting to hear him say the other day “If I had understood this better when we started, I would have written these stories differently.”

To which I replied “Then write them differently now!”

It’s fascinating to see things changing rapidly, and to see the team absorbing the lessons and moving forward quickly.

One aspect of this is in Mingle. We’re using Mingle, in case that wasn’t clear. The Project Manager, who is very junior, excels at process and organization. So she’s taking to Mingle very quickly (notice how I resisted the urge to use some trite metaphor?). Between one day and the next, I noticed all sorts of new cards, new views, and a reorganization of the cards into releases.

Still, back to the PM/BA/QA guy, I see this as one of the biggest risks for the project. We’ve been working hard on getting them to understand what “done” means for a card, and he is a bottleneck and single point of failure.

I can’t wait to see how this story unfolds!

Distributed Retrospective

Agile & Lean | Posted by Doc
Jun 07 2009

A couple of days ago, I facilitated my first-ever distributed retrospective.  I was pretty anxious about it, since much of the value I’ve experienced in retrospectives comes from the interactions between people.  Here’s how it went:

I was facilitating from my home in Austin. My colleague was in Chicago. The project manager/scrum master was at work, but off site. Several of the team were in the client’s offices, but not necessarily together. And several were in Bangalore, India.

From my perspective, this created a wonderful variety of challenges.

We used a sharing application that allowed participants to sign in as “guest #”, for those times when we wanted anonymity, and also used a WebEx. The PM shared the anonymous app via WebEx, so we could all see what was being entered.

We began with a Safety Exercise, which was supported by the sharing app which was revealed in the WebEx window. It worked quite well, and I was delighted to see all fives and one four (meaning that everyone felt quite safe).

We followed this with a Mad/Glad/Sad, still using the anonymous window. This was interesting, in that we were using virtual stickies, and had to do reading/clustering verbally. It’s clear that there’s an opportunity for a sharing app that actually presents something like stickies, and can be manipulated in real-time (something like, but more oriented toward this purpose).

I thought about using Mingle. Here’s how I think it might work (and I might try this next week):

  • Create a card type of “sticky”
  • Create a card attribute of “feeling” and give it a list of values: mad, glad, sad (or whatever is appropriate)
  • Create a card type of “cluster”, with the intent of connecting Stickies to it in a tree or hierarchy, as with epics, features, stories, and tasks

I’m experimenting with this now, and will share results as I get them, and what I learn in the process. While nothing that’s done electronically will replace face-to-face retrospectives, I’m hopeful that this will reduce the pain.

%d bloggers like this: