Category Archives: Uncategorized

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

Love,
Angela

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?

Can TDD help with a gnarly problem?

Here’s a puzzle for you. How do you represent counting numbers — integers starting with 1 and going on indefinitely — using letters, the way a spreadsheet’s columns are labeled? You’d use the letters A through Z, then AA, AB, AC thorough ZZ, AAA, AAB and so on.

Lots of folks think think is trivial when they first hear of it. I did. “That shouldn’t be too hard” is what I said to @kaleidic, when he brought it up. Ha!

I’ll leave it to you to figure out whether it’s trivial for you to solve. But for us, it was challenging. We wanted a functional solution. (Functional-ish, I guess, in the J programming language.) And we weren’t able to create it just by thinking hard.

Not knowing how to do this got me excited. I love the way we humans create new knowledge, and I wanted to try it.

Could we solve it by breaking it down into small pieces. Could we do that and produce something like a functional (denotative) solution? Could we see an algorithm evolve before our eyes through TDD?

[an aside: when I say TDD, I mean finding the smallest bit of success you can specify, and automating that — a unit test or micro test. Then writing the least bit of code to pass that test. Then refactoring the code toward the four rules of simple design. (No duplication, minimal pieces, expressing intent, and passing the tests.) And to watch design emerge from that process.]

So, we’re trying it.

First, Tracy (@kaleidic, that is) wanted to figure it out in his head, and write it down in one chunk, working. But that was taking a while, so we started looking for smaller pieces. We started writing unit tests.

At first, they were too big. We’d move forward a little bit, and then get stuck, and stop and look for a smaller chunk to approach.

We’re not done yet, but we’ve gotten far enough that it’s feeling like we might make it. If you’d like to see our progress, check it out on github. (Idiomatic J sometimes makes strong geeks cry. But this is unusually readable. Still not for the faint of heart.)

So what do you think? Can TDD result in the emergence of an algorithm to solve something like this? Or do we have to wrap our minds around a problem before we can solve it?

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.

WOW

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?

what’s the london school of tdd?

I’ve been hearing about the London school of TDD, and I’m puzzled. This post by Jason Gorman was helpful, but his examples confused me.

In describing classic TDD (as in TDD by Example), he uses as his example a program to express integers as Roman numerals. Then he gives an example for London school (as in Growing Object Oriented Software Guided By Tests) that is bigger, more complex. I’m not sure how to compare them.

I’m wondering whether London-style TDD provides the same advantages as classic TDD. From Wikipedia:

TDD can lead to more modularized, flexible, and extensible code. This effect often comes about because the methodology requires that the developers think of the software in terms of small units that can be written and tested independently and integrated together later. This leads to smaller, more focused classes, looser coupling, and cleaner interfaces.

I’m just starting to read the second book; I’ll know more as I get into it. But I’m really curious: does London school take the same sort of tiny steps that classic TDD advocates? Does it retain the benefits of TDD? I figure you get test coverage, but do you also get emergent design? Simple* design?

* See the four rules of simple design, as explained by Ron Jeffries.

Does math love emergence?

There’s something I’ve been wondering about around functional and agile. It’s about creating solutions, creating knowledge.

I see agile geeks pulling toward functional programming, from young coders here in Ohio to famous folks like Brian @marick and @unclebobmartin. And I’m wondering what it will look like when functional marries agile.

I talk to functional/denotative folks who are excited by math, and clarity of understanding, and composability. And I’m excited by those things too. They’re very cool.

But it seems like functional’s missing out on something important that TDD offers. Specifically, emergent design. Emergence is how complexity works, isn’t it? I think what the functional / denotative people are saying is that we should use our awesome rational brains to understand a problem and work out a solution. Is that what they’re saying?

(This TED talk is about how we solve problems without understanding them.)

How do brilliant functional programmers deal with complexity? Do they have to figure it all out, without letting emergence help?

I’ve been thinking it’d be very cool to create a cafe or an un-conference to address this. How do we get all the juice out of denotative mathy functional programming, and get the benefits of emergent design as well?

Functional agile: how does it work?

So I was thinking in the shower about how agile technical practices and functional programming both aim for something like “good” code, but then it occurs to me that — no surprise — “good” doesn’t tell me much.

I want to listen to what each “side” is excited about — not for “niceness” or for getting along or for unicorns and rainbows, but because I am all juiced about both, and I want to share that juice so I have more people to play with.

My first thoughts are that functional talks about correctness, and agile talks about utility. Functional programmers want clarity of vision, I think, with a precise understanding of the solutions they create, so they’re as simple as they can be, reusable and composable. And maybe agile developers are thinking about extensibility, maintainability, helping coders with stuff like staying focused, learning new stuff, avoiding getting buried in complexity.

I am guessing each would smile heartily at the things that motivate the other.

The thing that got me excited this morning was noticing that agile — even the technical practices — is about people. Pair programming, test-driven development, specification by example, and continuous integration are strategies for getting working, extensible, maintainable code, given that we are creative beings, going through life reaching for treasures without being able to predict the results of what we do. I call us mistake-makers; we poke at things and sometimes like what happens. We have brilliant days, and low energy or sad or un-brilliant days. We often don’t know what a solution will look like until it begins to take shape, and our solutions often involve learning, collaboration, discovery.

Here’e what I want to know: how do collaboration, discovery, emergence of solutions, and other agile values fit with functional programming? And as agile devs become fascinated with functional programming, what changes? Does this mean they leave their agile peeps behind? Or does the new functional stuff they’re discovering become part of their agile world?

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?

What is up with all the apairia?

The love of pairing, specifically pair programming with real geek joy, is seeming quite scarce. I keep finding myself around folks who, from my perspective, don’t get it. I want to really understand this. Get underneath it and inside it and get it.

So I’m asking: What are the causes of apairia? If you have personal experience, what do you hate most about pairing? If you’re a coach, have you seen people go to lengths to avoid pairing?

I am not asking to hear good stuff about pairing. This is all about a•pair•i•a: the fear of, hatred toward, or avoidance of pair programming (esp among fans of collaboration and code quality).

What are the causes? Are there effective treatments?

GeePaw sez…

If you’ve only ever had bad pairing experiences, it can seem like the best thing is never to pair again. I even know several coaches in that camp.

Consider dancing, another highly interactive joy-bringer. Imagine how you’d feel about dancing if:

  • your partners were all also first-time dancers;
  • you only ever danced in a tight closet;
  • your idea of dancing is for you to sit there and watch;
  • you get yelled at for stepping on toes;
  • you had the same partner for days;
  • …you get the idea.

We need to make sure every noob has at least one excellent pairing experience. If we fail to accomplish this, we can lose potentially terrific pairs forever.

What makes code readable?

I’ve been looking at some code I find pretty difficult to follow lately. Lots of reasons, not least of which is my inexperience. But I think there are other reasons, too.

In the process of remembering & unlearning Clipper syntax and replacing it with sql, I ran across this demo of aliases on the W3Schools site.

Assume we have a table called “Persons” and another table called “Product_Orders”. We will give the table aliases of “p” and “po” respectively.

Now we want to list all the orders that “Ola Hansen” is responsible for.

We use the following SELECT statement:

SELECT po.OrderID, p.LastName, p.FirstName
FROM Persons AS p,
Product_Orders AS po
WHERE p.LastName='Hansen' AND p.FirstName='Ola'

The same SELECT statement without aliases:

SELECT Product_Orders.OrderID, Persons.LastName, Persons.FirstName
FROM Persons,
Product_Orders
WHERE Persons.LastName='Hansen' AND Persons.FirstName='Ola'

As you’ll see from the two SELECT statements above; aliases can make queries easier to both write and to read.

This surprised me. Do y’all find the second easier to read?

Why *do* I love tiny tests?

I’m told that granularity is good, up to a point. But we don’t want to go too far. When I do go too far, I’ve been told more times than I can count that I’m being rigid or pedantic or mindlessly following rules. I don’t think that’s true, but I don’t have enough experience to defend my preferences well.

So, I thought I’d ask *you*.

I want to (remain open to learning new ways, and also) get better at explaining why I like:

  • Test names that describe a small characteristic of our system (typically called behavior). Like “a new account has a balance of zero” or “opens new accounts with a balance of zero”.
  • Asserts that match the name of the test.

I think that the tinier the test, the more likely we are to quickly know what went wrong when it breaks. I also think that tests that describe real behavior or characteristics:

  • are less likely to be stoopid tests—that is, not test for something we don’t want, like the ones I’ve seen that assert that for every new person, their name is Brian, and
  • are useful in letting us know what we have done and what we haven’t, and
  • help us find what broke, when they fail

What do you say? Should tests combine several asserts? Do we really need single-assert (single behavior, single characteristic) tests? And, are names important? How do we name tests?

GeePaw sez…

One of the reasons for me coining the term “microtest” was precisely to aim at the notion of very tiny tests.

I do occasionally have a test that contains a single behavior but multiple assertions. “One behavior” really means “One path through one function”, not “one variable changed”. I sometimes argue that we should add these two more assertions to test the two more changes made by a single path through the function. It’s not “one test per line of code”, it’s “one test per path”. Anyway, the argument is not very significant, and I yield quite easily.

Most TDD beginners envision and enact tests that test far too much in one test. If we’re to err in the size of our microtests, the error of making them too small is far less dangerous than the error of making them too big. If you can see how to write a smaller microtest, go ahead and do it.