Test Driven Meetings

Brett Schuchert — Thu, 12 Jun 2008 00:28:00 -0500

I’ve seen it as I’m sure you have. You look in to a conference room, there’s a spreadhseet or a word document or some such “deliverable” displayed on the overhead. There’s one person engaged, talking about it and N – 1 people with glassy-eyed stairs, hoping for the meeting to end.

What’s even worse. You have the next meeting in that same room and you know your meeting is going to be a repeat of the previous meeting. Even so, it irritates you when they go over because that meeting room is yours.

Make an agenda! That’ll solve it.

Maybe, but probably not. Most agendas are task-orietned rather than goal-oritned. So you might make it through the agenda but what have you accomplished besides following an agenda?

When people discuss wasted time, do they joke about meetings? Do they? Are you listening? If people are joking about meetings being a complete waste of time, then the meetings are probably a complete waste of time. (Ever consider keeping a count of the number of times you hear the same thing during a single day? You’d be amazed what you can learn by just listenting to your team.)

Does that mean all meetings need to be that way?

No

Why were we told to write agendas?

To keep focus and know we’re making progress

What purpose does a meeting serve in the delivery of value to someone who’s got $$ to spend?

That varies by the meeting

What do tests written first (unit or acceptance) accomplish?

Exress how we know somethign has worked

Can we do this with meetings? If we did, what might it look like? Would the very act of trying to express success critera for a meeting have a profound effect on how a meeting progresses? Isn’t this really just Covey’s 2nd habit (begin with the end in mind).

What if you wanted to try? How might you begin?

It’s all about he benjamins.

The first thing you need to ask is how what you’re going to do in a given meeting directly or indireclty adds value. Of coruse, to do that you need to know what is valuable.

Suppose, for example, you need to have a traditional requirements meeting of some sort (there is a traditional requirements meeting, it is usually bogged down in implementation details or it’s stuck in “how” mode versus “what” mode – the more you talk about database columns, the more you’re deep into requirements … NOT!).

OK, so take a step back. You think you need this meeting on requirements.

Why?

So we can figure out what this feature needs to do

Why?

So we know what to what to write, what schema changes we need

Why?

So we can implement it

Why?

Because customer X has a contract and we’ll be in breech of contract if we don’t write it

AH! That sounds like we’re getting close to something valuable. We have some feature that’s been promised to a current customer. OK, so before we go any further, that information needs to be part of the context for the meeting.

What’s been promised? What does the customer think has been promised?

If you cannot answer this, you are in deep trouble

OK, so you have promised some feature. Apparently that feature is ill defined (or you wouldn’t need the requirements meeting). So, what problem does that feature address?

If you know this, then you have something to grow. Maybe your first attempt at an acceptance test for your meeting is something like this:

This meeting is a success if we have described scenarios that cover what this feature will do for at the top three uses of this feature

OK, so now here’s your agend:

This requirements meeting is to address feature X
We need to discuss this because customer X has been promised this feature and if we do not do it by (insert a real date here), we are in breech of contract
This meeting will be a success if we can describe scenarios covering the top three uses of this feature

That’s a start. I can think of ways to improve that. Here are a few examples:

How do we define top 3? Is that something we know or something we need to accomplish?
What do we mean by “describe scenarios” does it include:
- Acceptance tests
- One or more stories (or maybe it is just a scenario in a use case, pick your requirements coolaid)
- Used by whom? Are there different roles? Is that important?
- What about a timebox? (Maybe that’s implicit because it’d be an electronic request)
- ...

Here’s the thing, do you think you’d be more inclined to think a meeting described thusly would have some value?

Object Mentor Blog: Tag meetings

Test Driven Meetings