Scalability. Great presentations scale. Most importantly, a great presentation can always be scaled down. If you can deliver a great presentation in 45 minutes you should also be able to say the same thing in 10 minutes. Or in a 45 second elevator pitch for that matter. So, how do you create a presentation with that in mind? My advice is to start with the one thing that you want the audience to learn, then build on that.

This blog post is part of my Duoblog Series. For each topic I ask someone I know and respect as an expert on that topic to write a blog post with the same title as my post. We then post them at the same time without knowing what the other person wrote.

For advice on creating a great presentation I turn to Claudio Perrone. When I first met Claudio two years ago he had just been accepted to speak at a conference, his first public speaking engagement. Claudio is an amazing learner and quickly studied everything from storytelling and moviescript writing to creating powerful visual presentations. I have been fortunate enough to see him present a couple of times so I know that he can really engage an audience with stunning visuals and a great story.

Read Claudio Perrone’s answer to “What is the secret of great presentations” on his blog.

So much to say, so little time

Picture this: You have been given a chance to present your company’s new product in a 45 min presentation. You want to create a great presentation to make people really enthusiastic about it. So, you fire up Powerpoint and start making bullet points for everything fantastic you can say about your product. The more great things you mention, the better people will feel about it, right?

Unfortunately, this seems to be what a lot of presentations are about. The speaker tries to mention as many things as possible in the time they have available. Each slide has so many bullets that she does not even remember to mention all of them. When time runs out she jumps to the final slide to wrap things up, while mumbling that there were more interesting things to say if only there had been more time. The audience remembers a fraction of what was said, and probably have a hard time summarizing it.

I believe that this happens when the speaker starts by considering how much time is available for the presentation and then works to fill that time with interesting stuff, rather than the other way round.

Creating a great presentation

Start by defining what you would say if you only had a short moment to say it, no matter how much time you actually have for your presentation. There is probably a specific reason why you are giving this presentation. Whether you are talking about a new technology or an idea you have, there is something about it that you think is important enough that you want to tell others about it. This is the core message you should deliver, and it should take no longer than 45 seconds to deliver it. If you can make people more enthusiastic and wanting to hear more about the topic then you know you have succeeded, and you are ready to add more things to the presentation.

If you have more time available, think about how you can make that message clearer and more powerful. Resist the temptation to add another core message to the presentation. Instead add some supporting ideas that give some more detail, still with the core message in focus. To avoid adding too much consider what you would say if you had 10 minutes to present your idea. If you have even more time then add another level of detail, this time giving further support for the ideas introduced in the previous level. In this way the presentation scales up, and everything you say is still related to the one central idea you want people to learn from your presentation.

A powerful message that people will remember

Now that you have taken a different approach to creating your presentation you will need to think about how to frame the core message so that the audience will understand and remember it.

Put yourself in the shoes of your audience and ask “What’s in it for me?”. If you do not give people a reason to remember it, why would they? Put your message into a context that the audience can relate to. Describe a situation or problem that they will recognize from their own life, and then present your idea and how it solves or relates to that problem.

Introduce the core message very early in the presentation, right after setting up the context it should be delivered in. Also repeat it throughout the presentation. Specifically make sure that you end with the core message again, since people generally remember best what they learn at the start and end of a learning session.

Finally, do not be afraid to use Powerpoint or other visual aid. People favor different learning modes (auditory, visual and kinesthetic), and multi-sensory learning is a powerful memory aid. Seeing keywords in written form, accompanied by powerful images, can help your audience remember better. The important thing is to avoid confusing presentation with documentation. A bullet list with some key points is a great aid when later reviewing something, but that does not mean it has to be a part of the actual presentation. Instead provide a separate file for documentation.

Scale your presentation up from the one thing people should learn

In summary, creating a great presentation starts with a clear and concise core message that the audience can relate to. The presentation is then scaled up level by level to add more detail, all the time repeating that core message. If you feel the time is to short, make it shorter.

When thinking about how to get inspiration for blogging I came up with an idea I have named Duoblogging. The concept is simple. I choose a topic that I want to blog about. Next, I contact someone I know who I respect as an expert on that topic, and ask that person to simultaneously write a blog post on the same topic. We decide together on a title we will both use for our posts, but other than that we do not know what the other person writes. We then both publish our blog posts at the same time, linking to each other. The idea is basically that one plus one is greater than two. By reading both posts readers will hopefully be able to infer even more than what is said in the posts.

I will be updating this post with links to each duoblog post as they are written in the future. Stay tuned!

Duoblog posts

• 2009-06-29: What is the secret of great presentations?, with Claudio Perrone

I recently participated in a discussion regarding pair programming. There were not really anyone against pair programming in general, so the discussion was mostly about what situations or types of tasks are good for pair programming. What always bothers me with this type of discussion is that it seems like most people consider pair programming to be something we decide to do because it fits a specific situation. In my opinion it should be the other way around. For any given situation we might decide not to pair program because of some circumstance, but that should be a conscious decision to disregard our normal standard of always working in pairs.

The problem with considering pair programming as something we decide to do in some situations, as opposed to deciding not to do it in some situations, is that it is too easy to stick with the norm by not making that decision. “This task is too simple, that task is too complex and requires some serious thinking, I do not feel like pairing today” are all easy excuses to use when you do not have to answer why. A conscious decision of disregarding a work standard requires much more than “not feeling like it today”.

When I propose that pair programming should be the norm people often react by listing situations where it would be wrong and wasteful (according to them at least) or by identifying problems with working with someone else all the time (“what if someone smells bad?”), almost regressing to an anti-pairing opinion. I think this is because this concept is so foreign to what we have been taught for so long, and that most pro-pairing people have actually not tried pairing as the standard way of working like I propose. To this day I have never met anyone who have actually tried working this way for at least a month but would like to work any other way.

For a great story of someone who did try real pair programming I really recommend Rod Hilton’s post I Love Pair Programming. I’ll end with a quote from that post:

I see pairing work so well every day that I consider my career prior to my current job to have consisted mostly of wasting time.

Together with Marcus, I recently designed and led a workshop on refactoring, unit testing and other techniques for producing good code. To start the day off we asked the participants to list some characteristics of good and bad code. After getting most of the usual suspects on the list, one participant shouted out a new one, which should be pretty obvious. On the good code side is my code, on the bad code side is your code. Everyone had a laugh, but the fact is this is probably true if you ask most people about code.

As I said, it should be quite obvious that most people consider their own code to be better than someone else’s code, but I think we can make some profound realizations from looking into this more closely. There are two questions that are important to think about here. First, what is the effect of this issue? Second, how do we use this knowledge when working with a development team to help them produce better code?

An escalating mess
If I encounter some bad code, I will try and make it better. Since I believe my code to be good code, I will of course try and change the bad code to become more like my code. So, the code is better and everyone wins, right? Well, what about the other guy? He sees my code, and since from his perspective his code is better than mine, he will of course try and change it so it becomes more like his code. And round and round it goes. Each of us are trying to make things better, but together we are actually producing an ever escalating mess.

So, the important question then is how can we help developers realize that their good code might not be the best for the team as a whole? My bet is on communication. Using practices of communication and reflection between the developers in a team, we can create a common understanding of what good code means to us, and break the escalation.

Talk about code
Any time spent away from programming, instead talking about code and coding, is time well spent in a development team. If we want to get a common understanding of what good code is, then we need to have some formal structures in place to insure that this talking about code happens. Do you use pair-programming as the default mode of working? Do you do code reviews, where everyone on the team sits down and talks about some piece of code to learn from each other about how it could be improved? Do you collectively break down user stories (or other requirements) into tasks, using CRC design and similar techniques for exploring what a good design would be? Are you running a study circle?

What techniques and practices does your team use to make sure that you talk about code enough to have a common understanding of what good code means to you?

Note: This post describes an anti-pattern that I have observed with software development teams. I wrote it as a contribution to Ola Ellnestam’s under-development book on Software Development Team Anti-Patterns. I recommend taking a look at Ola’s book for more anti-patterns. I like the short and concise definition of anti-pattern that Ola use in the book, taken from Wikipedia:

An anti pattern is a repeated pattern of actions, a process or structure that initially appears to be beneficial

The Helpful Teacher

Introduction
“If we would only use test-driven development, our design would be better.”
As the self-designated technical leader of your team, you are constantly trying to help your colleagues understand and use good practices for writing high quality code. Even so, the code base is a mess and it is not getting any better. You have tried everything, from buying them books (with your own pocket money!) to showing them your own great code during a monthly meeting. The best you have managed is to convince some of them to try, but after a short while they always give up while telling you that it does not work. You are back to square one, or worse since now there are people saying that the practices you are promoting does not even work!

Description
Studies in psychology* have shown that if we ask a person about their ability and competence in some skill, most people would estimate themselves as ranking above the average. (For an example, try asking people about their driving skills.) If we ask a group of people to estimate their own competence relative to the rest of the group, again most people consider themselves to be among the “better part” of the group. In fact, as the above referenced study shows, even the most unskilled people estimate themselves above average, because coupled to the lack of competence is a lack of awareness and understanding of that skill.

To be able to teach someone to use a new skill, they must at least see some need for it. Otherwise, from their perspective, you are only trying to push something not needed on them. Since they are unaware of the problem you are trying to solve, and therefore cannot distinguish your proposed solution from their defunct practices, all of your teaching goes in through one ear and directly out the other. “We are practicing test-driven development. We write tests in a Word document and run them manually before release.”

Refactored Solution
Before you can teach someone a new skill they must become aware of the need for the skill and their own deficiencies in that area. In other words, if you want to promote good technical practices for writing quality code in your team, you must first talk about the need for high code quality. The team needs to have a common understanding of what code quality means to them, otherwise everyone will just think that they are writing quality code and they do not need to learn new practices for improving on it.

Here are a couple of things you can try with your team to increase awareness on the value of high code quality, and to create a common understanding of what it means to your team. The thing in common between them is that they all encourage reflection and discussion.

• Pair-programming
  
  The mother of all knowledge-sharing techniques. If you want to spread an idea to your colleagues you should never sit alone and program. No matter how nice code you write no one is going to notice it, and the practices you follow to achieve it will be completely invisible to the others. Try and spend as much of your time as possible working together with someone else. Do not push for all the practices you would like everyone to use, but use the opportunity to show your partner what you can do and the great results that follow.




• Code Reviews
  
  Lots of organizations use code reviews as a way to achieve higher code quality. However, in my experience they are used in a command-and-control way, where you as the developer submit your code for review to the mighty architect, who then returns it with a number of things for you to fix. While some bugs and other problems can be avoided this way (depending on how much time the reviewer has to look into the code), it is not an efficient way of promoting high code quality in a team.

  Instead, schedule a regular meeting where the entire team meets to review and discuss some piece of code from your project. As an alternative you can pick some open source project and review code from there. That way no one in the room is criticized, and it is easier to have open discussions about issues in the code sample. Rotate the role of selecting the code to be reviewed, make sure everyone has the code in advance to review ahead of the meeting, and then spend an hour or two discussing it together over coffee and a snack. If you want to you can follow up by actually implementing the improvements discussed in the meeting.

• Coding Guidelines
  
  Again, most teams have a coding guideline that prescribes what is good code. They can contain things such as naming guidelines, where to put the curly braces and how many spaces the indentation should use. Sadly though, these are documents written a long time ago, by someone who is not part of the team or sometimes even no longer in the organization. As can be expected, they are not meticulously followed and it is not uncommon for people to be completely unaware of their existence.

  Creating a coding guideline for a team should be a collaborative activity for that team. Gather everyone once a month, discuss what people think is important when writing code and find out what everyone will agree to do. Write this down, preferably on large flip-charts posted in the team room. After a month, meet again and continue the discussion. It is not really the results that are the most important, the discussions are where awareness and understanding is spread throughout the team.

If you can create awareness on the need for high code quality you will not need to teach your colleagues how to do it. They will already want to learn, and all you have to do is answer their questions. (Not quite, but lets not get into that here.)

No matter how important you might think it is, you should not migrate your version control system when you switch to a fancy new system.

Something I see again and again is a team wanting to switch from CVS/VSS/TFS/SVN to something better, like SVN/git/BZR/Hg. In preparation for this move, they spend a lot of time seeing if they can find some tool that can migrate their history to the new system. After considerable effort, they decide it is no tools can do it well, and go ahead and do the switch manually. After some initial bumps, everyone is happy with the new system, and the team realizes that they haven’t missed the history at all.

So, my suggestion for anyone wanting to switch is this:

1. Install the new VCS
2. Make the old VCS read-only
3. Make the first commit in the new system as just the trunk from the old system, sans all .svn/.ssc/.cvs files.
4. If you need to look at old history, the old VCS is still there

If you have branches, merge them in before doing this. If you have long-lived branches that you want to keep after the switch, you probably have to do some manual magic. Do it manually. Don’t spend any time looking for tools.

Of course, you will not listen to this advice, and spend a number of fruitless hours looking for something that can do the switch for you. I know I would…

For the last couple of years, I have been extremely privileged to have the chance to work full time with some of the smartest persons I have ever had the chance to meet. I just want to share with the world who they are, and what they have taught me.

Chris Hedgate:
I have worked with Chris on and off for the last seven years. I have learned from him all along, and I still do. Chris has changed so much during these years that it is not even funny. He has gone from a kick-ass SQL dev with a little C# expertise, to exceptional object oriented developer, to an inspiring coach and great facilitator. And he can still code… One of the things I like about Chris is that he is always open to new ideas and projects. I am absolutely certain Chris will reach great heights in this industry, and I will be to be the one in the background saying “I knew him back when…”

Marcus Widerberg:
We (Marcus and I) did our first agile coaching assignment together almost five years ago. We noticed early that our interactions were not always smooth, but I learned from each and every one of them. Of the three, Marcus has helped me most to find new communication tools. He has a way of pointing at exactly what I say or do that might offend people, and he is not afraid of saying it. Marcus has also shown me that preparation is not only a bad thing. When he prepares and facilitates a meeting, I know that the meeting will be successful. I see Marcus presenting his papers in OOPSLA in a near future. I want a signed copy!

Joakim Karlsson:
I met Joakim through his design of a system I was hired to work on. He took parental leave, and I stepped in to implement his design (I know, it sounds crazy in my today-agile-ears). When he came back we worked side-by-side for some time, and I remember doing “guerrilla agile” with him – installing CruiseControl.NET on my laptop. Joakim has taught me a lot about how to work as a consultant – even though I have ten years experience in it, and he just started… I like watching him work with our clients, and in his relaxed, laid back manner steer them gently to better code and greater understanding of the system we work in. I try to copy him, but it’s hard…
When we joined forces with Joakim a year ago, I knew that he was a good developer, but I didn’t expect to find a great new friend in him.

Blueplane didn’t work out, but I had a good time, and I learned so much it would be crazy to regret any part of this experience.

Things are changing. We are closing down Blueplane after two fun and interesting years. I have had a great time and learned a lot and I am sure my colleagues would say the same (here is what Andrés and Joakim say). Now I am looking forward to a new beginning, although I do not know where right now. If you have an idea or suggestion, please let me know. I’d love to talk.

Okey. Here it is!

Blueplane slutar! Efter två års spelande lägger vi av. Beslutet är taget med största enighet och i största samförstånd. Alla planerade produktioner och turneer inställs. Beslutet gäller med omedelbar verkan. All ryktesspridning i frågan är osann! Jag vill ge ett speciellt tack till Leif Carlsson, ex-VD på Playahead och Carolina Palmquist, ex-VD på Travelstart. Tack för att ni trodde på oss. Lessen att kapitalet inte insåg hur bra ni är.

Tack också till alla som fortfarande inte förstår hur man ska utveckla mjukvara – ni gjorde Blueplane möjligt.

Kampen går vidare! 1,2,3,4, SLUT

To my English readers:

We have decided to close down Blueplane. It has been fun, exciting and immensely  educational. What I will be doing in the future is still not clear. Have a suggestion? Let me know.

I always start retrospectives, in fact more or less any meeting, by having the participants check in. After introducing the retrospective and describing its purpose, I let each participant in a round-robin fashion answer some question I ask. By having each participant speak in turn, the tone is set to show that during this meeting everyone is allowed and encouraged to be an equal participant. If we instead would just ask if someone wants to say something, those who are unsure, shy or quiet would probably not say anything and would be more keen on staying in that mode for the entire meeting.

The simplest way of doing this is to simply ask each participant to say something, for instance describe the past iteration in just one word. This activity, and some variations of it, is described as the Checkin activity in Agile Retrospectives, by Esther Derby and Diana Larsen.

However, if the group are becoming more used to participating in retrospectives, this activity can feel a little boring if used every time. This is a perfect time to spice it up with some more creativity from the participants. By having people draw something and then describe why the drew that specific picture, not only do we get a more rich picture (no pun intended) of their mood and feelings, but it also starts the creative process in everyone’s head.

Purpose
Invite participants to be active participants of the retrospective, and help them to get in a creative thinking state. Share the mood and thoughts people have with the rest of the group, including the retrospective leader.

Description
The retrospective leader asks participants to think about how they would describe the past iteration. Each person then draws a simple picture to symbolize their answer. Finally, in a round-robin fashion, everyone shows their drawing and describes what it shows.

Time needed
Ten to twenty minutes.

Materials needed
I recommend that you supply each participant with a magnetic drawing board (or even Doodle Pro for more size). A simple piece of paper and a pen could of course also work, but see the Motivation section below.

Steps

• Ask the participants a question. You could ask them about their perceptions of the past iteration, or just their current feelings. Depending on the situation, you might want to hear about their feelings of this retrospective or just the work that was done.
• Tell everyone to draw a picture that symbolize their answer.
• When they are done (or time is up), ask them in turn to describe their picture to the rest of the group. Some will just say what it shows, others might describe why they drew that specific picture.
• Listen carefully to signals indicating a safety concern. If necessary, follow up with an activity to create more safety for the retrospective.

Motivation
In Pragmatic Thinking & Learning, Andy Hunt tells us to “add sensory experience to engage more parts of the brain” in problem solving and creativity. He goes on to write that “when you involve an addition input mode, you are activating more areas of the brain – you’re bringing more processing power online [...]“. So by drawing our thoughts and feelings, instead of just speaking them, we are thinking more effectively on this ‘problem’, and also setting our brains up for creative work.

And of course, a picture says more than a thousand words! In my own experience, people who can seem very shy and quiet often draw very descriptive pictures, and are normally quite happy to talk about them.

The question of using simple pen and paper or something like a magnetic drawing board comes down to the purpose of the activity, and the specific situation you are in. The ease with which you can erase a drawing board can create a sense of safety. “It does not matter if you cannot draw very well, it is just a doodle that will be gone in a minute.” The playful nature of it, a children’s toy, also helps in this regard.

On the other hand, you might want to use the drawings later in the retrospective for some other activity, or even bring them back to the team room, in which case paper trumps.

Variants
Two specific variations of this that I know of are the Project Weather activity (I will talk about this in an upcoming post) and my friend Michael‘s Car Instrument Board activity (which I will let him write up a description for himself).

Creativity++
Alt. 1: To really get the creative thoughts going, have the participants pair up to create a drawing together two-and-two. Tell each pair to take turns adding something to the drawing. You can start them off by giving them a subject to draw, such as an animal symbolizing the past iteration. The other person then gets to add something to the drawing to change it, for instance another animal trying to eat the first. The first person ‘defends’ by adding something more to the drawing, and on it goes. After discussing their thoughts and the drawing, the pair then presents it to the rest of the group.

Alt. 2: If you only have one drawing board, and preferably a large one, start by letting the first participant draw something (or do it yourself). The board is then passed to the next person who is not allowed to erase it, but must add to the picture. Everyone gets a turn to add to the complete picture!