Focus on Whose Value?

Recently there seems to be a lot of talk about focusing on business value in the Agile/Lean blogo-/twittersphere. And while I think that there is value in talking about business value, it seems to me that many of those statements/discussions lack some critical aspects.

First, the often made assumption that businesses primarily exist to please their customers to make money is simply wrong, in my opinion. And actually, what happens in those businesses often disproves the assumption right away. I have seen business owners spending money on unreasonably sized fair booths, care more about the number and scope of projects worked on than their profitability, have the company grow and be stiffled by an oversized hierarchy without any apparent need etc. All these things were not done out of a focus on business value, but *to make the business owner happy*. Some of these business actually went out of the same, because what made the owner(s) happy wasn't financially sustainable in the long run.

Second, and not less importantly, there are also the employees involved. A common sentiment I see is expecting the employees (for example a software development team) to solely focus on what provides value to the customer, based on the fact that - after all - it's the customer's money they are working for. This seems to imply the main reason they are working is the money they get out of it. A quite sad perspective, isn't it?

I'd prefer for people to work on something that helps them live their passion, to find self-fulfillment. I'd prefer them by doing so in collaboration with their colleagues to be able to produce value that someone is willing to spend money on. Enough money to support the survival of the business.

Wouldn't that be a great world?

Tips for Being a Timekeeper

This post is inspired by a short twitter discussion with M. le Rutte. It made me reflect on how much I tend to struggle with keeping time in a retrospective (or other meetings), and what I've learned on the way.

In my experience, keeping the time is important for two reasons: expectations and hard constraints. You don't want participants to get impatient because an activity (and, by extrapolation, the whole meeting) is taking longer and longer, so that it seems there is no end in sight. You also don't want a participant to suddenly have to leave in the midst of action because he/she has another appointment.

On the other hand, you also don't want to follow the clock slavishly. You don't want to stop the flow of a productive discussion just because some arbitrary amount of time has passed. You want to focus on the people and their interactions instead of your clock.

Finding a balance between those forces that I'm comfortable with took me some time. Here are a couple of tricks and techniques I use:

Keeping the time is a service to the attendees

This is more like a principle that informs all the other tricks and techniques: the reason to keep the time is to ensure that the participants can have the best meeting possible given the time constrains they live in. The goal is to make the best possible use of a constraint resource.

Clarify expectations and constraints

At the beginning of a meeting, it should be obligatory to restate the scheduled timeframe. Additionally, I like to ask the participants what constraints they have on extending the meeting. It's vitally important to know whether someone has to be in another meeting at the scheduled end of the current one, whether people are eager to get home for the weekend, or whether they are totally fine with taking an hour longer than originally anticipated. Also, sometimes some people are fine with not attending the meeting to the end. All of this information has a big impact on how time needs to be handled by me as the facilitator.

Timebox activities

Keeping a meeting inside its timebox is much easier if you timebox activities, too. Even open discussions can easily be timeboxed: "let's talk about this topic for ten minutes, and then see how we continue the meeting."

Use a simple timer

Use a simple timer for timeboxed activities. The timer should be easy to read for the facilitator and show the time remaining for the activity. I prefer silent timers (no alarm when the time is over, see below) with an easy user interface. There is nothing more annoying to me than having to fiddle with a complicated timer setting at the start of an activity.

Use curt timeboxes, enforce them gently

Don't stop the activity immediately when the timebox is over (unless it has come to a natural end, anyway). Wait for a good moment to intervene; keep the constraints of the group in mind. Using short timeboxes gives you some slack to work with.

Let the group decide

If you feel that the group might want to continue the activity, ask them whether they want an extension. Remind them of the consequences for the rest of the meeting. Sometimes the best the group can do is change the goal of the meeting to be able to spend more time on an important issue that surfaced.

Use a parking lot

Keep an area on a flipchart or whiteboard where you can post topics that attendees want to discuss, but which are off topic for the current phase of the meeting. As part of closing the meeting, decide for each topic what to do about it. (I got this tip from the book "Collaboration Explained", which I highly recommend.)

Incorporate breaks

A meeting that takes longer than an hour should include at least a five minute break (more and longer breaks for longer meetings, of course). Get everyone moving and open the windows to get fresh air in. A short break refocuses everyone and actually generally shortens meetings.

Plan for alternatives

When you plan activities, for example for a retrospective, it can be a good idea to think of alternatives to long activities, that you can use instead when time runs out. This allows me to react more flexibly and relaxed when something takes longer than planned.

Blowing the timebox isn't a failure

As long as the attendees agreed on spending more time in the meeting than planned, it's a good thing that you reacted flexibly to the needs of the group. Keeping the time doesn't mean rigorously enforcing the original plan, but keeping everyone aware of time issues, and deciding collaboratively and responsibly based on needs.


That's what's coming to my mind right now. What are your tips and tricks when it comes to keeping time?

Index Cards are Tools, too!

Really, they are! As are white boards, pens, flip charts and all the other stuff we Agile "dogmatists" like to insist on using.

In fact, they are not just tools, but highly flexible, collaborative, simple-to-use tools. And that's not the only way they beat the "high-tech" software tools. Try to find a monitor that comes even close to the resolution of an index card. Or a company that can afford to decorate all their walls with white-board-sized computer displays.

So, please, pretty please, stop telling people that Agilists advice against the use of tools. Start telling the world that in fact we love tools, that we are in fact passionate about using the most effective tools for the job at hand. Which just more often than you might yet be aware of, means using an old fashioned low tech tool.