Tag Archives: collaboration

How can I facilitate a productive retro when tensions are high?

Hey, need some advice… going to run a retrospective next Monday and I think there are some high tensions around the topic. Any good resources you’ve found about helping to keep people’s tempers down and make the retro productive?

I thought summarizing what I’d learned about facilitation over the years might be hard. I asked other facilitators on twitter what they’d say in this circumstance, and it got the juices flowing. (Much gratitude to @jlangr & @woodyzuill & dang, I know I’m missing somebody.) Here’s a slightly modified version of what I sent him.

Most of what I’m talking about happens in the first ten minutes:

* If you’re comfortable with it, I’d set the stage by reading the retrospective prime directive, and asking if everyone is willing to take that approach. (And get a nod or a ‘yes’ from each individual.) If you prefer, you can just talk about how we’re not here to judge, we’re here to learn how we can do better. Remind them that “agreement helps us connect; disagreement helps us grow.” Whatever statement you use, make sure everyone is in agreement. Ideally, cancel if you can’t get that.

* Speak openly about your intentions for this meeting, and be as transparent as you can about your concerns. Sometimes just putting voice to them can help people stay mindful.

* Next, make sure that the loud, confident people don’t dominate the conversation. How much someone has to contribute has no correlation with how easily they take the stage or how introverted or extroverted they are.

* If someone speaks in the first five minutes, they’re much more likely to speak during the meeting. You can do this by going around the room (after you’ve said your intentions for the retro) and ask other folks what they’re hoping to get out of it. Remember it doesn’t matter much what they say, you just want to get them talking. (But you can also glean things about what they might be holding back from what comes out in this opening circle.)

* See if you can get agreement around the room to some ground rules. Some of those ground rules should be about the role of the facilitator. Do they agree to defer to your judgment?

All of that is to set the stage for your retro. After that, it’s about paying attention to body language, who is holding back, who is getting irritated, etc. People want to be heard. You can often calm someone down when they’re agitated by showing them that you know what they’re saying. One way to do that is to write it on the board (somewhere on the side, sometimes) for later discussion. As you’re writing get clarification so they agree you’ve understood what they mean.

Lastly, keep asking yourself (or the room) “what is the problem we’re trying to solve?” or “what is question we’re discussing right now?” Making sure you have a clear focus on the specific topic at any point can help keep discussion from flying all over the place, and you from losing your hold on the group.

Remember, they’ve agreed that you’re facilitating, so at any point, if you need to put your hand up and say “hey” or “HEY” or “I’M SERIOUS HERE, HEY” you can do that. They might find you annoying in the moment, but they’ll probably respect you in the morning. :D


A pretty decent crash course in facilitating, I think. But I know there’s stuff I missed. One thing I’d add now is “If there’s any way you can get out of facilitating for a group where you were involved in the project, do that. A neutral facilitator is really really valuable.”

What else? What would you tell someone new to facilitation to focus on?

long live agile. is agile dead?

Pick your favorite agile luminary. Chances are, this year they’ve been saying they’re done with agile. No more, after this year.

I’m not positive my list is precisely correct, but I’m thinking I’ve heard this from Rachel Davies, Brian Marick, Michael GeePaw Hill, Andy Hunt, and I’m sure more folks (though I hesitate to name names, in case I’m wrong).

At RubyMidwest, I asked Andy Hunt about this. I’m sure I wasn’t at all articulate, but what I wanted to ask was this:

“I get that agile has become mechanical, and that’s a bummer. But as someone who fell in love with agile pretty recently, I don’t want to lose the… agility? The emergent design stuff, the inspecting and adapting. When I hear y’all saying you’re done with agile, I wonder what comes next? What do you envison is the alternative?”

And even though I’ve gone round and round with GeePaw about this, I think Andy is the one who finally convinced me. You know what he said? He said that

agile was a solution to a problem. And that agile worked to solve a bunch of them. Whatever replaces agile, he told us, will be the thing that solves the problems we have now.

Holy crap. That was convincing.

It also meant I can actually love all the empirical, emergent, collaborative stuff agile brought us, while I head off into the future.


What do you think? Is agile dead? Do we keep preaching it, coaching it, putting on conferences about it? What do you think the next decade looks like?

Are commitments the only way?

Have I told you folks lately how much I appreciate the answers I get here? I mean I’m grateful, and feel all warm inside, but also, I just really love reading them and learning what agile looks like in different places, for different people. I learn so much from you! So, if I haven’t said so lately (or even if I have), thanks.

So, last night, Justin @searls lit up twitter with this:

Agile friends: anyone out there still believe the “agile commitment” is worthwhile? My writing wants your (starkly opposing) viewpoint.

Later, once the conversation had taken off, he added this:

an agile team guesses what they can accomplish in an iteration, commits to it, and submits to ritualistic beating upon failure.

On the subject of commitments helping with trust, Zach @zspencer said:

Promises that are kept help. Promises that aren’t don’t.

To which Justin replied:

success is never certain, or commitment would be unnecessary. You’d recommend a team risk promising an uncertain outcome?

Wow. Big conversation. And there’s a question coming. First, the part where I ramble. :)

Are promises part of life?

…I don’t typically make promises. I have intentions, and I share values with people. I care about them having what they need to be happy, and I care about me having what I need, too. I love collaboration and I love getting things done. That’s something I want. But it seems to me a promise would mean I’ll do something even if I don’t want to, even if something changes so the original plan won’t work. Or even if I was wrong about what would, in the future, be possible (or a good idea).

If I “promise” to finish something by Friday, and I don’t, it may well be because I choose to do something else rather than finish. For example, maybe it took longer than I thought, and I valued getting some sleep and taking breaks more than finishing, for example.

Maybe I chose to organize my collection of e-books instead of working on the project.

Would a promise help with that?

If I did choose to organize files instead, we’d have a problem that’s not about promises, and not about Friday. It’s a problem the moment I lose interest in the thing we both want to create. Maybe it’s too hard (I feel stuck). Maybe I’m not engaged. Maybe I don’t have the tools I need. Maybe the environment at work is so pressured that I can’t think. A good retrospective might help us figure out what’s really going on.

But if we’re on the same side, you know that we both value what we’re working on together. Maybe in a particular case, “you” means a manager or business owner, and “me” means a developer. We share an agenda, a devotion to something of value, and we work toward that at a pace we find, not just sustainable, but exciting, interesting, productive. We work out a shared intention, and then watch what happens.

People often tell me I don’t really mean that I don’t make promises, so let me be really clear. My spouse and I don’t make promises to each other, either. If one of us were unhappy, neither of us would want that person to stay. No promise is required when we’re both doing what we value.

So that’s me. I would really like to know how promises and commitments look in your work. (I don’t mean to bombard you; there are a lot of questions here, but I’d welcome an appreciate an answer to one or two that jump out at you.)

Here’s what I’m wondering…

Do you use commitment on your agile projects? What do you mean by commitment? What happens if you “break” that commitment? What causes the commitment to be broken? What are the consequences?

How do you build trust on your teams? Or between your team and the business?

Have you found a way to work — successfully, in the world — without commitment? What does that look like? What changes when you work that way?

Is ‎Object Oriented the best?

I’ve been hearing sincere complaints lately about object oriented programming, about the Craftsmanship Movement, about Agile development practices. I hear from folks who are excited about functional (denotative) programming, who write concise little functions with one character names. (Some have objections to TDD, or think pairing is costly, but those are on the edge of what I’m talking about). And I’ve been wanting to really listen.

And of course, I hear a lot from folks who love TDD, love Object Oriented structure, love pair programming and long method names. And those are the folks I hang with, for the most part. So I’m wanting to listen to all of it, and see what I hear.

Though I sometimes hear that Object Oriented is “just better” or that TDD is “always appropriate” — what I call Argument From Fist-on-Table — that idea doesn’t help me much. In listening, I’m looking for better at what? and appropriate to what end?

So for many months I’ve been wondering why I’ve been pretty content to love OO programming (though I can see the mathy beauty of FP*) and why I love the things that get called “clean code” (without loving the setting of it as a categorical imperative). Talking to @kaleidic this morning in the wee hours, I realized what it is that I love about them.

I love the whole shebang — “craftsmanship”, TDD, the Four Rules of Simple Design, long names, etc. — because I love collaboration. Not just because it’s juicy and fun, but because it supports the emergence of good systems, and things like flexibility, responsiveness, changability. I love having a shared code base, and object oriented “craftsmanship” is a strategy for getting that.

I also love evolution, and folks following the sparkly stuff, so when I see smart friends like @kaleidic and @conal and @tunixman railing against object oriented programming, for example, I’m excited about what they’ll come up with. But I realize that whatever techniques emerge, they won’t just have to be about faster or even more accurate code to make me love them. They’ll have to fit into the collaborative social structure that makes Agile so beautifully effective.

* Really itching to work on Conway’s Game of Life without state changes, in fact.

A question anyway

So I answered this question for myself, but I am still curious. What is important to you about your preferred style of coding? If you’re an Agile developer, why do you love long names and TDD and objects? If you’re a Functional / Denotative Programmer, what do you love most about your code? Can it be made collaborative in the way I’ve described?

Can interview pairing work? How?

I’ve paired with a pretty decent handful of people, now — enough to know what it feels like to be grooving a little bit, coming up with ideas together, bouncing creativity and stupidity off one another until something lovely (or “good enough”) emerges. It’s delicious. It’s maybe exactly what humans are for. That’s how it seems to me. I’m not going to water it down; I really think it’s amazing and wonderful.

And then there’s this thing called “interview pairing.” Yes, I realize I just put out a flag saying I wanted to be hired, but dang it, this isn’t about bad hiring experiences. — I think I’ve “done fine” in those situations, and I’m ok with me regardless. I am what I am. — But this is about my love for pairing, people, and creativity. I just have to say it: I smell a rat.

Pairing is a delicious synergy, where two people are working together to build something. They keep each other focused, add bits of brilliance to the midst once in a while, and they catch one another’s stupid stuff with good humor. After a particularly stupid moment, one says “And this is why we pair!” and everybody is happy. Or that’s the hope.

To do that takes two people giving what they’ve got, welcoming one another’s ideas, welcoming one another’s mistakes, and both thinking about how to solve the problem.

If one person is evaluating the other, looking for problems, how is she going to be a good pair? If the other is scared, or just feeling the pressure of being constantly evaluated, how will he be brilliant, energized, creative? How will you find out what kind of pair someone is if you approach pairing this way?

My guess is that it’s possible to either observe from the sidelines while someone pairs (preferably, for fun) with another developer, or to be particularly mindful while pairing with someone you’re also evaluating, so that it’s fun and creative, saving your evaluation for after the fact. (Ideally, a nice, blame-free retrospective that you do together?) But I’ve definitely seen evaluative pairing look icky, and friends have told me about similar experiences.

(This reminds me that one key to making the workplace open and creative is to encourage everybody to remember that we’re all doing this voluntarily. That is, a pairing interviewee can remind herself that we are checking each other out, looking for a match. Neither party holds all the power.)

Question for the smart people: Have you noticed this issue? Figured out a way around it? Or maybe you think people being evaluated should just buck up and deal? ^__^ Seriously… how does evaluative pairing look in your workspaces?

GeePaw sez…

Interview-pairing is not pairing. It *would* probably help identify someone who claimed to have paired but actually never had.

Other than that, I’m not buying.

Does it predict success or failure at real-world pairing? Well, maybe, but only way out in the long tails. That is, only the very best and worst will do anything other than the range from “not bad” to “reasonably good”.

Does it predict raw coding talent? Not so much. Greenfield problems that take a couple of hours to solve, in a domain you don’t live in, are not terribly representative of the work of real coding.

Is it a good way to see if someone fits the team? Hmmm. I guess it’s not any better or worse than all the other possible ways to test that in a couple of hours.

Real-world pairing success is just too complicated, depending as it does on factors like these: which problem we’re solving, how much domain knowledge we have, whether the partner is confident or timid, the nationality of the pair, the time of day, the status of the car payment, the layout of the keyboard, the difference in the chairs, physical health, individual styles, and on and on.

Can there be Agile functional or denotative programming?

Somebody tweeted that they don’t like OO, and it made sense to me, because a few people I’m close to feel the same. Something’s bugged me about the anti-OO idea, though, and I just realized what.

Agile programming to me seems like a big, creative party. Like a barn raising, maybe.

If OO were thrown out in favor of the purest form of Haskell, for example, what would that look like? What kind of collaboration would happen? Pairing? How? What would we test, and when?

What would it be like working on a scrummy, xp-like denotative programming team?

GeePaw limps along with…

Beats hell outta me.

I spoze I could make some knowledgeable-sounding thing up.

True story: I do not know.

True meta-story: Is better to not know than to know wrong, or to make things up.

If I have a team who does functional or denotative programming, I’m certainly willing to try.