Instantly Better Presentations

IMG_0796At a recent YOW! Night, Damian Conway gave an excellent presentation on “Instantly Better Presentations”. His notes are online and the video of the presentation is below.

My notes from the session:

  • if you need to give the audience bad news, give it first
  • instantly does not mean effortlessly

1. Talk about your passion

  • to feel more confident, you need competence – talk about subjects you genuinely understand
  • seeing someone who is excited… is exciting
  • energy, enthusiasm and passion through your actions and speech will translate to your audience
  • find something in the required topic that gives you passion – even if you loathe the topic or have been forced by your boss to present it

2. Tell them a story

  • our memory is very volatile – stays for 8-10 seconds unless we do something with it
  • 7+/- 2 is horribly optimistic and not backed by research, real number is 4 +/- 1
  • stories are our oldest information processing tool
  • stories have a flow to assist acquisition and memorisation (all our memories are reconstructed from a storyline), have a hierarchy to assist comprehension and recollection
  • tell the historical story or the story of what happened, process or funny anecdotes
  • story is for your benefit to get the sequence and content right – audience don’t necessarily need to know
  • stories make complexity comprehensible, structure recognisable, information easy to remember, make audiences feel more comfortable

3. Don’t search for content, select it

  • what should I say is the wrong question, question you should start with is what could I say
  • humans are good at recognising important stuff rather than recalling important stuff
  • start with a blank sheet and write down everything you know about the topic that you might want to say – stream of consciousness
  • whittle down to 3-5 most relevant and important topics to talk about
  • these 5 points becomes the chapters, so go looking for the narrative that connects them – they may not connect so look for a couple of lesser topics that better connect the 5 important things
  • competency – think about the questions you were asking when you were learning

4. Simplify your slides

  • tools encourage a bad job
  • content matters but not as much as style
  • content is your payload to explode the audiences brains
  • style – the stuff the audience doesn’t see that prevents them seeing what they should see
  • bad style – anything that prevents the audience seeing what they should see
  • a wall of text – technical audience will read everything, regardless of whether it is relevant or not
  • Apple is good at presentations – simple but effective
  • big words – people at the back can still read them
  • slide numbers turn your presentation into a death march – get rid of background, name and title on every slide, get rid of the logos (audience sees salesperson)
  • slide deck is to focus audience on the presentation – if they need context give them a separate PDF or notes
  • each message is a different slide
  • cluttered is overwhelming and as a result they switch off the attention channel as they are trying to read everything
  • show less on more slides

5. Manage the questions

  • a presentation should always be for the benefit of the audience – give them what they need
  • have an explicit questions policy – hold to the end of each topic, end of the talk, or interactive through the talk (can however affect the flow)
  • always be keen to take questions – shows you care
  • make the questions fit in with your question – “that’s a really good question” makes others more comfortable to ask question

6. Animate code simulations

  • explain code temporally, not spatially
  • use animations to reveal information one thing at a time
  • walk through code as an animation and highlighting
  • low tech animations – use the same slide over and over – cell animation
  • don’t export your slides – notes
  • live coding – synthesise, automate or have a partner – need to keep contact with the audience

7. Deliver your message fearlessly

  • use your nervousness – turn fear into energy
  • never give a presentation for the first time – practice it live at least 3 times
  • use an audience image on a big screen

Episode 84: Retrospectives in Middle Earth with Rachael Tempest Wood

The Agile Revolution's avatarThe Agile Revolution Podcast

P1020445Rachael Tempest Wood from Nomad8 in Wellington joins Tony and Craig in the Brisbane Queen Street Mall over lunch with a bonus busker on saxophone and they discuss:

TheAgileRevolution-84 (25 minutes)

View original post

Episode 83: Making Impacts with Gojko Adzic

The Agile Revolution's avatarThe Agile Revolution Podcast

GojkoAdzicGojko Adzic “does computers” which means he helps people deliver software and he caught up with Craig on a recent YOW! DepthFirst tour of Australia. Gojko is the author of numerous books including “Bridging The Communication Gap“, “Specification by Example“, “Impact Mapping” and “50 Quick Ideas to Improve Your User Stories“.

  • XP – started with “Extreme Programming Explained” which was really about developers ruling the world – XP is not dead, it won!
  • TDD has crossed the chasm to mainstream
  • Sturgeons Law – 90% of anything is going to be crap
  • Continuous integration and automation has opened up a world of possibilities
  • “Bridging the Communication Gap” – about finding ways to break dysfunctional processes in organisations
  • Agile Testing” by Lisa Crispin and Janet Gregory
  • The most valuable companies in the world are software companies
  • It’s more about the right people…

View original post 170 more words

Episode 82: The Heckle Revolution

The Agile Revolution's avatarThe Agile Revolution Podcast

name_col_sq_200Craig joins Darren Rogan, Ben Morgan and Leigh Appel in a special cross over episode with the Hack && Heckle Podcast to talk Agile and preview the upcoming YOW! conference that will be covered by both podcasts.

This episode has been released simulatenously as 088 The Heckle Revolution by Hack && Heckle.

Discussion points included:

TheAgileRevolution-82 (39 minutes)

View original post

Episode 81: Resetting Agile & Devops with Justin Hennessy

The Agile Revolution's avatarThe Agile Revolution Podcast

JustinHennessySitting in a sometimes noisy coffee shop on a unusually cold Brisbane day, Craig sits down for a chat with Justin Hennessy, a Scrum Master, Devops and System Administrator all rolled into one!

View original post 24 more words

Episode 80: Context Matters in SAFe with Em Campbell-Pretty

The Agile Revolution's avatarThe Agile Revolution Podcast

Em Campbell-PrettyAt Agile Australia 2014 in Melbourne; Craig, Renee and Tony catch up with Em Campbell-Pretty to talk about the Scaled Agile Framework (SAFe) as well as Impact Mapping and a variety of other topics:

View original post 164 more words

Scrum Australia 2014: 40 Agile Methods in 40 Minutes

My presentation from Scrum Australia 2014 called “40 Agile Methods in 40 Minutes” is available on Slideshare.

With 73% of the world using Scrum as their predominant Agile method, this session will open up your eyes to the many other Agile and edgy Agile methods and movements in the world today. For many, Agile is a toolbox of potential methods, practices and techniques, and like any good toolbox it is often more about using the right tool for the problem that will result in meaningful results.

Take a rapid journey into the world of methods like Mikado, Nonban, Vanguard and movements like Holacracy, Drive and Stoos where we will uncover 40 methods and movements in 40 minutes to help strengthen your toolbox.

Huge recognition to Renee Troughton who created the basis for this talk as part of her Enterprise Transformation Meta Model work.

Honoured to have Henrik Kniberg, Nick Muldoon and Adam Weisbart in the audience for this talk and lots of good feedback on Twitter.

Lean Metrics & Time Tracking

Lean MetricsAt this month’s Agile Brisbane meetup, Ben Starr presented on Lean Metrics. His talk was based on metrics that they tracked at his previous company on an operational support team. A couple of points from the talk:

  • used Kanban – work item types to allocate capacity and 3 levels of service (standard, coordinated, expedite)
  • JIRA was the tool but was not the most ideal choice and not really up to the task
  • reported by type on backlog, work in progress, throughput (number of work items not size), velocity (throughput and velocity were similar which showed average size), cycle time, class of service mix, due date performance, estimation accuracy, cancelled WIP (started and then cancelled work) and demand balancing (clearing out the backlog)
  • flow efficiency – percentage of time you work on an item versus in progress, also referred to as touch time – using time tracking in JIRA to do this
  • time allocation – value add, failure load (defects), transaction cost (overheads of planning and releasing), coordination cost (management), used percentage of time spent rather than actual hours

The one things that got me thinking during this presentation was the flow efficiency report.

Early on my journey of being an Iteration Manager, my teams used to track times per card. We used to use XPlanner which had some reasoanbly easy functionality for tracking time (one of the good features was as the Iteration Manager I could enter time for my team if needed, tools like JIRA require the developer to record that data if you want it assigned to that developer). We used to use thee metrics for comparing estimates to actuals but over time I came to the conclusion that we would be much better off just making sure that the cards were completing on time (an average of 3 times) and splitting cards out if they appeared to big.

Lately, a number of people in my Agile classes have been arguing that time track is beneficial. My usual response to this (like for all metrics) that it is OK if it adds value, but my recommendation is not to waste your time. Even more so, this opens up the estimation debate that I also believe that a lot of time should not be wasted on (#noestimates), but that is a discussion for another post. My main reasoning is often we need to track for other sources (like timesheets) in different systems, and the overhead does not justify the effort. If teams need time metrics (often to see if time is being wasted away from the core work of the team, say on production support or corporate meetings), I suggest they are done at a team level and rounded to the nearest hour, and collected as time not spent not on project work.

In the graph above, flow efficiency is a good way for showing waste in the system (in this example, the team could potentially be way more effcient), but it relied on the team tracking time (in this case using the time tracking feature in JIRA against each card). I really like it as a graph, I am just not sure the effort to produce it is justified.

Some discussion in the Q&A revolved around recording time tracking (or similar metrics) is OK if the team understands it is an incentive for better metrics, and I can’t disagree with that thought. Just in my experience as an Iteration Manager, getting reliable and timely time and effort metrics ha been painful and the reward outweighed the effort.

Episode 79: Vomit Value with Jim Benson

The Agile Revolution's avatarThe Agile Revolution Podcast

14491375311_22bf182a39_zAt Agile Australia 2014 in Melbourne, Jim Benson of Personal Kanban fame takes some time to talk with Craig, Renee, Tony and (a very silent) Kim Ballestrin and along the way they talk about:

  • early work implementing David J. Anderson’s Agile Management which resulted in Jim focussing on the person (Personal Kanban) and David focussing on the organisation (Kanban method) – two different viewpoints on the same solution set
  • XP, Scrum, Kanban method and Personal Kanban exemplify the people who created them
  • The Oath of Non Allegiance
  • Scrum vs Kanban
  • Why Limit WIP and Why Plans Fail books out now and working on an upcoming book about meetings
  • Individuals and interactions is redundant – relevant in 2001 to shake people out of complacency
  • Agile is anti-manager
  • Agile in knowledge work
  • WIP limits and avoiding “death flow”
  • Vomit Value – user stories with spurious and arbitrary value in a…

View original post 63 more words