Chris Hedgate

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.)

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.

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!

I have now finished my little tour of presenting “From Good To Great Developer” at various Swedish conferences. I want to say a big “Thank you!” to everyone who joined me at any of those occasions. As promised, you can download the presentation and code from my web site on the resource page for the talk, where there are also links to various resources mentioned in the talk. For anyone who missed it or want to spread the word to your colleagues, I would be more than happy to come to your company for a session.

Finally, I also want to thank my friend Erik Emmerfors at BitsInFrames for drawing the great comic strip describing the story of the incompetent bank robber. For more information on what this story has to do with my talk, see the summary flyer on the resources page.

I use Spaces and Quicksilver to increase my focus on the task that I am currently working on. By hiding focus-stealing applications from view in another desktop, and interacting with them through Quicksilver, I can stay focused on my task. Read on for more details.

For a couple of weeks now I have been deliberately trying to become more effective by improving focus during daily work. I have had a lot of inspiration from Staffan Nöteberg, whose book Pomodoro Technique Illustrated is a great read. I have tried using the Pomodoro Technique a bit, but for various reasons (one being synchronizing with my colleagues) I’m trying other similar techniques such as PCEO now. Regardless of which technique I have been using I have also tried using some technology to help me focus, and that is what I wanted to write a quick post about here. Specifically there are two applications, Spaces and Quicksilver, that I have been semi-using on my Mac for a long time, but not really been able to see or draw any real benefit from.

Focus on the task at hand

When I am working I want to be able to focus on the specific task that I am doing right now. For instance, if I am writing an article I want to have Textmate (or some other application for writing) running, perhaps a couple of browser windows/tabs with some information I need for the article, and perhaps a Finder window. Just things relevant to this task, and for those applications that can have multiple windows or tabs only the relevant windows.

What I do not want to see is iTunes, Mail, an IM application, lots of browser windows/tabs with “other stuff” not relevant for this task, a development environment, Finder windows for other things, my note-taking application or anything else that could steal my focus if I would look at them.

A simple solution is of course to simply quit all these other applications. But that means it will take a lot longer to switch context to other tasks, or catch up on mail and other communication during a quick break. And perhaps I do want iTunes running since music helps me focus, I just do not want to see it because I can easily get stuck navigating songs. Minimizing all these applications is not much better than closing them, since it still makes it difficult with context switching.

The solution for me has been Spaces, the built-in virtual desktop application in Mac OS X Leopard. Using Spaces, I have arranged my desktops according to tasks. The basic setup has three desktops that always exist:

• My first desktop starts out blank. This is where I work.
• The second desktop is my communication hub. Mail, IM, Twitter, RSS reader etc, all those kind of applications are normally always running here. I also have my calendar and todo’s open and showing here all the time.
• My third desktop is my reading place. Articles, blog posts etc that I defer reading until later are dumped here.

At any given time, I normally have a couple of other desktops created. For instance, since I am interested in photography I normally have a number of browser windows open specifically for reading about photography, and also for following different communities that I take part in. I want to be able to quickly overview what is going on in that area, so I more or less always have a separate desktop dedicated for that. Other ongoing work such as sales usually have a dedicated desktop as well.

More importantly, when I am working on some task (on desktop #1) and decide to postpone it for later, I usually create a new desktop and dump everything there. That way I am ready to start a new task with an empty desktop, and I can easily get everything back when I decide to switch back to the previous task.

Finally, I really like having a communication and planning desktop. This is where I go when I come back from a quick break, to get an overview of any changes that might affect my planning.

Recovering gracefully from interruptions

When I am focused on something, possibly in a nice state of flow, I do not want to lose that focus to an interruption I did not plan for (breaks should be planned often to reflect and re-plan as necessary). However, interruptions cannot simply be ignored. The Pomodoro technique describes some good principles for handling internal and external interruptions. Usually it comes down to making a note of whatever was so important to interrupt you, and scheduling time for taking care of it later.

However, there might be some interruptions that I want to act on immediately. For instance, something as simple as iTunes switching to a song that I do not want to listen to right now. I could switch to iTunes, but that would carry the risk of ‘getting stuck’ navigating songs and thereby losing focus. Another example is sending a quick email (such as just a file that someone needs), or adding something to a todo list. The common theme for all of these are that I need to interact with some other program, but to avoid losing focus I do not want to interact with it directly.

Email a file

This is where Quicksilver really shines. With just a couple of keystrokes I can email that file to my colleague, without even seeing the mail application. It is still ‘hidden’ in another desktop, and there is no risk of me seeing that super interesting but non-urgent email lying in my inbox. Quicksilver has tons of plugins that allow me to do these quick indirect interactions with applications, which means I can recover from an interruption without losing my focus.

Pen and paper rules!

With that said however, as a final note I want to warn you not to rely to heavily on technology. Pen and paper are the base components of whatever focus-helping technique I use. Daily planning of what activities I need to do today, simple follow-up on where my time was spent, and taking notes of things to reflect upon later is best done using just pen and paper.

Last year, after a user group meeting, me and Kim Gräsman were talking over a beer about how hard it was to get everyone else to care about code the way we do. For instance, there we where at a user group meeting, while ‘they’ were not. This got me thinking about what we usually do when we try to ‘help’ others see things our way. We try to teach them things such as refactoring, design patterns and TDD, with no other result than us becoming frustrated when people do not understand or want to use them.

Further thinking led to a presentation, titled Great Developers, that I gave at the SweNUG Code Camp last summer. There I talked about what I believe a great developer to be, and how they work with code to produce a great result. I had the opportunity to do this again a couple of times during the autumn, and I also submitted the presentation for a couple of conferences during this spring.

I did however change the title, and also the abstract, since my main point in the presentation moved from ‘what is a great developer’ to ‘why are we having trouble helping good developers become great developers‘. This week I gave this presentation to 300-350 people at the JFokus 2009 conference in Stockholm, Sweden. I think it went really well, and I hope people liked it. At least one person commented afterwards:

Your presentation has been one of the most concrete, clear and to the point presentation I have heard since a long time ago, and I can mention that my motivation regarding what you have said has changed.

With the Java-people covered, I move my focus to the Microsoft TechDays conference in Västerås, Sweden on the 17th to 18th of March 2009. And if you happened to miss me on any of these occasions, there is a final chance at the Scandinavian Developers Conference in Göteborg, Sweden, on March 24th.

I hope to see you at some of these events! Take a look at the lineup of speakers for them, they promise to be great sources of inspiration and learning.