The calumet in the form of a biscuit

Yesterday was spent in the company of supplier in Bristol. It might seem like an outdated solution to bother to travel to a supplier, but having worked close with both business people and developers, I truly believe that a personal meeting beats it all. In all our upcoming meetings, which probably will be held over the phone or using our web based conference systems, we will at least have a face and the meeting in memory.

Working with agile values we all know this. But in the days of digital communications and green values, it’s so easy to think that it don’t make such a big difference.

The problem is that in the case of software systems, the developers are not included in the actual meeting of clients. Perhaps XP set aside, many use proxies or let the manager meet the customers. If I can chose, I think it’s better if the developer meet the customers. Customers like seeing the guys working with their tools and developers will (I think) do a much better job if they see the actual people and hear the words from the source

Sitting there eating biscuits and drinking tea, it almost felt like the traditional calumet. The native Americans were not stupid when they applied this ritual. And the idea of two persons sitting in different parts of their world sipping on a pipe of their own is not the same thing. Why would we ever think that modern meetings are different?

Getting to the point using PowerPoint

When it comes to giving presentations, you can divide people into those who use PowerPoint (or something like it) and those who don’t. Those who don’t can be divided into those who instead uses Word, Excel or something for their presentations (they don’t think they do but making a speech over an Excel spreadsheet is using Excel as a presentation program) and those who uses no programs at all. This latter group either does this as a conscious strategy (those are often the really good presenters) and those who just happen to be talking. This post is not about the people who doesn’t use programs for presentations. This is about the PowerPoint warriors. But they come in very different flavors.

Slides are expensive stuff

First we have the group who thinks that Microsoft charges by the slide numbers in the presentation. They tend to crank up as much text and tables and unreadable pictures as they can to cover up the background. You can recognize this group by “Well, you can probably not read this, but it says…”.

My slide show must have at least 50 slides

Then we have the group who just made as many slides as they possible could. Half of the slides makes no sense to the presentation and somehow you get the feeling that this presentation was made for ten different audiences. You can recognize this group by “Well, we don’t have time to go through this slide, but “ or “Hm, well, this is probably of no interest to you, but “

I need some support when I’m giving a presentation

This two groups are both linked to the group which needs some support when giving a presentation. They turn to the presentation and reads from it instead of giving the presentation themselves. You can recognize them from the back of their head because that is all you are going to see during the presentation. The worst ones are the ones who are actual pointing at the words like we cannot read. Or did I mistake the presentation with a karaoke exercise?

I have to much time and think PowerPoint effects are really fun

Believe me, I know that effects, pictures, etc can be really important tools for making a presentation remember able. But that’s when the effects had a purpose and was chosen deliberately to strengthen the message. Random text flying over the place does not make the message stick. The group here is probably the folks no one really knows what they are doing and you recognize them by the sensation of sea sickness after leaving the presentation.

So how do I get to the point?

The main problem I find is that these groups do not value the minds and the time of their audiences. Instead of preparing their message, they present an audience with the basic material for a presentation.

So, lesson number one is understand which message you want to present. Have a commander’s intent for your presentation. That is: if people don’t get anything else from the presentation, what do you want them to grasp. And then focus the presentation around that intent. Select your slides with care and make every slide mean something important. That does not putting in as much as possible on each slide. No, it’s having as little as possible on each slide but that the intent of that slide is clear to you and to the audience. If you follow that rule, you will learn your slides and you won’t have to read from them.

After I read Made To Stick, the number of slides in my presentations has lessened but it’s interesting to see that people can often visualize all of them after a presentation.

Knowing what you want to accomplish pays off.

A simple strategy for making meetings being on time

Since we work actively with lean in our strategic work, being on time when it comes to meetings is important. If you have ten participants who have to wait for 5 minutes for the guy who is late, you waste 50 minutes.

One reason for people being late to meetings is that they are late from other meetings. We can all understand that if you have a meeting between 2 and 3 and the next meeting start at 3, you will be late.

I had the first steering meeting for one of my projects today and one of the suggestions from the group was that meetings always start 5 minutes past and end 5 minutes before. So, the next steering group will be between 14:05 and 14:55. This leaves time for toilets, coffee or just sprinting between conference rooms.

But someone might add that why all these meetings and of course the amount of meetings is also something that should be debated. But if you’re going to have a meeting, why not making a bit easier on the participants.

A successful meeting

I took over another project the other day. The project hasn’t started and the problem was that we were waiting for some technical specification from a supplier. I was told that we’d been waiting for a month to get some information, but we still hadn’t gotten it. The business people are really eager to get going, so, you know…

I talked to the guy who’d been in contact with the supplier and asked him which information we needed. It turned out that we needed a specification for a certain function (X) so he could ask the operations team how much time this would take. It turned out that he hadn’t talked to the supplier, but a lot of e-mails had been sent between him and the supplier. He’s no technician and neither am I. I can admit to that I really didn’t understand what X was. So I asked if our techies had spoken to their techies. The answer was no. So, I called the supplier and asked if they had a techie to spare during an hour telephone conference. I sent all the e-mail conversations to our operations and then turned up on the meeting.

We discussed first and I asked what X was all about. And then the guys said that they thought it was something I actually know what it is but since I hadn’t seen this in other systems, I was puzzled that it had stopped the project. I asked if X was a requirement in our solutions. It wasn’t. Then we called the supplier and asked if the previous e-mails had been about X. It had. We then asked who had asked forX in the first place. Then it turned out to be that the supplier had asked if we wanted X. And there had been a huge misunderstanding that X, which we don’t want, was mandatory.

The meeting was over in five minutes.

Something are not suitable to discuss in e-mails and sometimes it’s better to leave the techie stuff to the techies.

Was it a successful meeting?

Why did you feel that a certain meeting was "successful"? Did you leave the meeting without long debates or did you finally win over the team from The Other Guy, that bastard who always gets his way? Or did you feel confident that the right decision was taken, even if you really thought that another solution is better from your point of view?

In most leadership courses, time is spent on getting the participants to understand who they are. Myers-Briggs is a scale many of you are most certain familiar with. Dave Nicolette writes on his blog about a simpler classification which can be used when describing meeting strategies among team members. In a very interesting blog post, he sees three strategies:

1. The ones who’s highest priority is "To win"
2. The ones who’s highest priority is "To find the best solution"
3. The ones who’s highest priority is "To avoid conflict"

Be sure to read the example in the blog post. We’ve all been there. Heard the discussion. Met the types.

And as Nicolette writes, you need all these traits in a team and a discussion! What if no one cares enough to win the discussion? What if no one cares if the best solution is selected? What if everyone is so involved in the discussion that they don’t care if the time spent and the risen conflict is really worth the trouble?

But it is also interesting to see which traits are dominant in a person in a specific context. A person can feel very strongly about an area and even if he’s the guy who always avoid a conflict in other cases suddenly becomes the guy who have to win since the area of discussion is a treasured and soft spot. And if there is a personal strain between two individuals, two who in other instances are the ones who try to find the best solution turns has to win the debate since the other guy is presenting another suggestion.

How can you use this classification? Well, I really hate classification of individuals into one, single package. What I like about Nicolette’s classification is that it’s context based: you don’t classify a person. Instead you classify how a person works in a specific discussion, where the context is a function of area of discussion, other team members and situation. You can therefore use the classification to analyze the discussion as such: if we spent 12 man hours on a discussion and the end result was still poor, could it have something to do with how the discussion worked?

So, what do you do if your discussions are not productive? Nicolette points at the possibility to remove a team member. Since this changes the context, everything can become better. I believe this can be a good solution if there are personal strains between people, turning them into must-wins or avoid-conflicts or if someone is incompetent without realizing or caring about it and still use the must-win strategy. Both these scenarios are sad and leads to a spiral of death to the team. Either you handle the personal conflicts, increase the competence (the problem here is if the incompetent person does not want to admit to lacking competence) or you make changes to the team structure. But one should not fall into the pointing of fingers: it’s HIS fault that the system is built this way. That is truly unproductive.

Agile teams are self organizing but that does not make them free of unproductive discussions and here I think we need great leaders and involved leadership. A great leader handles a personal conflict before it gets out of hand. A true leader handles a team member with lacking competence, whether or not that person admits to it or not. An agile leader evaluate meetings and make sure that they are productive, and that does not mean that "a solution was decided on" but also evaluates the long term effects. You cannot place this burden on individual team members. It’s great if the teams can solve these problems themselves but we all know that handling personal conflicts, consistent flow of bad decisions and lacking competence is a harder apple to bite.

Please, let me get back to work… A developer’s view on meetings?

Leon Bambrick at Secret Geek calls it Meetingitis. Leon’s description of the situation is as follows:

1. Q:What do managers do when they’re stressed?
   • A:They call a meeting.
2. Q:What gets managers stressed out?
   • A:When projects are not making progress.
3. Q:When do projects fail to make progress?
   • A:When people spend too much time in meetings.

I don’t think Leon is alone: developers don’t consider meetings as work. And you’ve probably heard this before: ‘When will this meeting end, I really need to get back to work…’

But then, developer’s complain that they are never informed, included in early discussions and have to pick up the trash after other’s decisions. And where are these decisions made? Probably in a meeting. So what’s the problem? Are the developers invited to the wrong meetings (a k a then ones where decisions are made) or are they not paying attention? Or are the meetings held when the developers really don’t have the time so they are thinking about something else? Or is the form of the meetings inefficient or unclear? The answer to this question is probably: all of the above. And probably ten other reasons I didn’t come to think about this Saturday evening. But think about it, talk about it and make it work.