Here are the links and the slides from the APIL2012 keynote:

• Forrester research on water-scrum-fall
• Article summarising the research
• Specification by example
• Effect mapping
• Feature injection
• User story mapping

Problems: Story is too big to split and estimate; business users don’t accept any breakdown proposed by the delivery team; team is inexperienced and thinks about technical splitting only;new project starts and no simple starting stories can be found
Solution: User Story Hamburger

I’ve evolved a new technique for splitting user stories over the last few months shamelessly stealing repurposing Jeff Patton’s User Story Mapping and ideas described by Craig Larman and Bas Vodde in Practices for Scaling Lean & Agile Development. I think it works particularly well in situations where a team cannot find a good way to break things down and is insisting on technical divisions. It has the visual playful aspect similar to innovation games and it’s easy to remember. I call it the User Story Hamburger.

Inexperienced teams often can’t get their heads around splitting stories into smaller stories that still deliver business value. But they will happily break a story down into technical workflow or component tasks. I like the idea of User Story Maps which show the big picture under a breakdown of a business workflow. We can do the same on a much lower level, for tasks making up a user story, keeping the team in their comfort zone. Then we use this breakdown to identify different levels of quality for each step, and create vertical slices to identify smaller deliverables. Here is how to create the hamburger:

Step 1: Identify tasks

As a group, identify technical steps that would be involved in implementing a story on a high level. Breaking it down into technical/component workflow is OK. The tasks become layers in a hamburger bun – meat, lettuce, tomato, cheese – throw in some bacon for fun as well.

For example, if we’re working on a story to contact dormant customers by e-mail, the steps might be: query db for dormant customers; send e-mail to customers; retrieve delivery report; remove bounced addresses from the system; mark non-bounced as ‘recently contacted’.

Step 2: Identify options for tasks

Split the team into several small groups and ask them to define quality for each task, or what would make a particular task good. Then they should write down several options on different levels of quality on post-it notes.

For example, speed of execution and accuracy of results might be a measure of quality for database query for dormant customers. Two possible options could be to make a slow and relatively inaccurate query on all customers compared with overnight transaction reports, which won’t pick up intraday changes. Another option to increase accuracy would be to have a nightly job making customers dormant and remove the dormant mark on every transaction, which would enable us to be 100% accurate and faster. The first option would work only if we send e-mails once a month, the second would work at any time.

Another example might be the volume we can send, the content personalisation and spam-regulation compliance for sending e-mail. We have an option of sending things manually, slow and low-volume. Second option is to use an automated process and send generic e-mails, with a manual unsubscribe process. A third option would be to use an automated process and send personalised e-mails, with manual unsubscribing. The fourth option would be to send personalised e-mail automatically and enable people to unsubscribe automatically. Yet another option would be integrating with a third party service that does all that.

Step 3: Combine results

Create a single hamburger on a big board. Ask representatives from each team to bring post-it notes and fill in the layers of your hamburger, briefly introducing what each note it. Identify duplicates and throw them away. Align task options from left to right based on the level of quality.

Step 4: Trim the hamburger

As a group, go through tasks and compare the lowest quality options with things next to them, based on how difficult it would roughly be to implement each option. Mark that information on the post-its. It might be worth breaking things down into relatively same-size technical tasks to do some simple comparisons. Think about throwing away lower quality items that would take more or less the same to implement as a higher quality option.

Also decide what is the maximum needed level of quality for each task. For example, intra-day bounced e-mail removal won’t really bring much more value than overnight bounced e-mail removal. Take items over the line out – that’s what will be left in the box after you eat the hamburger.

Step 5: Take the first bite

Now that you have a hamburger, decide how deep you’ll take the first bite. Discuss what is the minimum acceptable level of quality for each step. For example, manual sending might not be acceptable at all, because of the low volume. But sending e-mail once a month might be acceptable. If the lowest quality option is more-less the same size as the higher quality one, you might go deeper straight away. For example, sending generic e-mail with manual unsubscribing might be more or less the same effort as integrating with Mailchimp. On the other hand, a fast realtime update of customer activity might be much more difficult than a on-demand slow database query. For some steps, eg removing bounced addresses, doing nothing might be a valid level of quality initially.

Step 6: Take another bite… and continue

From there on, any further bite should provide more quality, regardless of what you add. Eg implementing initial bounced e-mail removal enhances the quality. So does more frequent e-mail sending. Use complexity comparisons between tasks to decide how deep you want to take further bites.

This method works very nicely because it is visual, and it gets people thinking about alternatives while still staying in their comfort zone. It also works nicely with ‘bite-size chunks’ analogies. And you can easily explain why releasing just a technical task doesn’t make sense because no sane person would eat only the lettuce. On a final note, make sure not to do this while people are hungry.

If this sounds interesting, you can practice many other collaborative techniques for delivering the right software iteratively at my upcoming two day workshop in London in mid-March.

“The best course I’ve attended in my career. I loved that the instructor challenged us to think for ourselves and did not give us the answers straight away.” Trond Svensen, SITS

My two-day hands-on Specification by Example workshop is finally coming back to London. Since 2007, more than 2000 people have benefited from this training. The workshop is aimed at testers, business analysts and developers and based on my books Specification by Example and Bridging the Communication Gap. Through facilitated exercises and discussion, you will learn:

• how to extend specifications with examples to create a single source of truth for testing and development
• how to avoid functional gaps and inconsistencies in specifications and tests
• how to run specification workshops to facilitate collaboration
• good practices for designing specifications with examples and acceptance tests for agile teams
• how to create a living documentation system to facilitate change and improve your process long-term
• how other teams, from small web startups to large distributed teams in investment banks, apply specification by example in their contexts

For more information and to sign up, see the event page on EventBrite.

InfoQ just published an article on Feature Injection by Chris Matts that I’ve also contributed to. This article is a high level introduction of Feature Injection and related techniques. We explain the key elements of the framework and support them with a realistic example.

For more info, see click here.

Here are my slides from the agile testing days 2011 keynote “5 key challenges for agile testers tomorrow”

And by popular demand, here is the agile testing donut separately:

Here are my slides from the Eurostar 2011 Keynote: Death to the testing phase

As usual, Dan North did a fantastic keynote today at Oredev. Amazon should really start paying his salary — I ended up buying several books while he was still talking. North’s central idea was that patterns for effective software delivery derive from embracing uncertainty and that the delivery landscape changes significantly once we understand that.

North started by repeating the key ideas from his Oredev 2007 keynote, “Fear leads to risk, risk leads to process, process leads to hate… and suffering and Gantt charts”. Many elements of delivery processes in organisations are there to address risks because people are afraid of uncertainty. “We are terrified of uncertainty – we would rather be wrong than uncertain,” said North. Many of this process elements are wasteful and counter-productive, because uncertainty is a fact of life and more structure in a process does not address that properly. As an example, North mentioned the pointlessness of rigour in requirements and long term planning, citing a recent research which states that requirements have a half-life of only a few months today (the time it takes for half of the written requirements to become obsolete).

Dealing with uncertainty is at the core of the ideas promoted by the agile manifesto, but according to North that was widely misunderstood and many teams focused on practices expecting them to eliminate uncertainty. The original XP book has a tag line Embrace Change, which suggests that people should prepare for change but teams tried to predict where the change will happen and plan for it. According to North, uncertainty isn’t just about expecting change, it’s assuming that some unexpected bad things will happen during the project and that we can’t even know about them when we start. We can’t plan for them — if we could they wouldn’t be unexpected. “Embrace change was wrongly named…,” said North, “your ability to survive is directly related to handling the unexpected. Embrace uncertainty; expect the unexpectable and anticipate ignorance.”

As a potential technique to deal with uncertainty, he suggested Deliberate Discovery: if we know that some unexpected bad things will happen, we can optimise the delivery process for discovery instead of optimise it for structure. “The premise is assuming this will happen, what would you do differently?” asked North, adding that “we can actively reduce ignorance – instead of saying ‘I want to do estimation’, get people in the room and do stuff that is likely to produce the learning.”

He called the strategy double-loop learning — not just aim to improve the process, but learn to improve how we improve the delivery process.

He also suggested rolling wave planning as a way to embrace uncertainty of scope: “Get started and get data.”

For embracing uncertainty of technology, he suggested not splitting the deliverables in spikes and features any more and imposing rigour in testing and delivery on features. He said: “For features we have certain rules. spikes are hacks to learn and promise to throw the code away. what if you didn’t choose? what if i’m always going to start code by sketching. When it stats taking shape, stabilise it, make it testable, introduce rigour.”

For embracing the uncertainty of effort, he suggested investigating Beyond Budgeting, summarising it as “Measure stuff, spend money as if it’s your own.”

For embracing uncertainty of structure, North suggested using Real Options. He said: “Structure is an illusion of control, you can’t predict the future, so you can relax a bit. Use options, which have value and expire, commit deliberately and never commit early unless you know why.”

Last week I got inspired by a keynote presenter at a conference. Not about the topic, sadly, but to write on how to present. The logic of her presentation was sound, with good ideas, but she completely lost the audience.

She opened with a set of slides with 10 bullet points each, some with further detail. Like an evil robot from the movie 9, she started to drain the life energy from the audience. The room became very hot. With my last few mana points I tried to escape. Damn, I was blocked on both sides by people turning into zombies. I faced a tough decision: be rude and try get out by interrupting a row of attendees, or be polite and stay there to slowly die. Or at least, check out what’s new on Twitter. Others had similar ideas, and Angry birds seemed to be the preferred antidote for people around me. When this happens during a normal talk it is sad and bad. When it is an opening keynote of a conference, it should be a criminal offence punishable by law.

Good presentations inspire and energise, not hibernate the audience. Who cares about the plebs, you might think, because if people aren’t paying attention that is their loss. When you decide to invest one hour of your life in speaking at a conference, with a few more hours to travel and prepare, you probably want to get a message across. The less people pay attention, the lower your return on investment.

Presenting doesn’t come naturally to software people, and I made lots of mistakes early on and learned from them. Here are five basic things to watch out for if you’re planning to present.

A word or two is due about context before I start. People present for lots of different reasons and at many different occasions. There are no best practices for presenting, similar to the way that there are no best practices for software in general. My keynote at StarEast this year, for example, was rated very highly by the audience. I asked Naomi Karten, famous author of Presentation Skills for Technical Professionals, for feedback on improving after the talk, and she said “It is amazing how someone can do everything wrong but still make a great presentation.” Use the ideas below as an inspiration, not as a prescription. I mostly speak at conferences in front of mid-size groups (100-400), mostly from the IT industry, often geeks. In different contexts, different rules might be applicable.

Watch the wordcount

Presentations where I lose interest are often the ones where the slides are trying to be a novel. Geeks are compulsive readers — put text on the projector screen and people start reading it, which means that they stopped paying attention to the presenter. Another issue with novel-like slides is that detail often doesn’t come across nicely. The average projection equipment at a tech conference is as far as you can get from IMAX 3D as possible. Even a cheap monitor has much better quality of picture and colours. This is important because the audience, especially those at the back, won’t be able to see fine detail. Font size 8-9 is perfectly readable on a monitor, but it will be impossible to interpret for people from the audience, unless they have superpowers. Shades of colours are often indistinguishable. The keynote presenter last week showed a photo of camels in a desert, that I have no doubt looks fantastic on her monitor, but was just blurry surrealist art from where I was looking. She then had to explain the photo, proving that a thousand words is better than a bad picture.

For best results, I keep the font massive. 30 pixels at least. 40-60 pixels is even better. This makes me keep the text short as well. I try to rephrase the text and remove as many words as I can — and focus it just on the key points. When I show code, I try to have only one or two relevant lines on a slide, with emphasis on relevant elements. Lots of people show a whole method or even worse try to push in a whole class. Nobody is going to try to compile a slide, show them the key stuff!

Slides are a visual aid for the presentation, and good slides support a story by illustrating it or reinforcing key points. If the slides are there just to reproduce what the speaker is talking about, the audience is not getting any benefit from them. Even worse, slides are competing with the speaker for attention, so complex slides with lots of text are a great way to score an own-goal.

Great slides help the audience see what the presenter is talking about. The comparison between pictures and kilowords is a big cliche but it really works, especially when I need something visual to complement the audio experience. I got great ideas on how to illustrate key ideas of my presentation from the The Back of the Napkin: Solving Problems and Selling Ideas with Pictures. You don’t have to be an artist to draw nice illustrations. As long as you have a simple idea (such as the key idea of the slide), you can express it with diagrams or charts. For example, see my presentation from StarEast, which was inspired by the Indexed blog and GraphJam.

60 minutes is shorter than you think

Many new presenters are scared that they won’t have enough content to fill the whole hour, and end up creating too much material. This often causes presenters to overrun, which means they start skipping some of the slides. When I’m sitting in the audience and the presenter is skipping slides, it makes me feel as if I’m being cheated, especially towards the end when I expect a conclusion. The presenter had more things to tell me but she’s now keeping something secret.

In general, it’s better for a presentation to be 10 minutes shorter than 10 minutes longer. You can always use the spare time for Q&A. I tend to leave slack just in case that someone interrupts the presentation in the middle with a few questions, so the whole thing might take longer than expected. At less formal conferences, talks before mine often overrun, so I then have to make mine shorter.

My rule of thumb is 15-20 slides per hour. Any more than that needs to be cut down. There are exceptions, of course. For example, I watched Simon Wardley do a presentation with 100 slides in one hour and it was fabulous. It was perfectly rehearsed and his slides were there for the comedic effect.

In any case, the best way to see how long a presentation takes is to try it out before the talk. Just rehearse it. I make my family crazy by presenting at home and talking to myself, but this makes me spot parts that are going slow, refocus, and ensure that I have enough material to fill the required time but not too much so that I have to rush it at the end.

I now try to keep the number of slides as small as possible, and have only key points in the slides. If there is not enough time, I can skip less important parts of each story. People won’t feel cheated because I skipped a whole slide. The same applies for too much text — when there are six or seven bullet points and the presenter only talks about two, the audience feels cheated. If there are only three points but I talk about more, they feel that they got more than they should.

For an example, see the slide below. It illustrates the key point of what I want to talk about visually and I can rant about that topic for two minutes or for 30, depending on available time and audience interest.

Keeping people awake is the presenter’s job

I read somewhere that TV has conditioned us to pay attention at most for 20-30 minutes, and expect a commercial break after that. With too much content fired at the audience, without considering their attention span, people won’t remember most of what was said. This again reduces my return on investment as a presenter. Keeping people awake is a part of the presentation as much as the “real” content.

The presenter last week tried to create short discussion breaks, but I often find those things a bad distraction. The classic “turn to the person next to you, introduce yourself and tell them all the sad elements of your life story” thing never works for me. Maybe I’m a bad person, but I just don’t care about what other people had for breakfast, especially if I’ve never met them before and I’m unlikely to see them ever again. Giving people five minutes to discuss something topical seems as a good idea until you actually participate in that, and see that most of the audience talks about something else. They lose the context, which requires the presenter to grab the attention back. Even when on topic, these discussions often don’t have a conclusion because they are too short and there is no time to consolidate all the information from the audience. Five minutes never turns out to be five minutes, because it’s not enough time for any decent conversation and some people just won’t shut up. Things like this work for interactive workshops where groups have 15-20 minutes to explore a topic and summarise it, not for presentations. Getting people to discuss something at a conference presentation is just a lame attempt to break up the boring stuff.

Interruptions in a presentation are a good idea to keep the attention, but for best results I try to create interruptions that are strongly facilitated and controlled, not a free-for-all please discuss something. One good technique is to ask random people from the audience questions. The rest of the audience then floods their organisms with adrenalin because they fear that they might be next in line — nobody wants the world to know that they were sleeping during the presentation. Stand-up comedians are masters of this. Watch any show by Dara O’Brien to see this effect.

Another good trick is to give away gifts for correct answers. I often try to insert 3-4 questions in a presentation that allow the audience to compete for gifts, such as books. This keeps them awake because they don’t know when I’ll be giving away something next. I intentionally organise questions as a bit of a shouting contest (“the first person who…”) because the person shouting also wakes up all the people around her.

The third trick I use to keep people awake is moving all the time. That gives the audience a moving target to track, so they have to pay attention. Don’t understand this as a justification to run around like crazy during a talk — I’ve seen one guy do that and it just seemed as if he was on drugs. The audience shouldn’t feel as if they are watching a tennis match. I walk around slowly and people have to follow me visually. This also helps me engage an audience in a wide room, as I can make eye contact with different groups of people.

The presenter at the conference last week was still. Handcuffed to her computer by a short cable leading to a mouse she used to flip the slides. Without a moving target, the audience satisfied their visual stimulation needs with shooting virtual birds at equally virtual pigs. I strongly suggest investing in a clicker if you’re going to present. The cost of it will be justified by keeping just one more person awake. Some people use a wireless mouse, but a mouse has a shorter range and it is easy to press the wrong button or flip over too many slides. Good clickers work from 10-20 meters away, so you can even move into the audience if you want. I use a Kensington 33374 Wireless Presenter which fits nicely in my hand and the buttons are clearly separated. Here’s another tip: if you don’t have a clicker, ask the people presenting before or after you to borrow it to you, you’ll see the difference.

There are many books about presenting which talk about jokes as a good way to keep people awake, because they interrupt the expected flow of text. Geeks are curious by nature, so the audience pays attention after a joke because they want to know what the presenter will say next. This again has to be considered in context. I’ve done a stand-up comedy show at agile testing days last year and the audience loved it, the organisers asked me to come back and do a keynote this year. I’ve also tried to tell well-written jokes at a relatively formal conference at a country where people aren’t really known traditionally for their sense of humour, and this was a big mistake. I’m not going to resort to stereotypes, but nobody laughed, probably because they did not want to stand out. It felt awkward both for me and for the audience. I now try to gauge how formal the talk has to be, and whether the audience will react to jokes. Generic jokes also don’t work well. For best results, I try to use jokes that support the point of the presentation. They have to be topical and relevant for the audience. I often rewrite one of the points I try to put across as a joke. I got some great ideas on writing jokes from Comedy Writing Secrets and The New Comedy Writing Step by Step.

Slides are for the audience, not for the presenter

Many people use slides as presenter notes. The presenter at the conference last week continuously turned to the slides on the screen behind her and read from them. This is a horrible way to present and an easy way to lose the audience. While reading, the presenter loses eye contact and often turns her back on the audience. For example, here is a picture of me from a few years ago getting it completely wrong.

Presenter not knowing what is on the slides shows utter disrespect for the audience. If people in the audience give me one valuable hour of their life, I can at least bother to learn my own presentation.

I often use slides to remind me what to talk about, but glance over them quickly and not by turning my back or reading from them. Here is a protip for that: put your computer somewhere where you can clearly see the screen from a distance — the lectern or the floor, and position the screen so that you can see it when looking at a part of the audience. Then you can glance over the current slide while it appears that you’re talking to the audience. Having slides in big font or just massive illustrations helps as well, because I can see better from a distance. If I forget what’s on the slide and can’t see it from a distance, I walk past my computer and glance at it while moving to a different part of the stage.

It’s normal for presenters to have a sip of water during the talk a few times, so I use that for my plan B to disguise catching up on notes. If I do need notes, for example if I didn’t have time to practice the talk properly or if I’m doing something completely new such as a standup comedy show at Agile Testing Days last year, I write the key points to remember in big block letters on a piece of paper and leave it close to the water jug. Then I can pretend to drink water while reminding myself of the key ideas to talk about. The audience doesn’t see anything unusual.

Preaching puts people off

I absolutely hate when people tell me that I have to do something or that I need to do something without knowing the first thing about the context in which I work. At conferences, we speak to hundreds of people and they all work in different contexts. There are often some common problems and ideas, but preaching without context is a horribly bad way to pass on useful knowledge. No, I don’t need or have to do anything in particular. I could do it if I wanted and it made sense in my context.

Instead of treating the audience like a child, I treat them as adults and explain why good ideas are good and in what context have they worked. Instead of telling people what they need to do, I try to illustrate everything with stories from my experience and let the audience connect it with their own experiences. It’s fine to summarise the story in a “if you have this problem, then don’t do …” but preaching without context is a sure way to lose many people.

Another reason why experience stories are better than preaching is that nobody can argue against that. It might be right or wrong, someone from the audience can know a better way, but I’m telling what I did and what I learned from that. Nobody can dispute that. I encouraged a lot of first time speakers to present at various user group meetings organised at Skills Matter over the last 4 years — and they often had the same fear from presenting: “What if someone thinks I’m wrong and they know better about the topic?”. If you’re preaching, this is problem because it will inevitably create a strong negative reaction. If you’re telling your own story, then you are the person in the room who knows the most about it.

Summary

So in short, here are five things to consider if you want to avoid the classic traps:

• Keep the font big and make slides illustrate your key points
• Keep the slide deck short
• Don’t let the audience fall asleep – move around, tell jokes, think of other ways to engage the audience but facilitate it
• Don’t read the slides, use them just as a quick schedule reminder if you have to
• Tell stories, consider context, don’t preach

This will get you over the first few initial hurdles in being a good presenter.

Photos: Zsuzsanna Kilian, Chris gilber, Paul Szustka, Alex Dunne.

“So much challenging and interesting information on eliminating waste in software development. Everyone should join.” Morgan Johnston, Agile Lead/Developer, Digiterre

I’m organising a half-day overview of Specification by Example, BDD and ATDD for senior technical people and management again on February 3rd 2011 in London. This seminar is designed to give senior people, who would not be able to attend a three or four day training course, all the information they need to know why these ideas are important, how to instigate and support a process change and what they can expect throughout the journey. For more information and to sign up, see the event page on EventBrite.

I speak at a lot of conferences and I often get promo codes from the organisers for people to buy cheaper tickets. I kind of ignored this so far, but several people asked about this at a recent workshop, so I decided to set up a mailing list for anyone interested in this. I will also send out discounts for books, workshops and similar things as I receive them.

If this sounds interesting, sign up.

Next week I’m in Oslo and Tallinn and I’ll be doing three user group talks – so this is a nice chance to meet up if you’re in the area.

• Breaking the TDD mould at XP Meetup, Oslo, Norway, October 24
• Busting BDD Myths at NNUG, Oslo, Norway, October 25th
• Challenging requirements at Agile Saturday, Tallinn, Estonia, October 29th

The first proof copy of the poster arrived today, which means it’s ready to go. I’ll start sending out copies in the next few days.

You can grab a copy from CafePress (the price there is just their printing price, I’m not taking any markup) or you get it for free till the end of this month.