selective focus photography of brass-colored microphone

The secret to a great talk

/by

I have been part of the Agile Africa organising committee for a couple of years now responsible for speaker coaching. I have loved every minute of it because I have had the opportunity to see speakers grow in confidence during the process.

Most of the speakers were new to conference speaking and a few were experienced. During these times I was reminded that we never stop learning, no matter how experienced we are.

After Joanne Perold’s awesome post on how to get your conference submissions accepted, this topic discusses what to do once your submission has been accepted.

This is a broad topic so I am going to split it into 3 sections:

  1. Crafting your talk,
  2. Presenting your talk, and
  3. Timing your talk.

Crafting your talk

The message map

Carmine Gallo suggests in his book Talk Like TED: The 9 Public Speaking Secrets of the World’s Top Minds a simple yet powerful way to structure your talk by using a message map.

All you need do is remember 3 things:

  1. create a Twitter-friendly headline – memorable and easy to tweet,
  2. keep it simple by breaking your talk into 3 key messages  – more than this and people are bound to get confused,
  3. each key message has supporting points – remember not to have too many of these either.

The picture below shows how easy it is.

The rule of three

This is a powerful speechwriting technique that allows you to “express concepts more completely, emphasize your points and increase the memorability of your message.” (Andrew Lugan).

As a conference speaker, you need to make your message memorable, create passion, and stimulate discussion (see it in action here :-))?. Examples of the Rule of Three can be found in famous speeches throughout history, such as Barack Obama’s inauguration speech,

“we must pick ourselves up, dust ourselves off, and begin again the work of remaking America.”

So try this… group concepts or points that you want to carry across and be remembered long after you have left the stage, in threes.

In his book, Writing Tools: 50 Essential Strategies for Every Writer, Roy Peter Clarke says that “the mojo of three offers a greater sense of completeness than four or more. Use one for power. Use two for comparison. Use three for completeness, wholeness, roundness. Use four or more to list, inventory, compile, and expand.”

Presenting your talk

Be yourself, be real

The most important advice I ever received as a public speaker was to be myself. It can be tempting to want to imitate a speaker we admire. Unless you are an Oscar-winning actress aim to be real. When you do this your audience will connect with you. People will come to your talk because they’re interested in who you are and what you have to say. How you connect with them will determine if they stay…

Tell stories and use humour

People like stories, our brains are wired for them and become more active when we listen to them. Be they metaphoric or personal, using these to emphasise or illustrate points or concepts ensures that they are memorable. Good stories are powerful, simple and persuasive.

Stories paint a mental picture that invokes all of your audience’s senses – seeing it in their minds and feeling emotion – such that they connect with your content.

I have also found that to start with a story calms my nerves and hooks the audience in right from the start because it creates interest from the get-go.

Keep facts and stats to a minimum

These tend to overwhelm the brain and it’s a quick way to lose your audience. I’m not saying have no facts or stats – think about what you want your audience to take away and focus on delivering this in a memorable way – anchoring them with a story is a good idea. Infographics are also effective at presenting facts and stats – it’s a picture and easy for people to remember.

Timing your talk

You have a timebox in which to deliver your talk. Write a talk that allows time for questions. For example, if you are doing a 45-minute talk allow 10 minutes for questions – this means that you need to write a 35-minute talk. For a 60 minute talk allow 15 minutes for questions.

This also creates a buffer because there are other things that can go wrong on the day. I recently witnessed the following which caused the speakers to rush the ending and didn’t allow time for questions:

  • the clicker didn’t work,
  • the laptop and the projector were not compatible,
  • the audience began asking questions during the talk (this is perfect – just plan for it in your timing, or tell your audience that you will take questions at the end).

Work with a timekeeper – get the MC, facilitator or a friend to give you hand-signals or hold up coloured cards when you reach certain time thresholds.

And a couple of final tips

End on a high note and what’s the takeaway?

A lot of good presentations fizzle out at the end. This could contribute towards a recency bias where your audience will only remember the last part of the presentation which clouds their perception of the rest. You’ve probably heard of this cognitive bias – read more about this systematic error in thinking here.

There are many ways of ending on a high note. A good way of thinking about this is asking yourself ‘what is the one thing that I want my audience to take away or do differently?’ and find a way to communicate this – perhaps another story, a quote, a tweetable moment… it’s all in your imagination.

All of the best with structuring your talk. Work with a coach. And remember: the ultimate secret to a great talk is to make time to prepare and practice, practice, practice!

Do you have any other secrets that you are willing to divulge? Let me know in the comments below.

LeSS and DevOps

/by

Three-fourths of the companies surveyed in the 2017 State of Agile Report are either engaged in, or planning, a DevOps initiative. And why not? Who wouldn’t want their teams’ work released as quickly and easily as possible.

As we look to expand our Agile development across multiple teams, it makes sense that we’d want to keep our DevOps intact during that effort. Now, most frameworks or even home-grown designs for team collaboration account for DevOps. Large Scale Scrum (LeSS), however, is different. It not only accounts for DevOps, but also builds it into the approach. And the more teams embrace DevOps, the better it is.

BalticServers data center

What sets LeSS apart in this? Where other approaches focus on aligning and directing team efforts, LeSS focuses instead on team collaboration. Teams in LeSS don’t just work in the same direction, they collaborate on the same product effort. We know from working with team members that fast feedback loops, frequent check-ins, and automated tests help developers collaborate and LeSS leverages those same benefits across teams. Let’s look at a few examples:
 
Continuous Integration & Deployment (CI/CD): We have learned that finding integration conflicts quickly leads to smaller problems and faster solutions. Most developers have moved from checking in code every week or so to committing multiple times per day. In LeSS, all teams must be fully integrated into a single code-base by the end of the sprint, which is distinctly different than all teams integrating at the end of a sprint. Much like within a team, the more frequently these teams integrate and build their application, the smaller their inter-team integration conflicts and faster their resolution to create overall robust scaled delivery environment.
 
Automated Testing: This serves two major purposes when collaborating between teams. First, describing the desired functionality in a test using unit tests, integration tests, or functional tests, removes ambiguity about how the application should function. This allows teams to work on the same effort more effectively without taking the application in different directions. Secondly, running automated tests at every build alerts a developer (or team) if the code changes they made accidentally interfere with someone else’s work. Done right, these alerts can happen even before integration on a CI server occurs.
 
Cross-Functional Teams: DevOps extends the idea of cross-functional teams to include the skillsets needed to deliver software to the end user. LeSS relies on this to release software. In the LeSS approach, there is no separate process for code to enter that carries it to release. Each team must be capable of releasing their features into production at any point. There is no release team or stabilizing period to hand off code to.
 
While other approaches are compatible with DevOps, LeSS is principally and structurally sets up an organization to be successful with DevOps. DevOps principles and practices find full expression in a LeSS environment and in turn enable smoother and faster development in teams working with LeSS.

Photo BalticServers data center by Wikimedia Commons

Agile Leadership for future-proof companies

/by

Fast-moving markets, economic uncertainties and progressive digitization pose major challenges for companies. Instead of responding quickly, many companies are still stuck in old structures. However, economic survival requires a high degree of adaptability. Businesses therefore have to become more agile. For this to work, in addition to intervening in the organization, a new understanding of the roles of all involved is necessary. The executives are particularly challenged here, as agile methods are largely responsible for the teams’ decision-making power. So what role do managers play in moving towards more resilience and anti-fragility in their organizations?

We have discussed these topics in a new article published by German magazine Informatik Aktuell.

The original article titled Agile Leadership macht Unternehmen fit für die Zukunft can be read online.

Survival Tricks for Remote Developers

/by

At the Italian Python conference, Alessio Bragadini illustrated some of the key aspects of how he works remotely and how a distributed team can be efficient in his talk Out of Sight, Out of Mind: Survival tricks and tools for remote developers. Thanks to his experience, in a matter of minutes Alessio clearly explains what implies to work away from the office and how to do it successfully by using specific methods and practices. The talk ends with a useful list of tips and tools to “survive” in a distributed team.

The video recording of the talk can be watched here or on YouTube. Slides available from SlideShare.

 

The nature of innovation

/by

“Innovation is not so much about having ideas as it is about making connections” – Harold Jarche

“Yesterday during a break, I went for a walk in the bush around the venue. I came across a deer in the path, and I immediately thought that I had to bring my son with me next time, as he’d love to see it. But then I realised that if I came back here expecting to see the deer again we’d probably both be disappointed.”

This story, shared by a participant of the 5-day agile42 Innovation Sprint I facilitated recently, captures the emergent and often ethereal nature of innovation. Innovation happens mostly by accident – it’s about serendipitous encounters and connections. We can create conditions where the chance is greater for it to emerge, but we can’t mandate, manage or create innovation.

How then do we go about creating containers where innovation is more likely to emerge? One learning from this workshop is the importance of how an event is framed (i.e. what we call it) as the framing creates a container within which the process unfolds, and it also creates expectations that can either be enabling or disabling.

InnovationFirstly, the expectation of this being an event that needed to lead to “innovation” introduced pressure and expectations that paradoxically may stifle more than enable innovation. Some of the participants voiced concerns about “not being particularly innovative” and many seemed to adopt a wait and see attitude about whether anything new will actually emerge. Many expressed the fear that we’ll only end up with “tweaks and fiddles” as opposed to “real, out of this world innovation” or that “ONE big idea”.

To counter this, one of the first exercises was a narrative meaning making process around innovation where the aim was to at least externalise and acknowledge problematic stories and meanings the group held around innovation so that we could work with them more intentionally. We did this by exploring the following questions:

  • What do “they” say about innovation? (They being the nebulous “other” that we often talk about, but never really know who “they” are)
  • We then broadened it to look at the context in which these things are said
  • Then we unpacked the impact of these meanings on the group

The group highlighted two emergent patterns from this exercise: one of pressure (innovate or die) and another of prejudice (only some people can innovate). Innovation was seen as “hard”, about that “ONE big idea” that had to be lucrative. It is risky – expensive if you fail. Innovation is fast and quick; it’s an imperative “innovate or die”. On the other hand it’s also a “buzz word”.

When asked to name this innovation narrative names like “we’re all confused” seemed to resonate.

This process a much more open container for the work and upon reflection later on in the week, many participants referred to this process as a key break-through moment.

Outside of the boxWe also challenged the cliché of innovation requiring us to “think outside the box”. Often we don’t know what the box is (or if even exists), so how can we think outside it? We chose instead to reframe our process as “unfolding the box”, which served to shift the perspective of the group from a focus on outcome to a focus on process and a stance of curiosity and enquiry.

agile42 has a strategic partnership with Prof. Dave Snowden, and we wanted to use this workshop to also gain deeper practical insight into the Cynefin framework and other related methods. We therefore “unfolded the agile42” box using multiple complexity based group activities such as…

  • Future backwards to understand the current reality (today), future dreams (patterns in heaven) and fears (patterns in hell) of the group as well as gain insight into the shared corporate memory (patterns in the timeline). Here the group discovered that even though they are distributed across many different countries and continents, there were golden threads that tied them together.
  • Cynefin contextualisation to surface sense-making patterns and biases.
  • Archetype extraction – prior to the workshop, we collected stories about current agile practices (best and worst) using Sensemaker. We used these to extract emergent archetypes, visualised by a cartoonist in the workshop.
  • We used appreciative interviews to surface and share success stories about client engagements as well as sales and marketing experiences. We then asked the ASHEN (Artifacts, Skills, Heuristics, Experience and Natural Talent) perspective questions and to surface key knowledge objects that exist in agile42.
  • We applied ABIDE (Attractor, Boundaries, Identity, Diversity & Environment) as perspective lenses to understand the market and “influencable” patterns.

These divergent (and often messy!) methods served to make patterns visible and keep the group from falling into their comfort zone of identifying problems and then trying to find solutions.

This was not an easy of comfortable process for the group. Many of the activities seemed disparate, each providing a different perspective or unfolding a different aspect of the box. There was no defined outcome, and no linear process where each activity built on another. Being complex methods, they were largely emergent and involved ambiguous instructions. Golden threads only became apparent on day 3, and some activities were “left hanging” and never really resolved.

As the majority of the people in the room are coaches, who are used to “being the experts” and the “ones who know”. The inherent uncertainty and ambiguity that such a divergent process brings challenged this identity and brought greater empathy for how their clients feel when they experience similar processes.

When we did finally converge on day 4, the majority of the group felt that the discomfort was worth the end result. Many felt that the value was as much as the experience of the uncertainty of the process, and the associated learnings than the eventual outcome (a portfolio of experiments and ideas that will be actioned in the next few months).

An interesting metaphor that emerged during the process is that innovation can be likened to a chef that combines existing ingredients into brand new recipes. Chefs don’t create new ingredients, they combine what is already there in unique ways. The challenge for this group was to see themselves (e.g. skills & offerings) and their markets (attractors, boundaries etc) from multiple perspectives to potentially recombine existing capability to new market opportunities.

Read more about Sonja Blignaut and More Beyond at www.morebeyond.co.za. Artwork by James Durno.

selective focus photography of green iguana

The Lizard Brain

/by

This topic is an excerpt from “The Hitchhiker’s Guide to Agile Coaching”, where agile42 coaches share their insights. Electronic copies of the whole book can be downloaded for free, check link at the bottom.

Cover of "The Hitchhiker's Guide to Agile Coaching"All humans have a hard-wired notion that change is dangerous. Over-reacting pays off in the jungle or on the veldt — those who scram away without thinking have a good chance of seeing their offspring grow up. And so we have evolved a mechanism for getting ourselves out of dangerous situations quickly and with a minimum of thinking. In fact, thinking is high on the list of things not to do. Those who start analyzing whether the waving grass really does conceal a man-eating saber-tooth tiger are more likely to end up analyzing the tiger from the inside.

Change and fear are connected on quite a deep level in our brains. As shown in the figure, when subjected to a threat of some kind — a threat to their habits, territory, or very existence — people go into panic mode and will either fight, flee or freeze.

Like all models, this model is incomplete: it’s a simplification of reality and full of holes and errors. However, we have found it very useful. It explains some of the reasons why people fear change and also helps make sense of why people react as they do in the face of change.

The lizard brain — primal reactions

The name lizard brain comes from fact that panic reactions are handled (mostly) by a part of the brain called the amygdala, which can be found just above the brainstem in all vertebrates. We share the amygdala with all mammals, birds and — as the name implies — with lizards.

When a vertebrate animal is subjected to a strong threat, the amygdala causes an immediate primal reaction. This is not a simple reflexive action: reflexes typically only yank a couple of muscles. But the primal reaction is still well below rational thought. The amygdala in fact prevents rational thought by subverting and disconnecting the upper brain functions. People suffering from primal fear are not only unreceptive to rational arguments but actually incapable of rational thought.

Interestingly enough for an agile coach, similar patterns can be found in prolonged situations of uncertainty, fear or anxiety, as is the case in e.g. agile deployments. Case in point: “We will pilot Scrum in the organization and your team is the best candidate!” In other words: “We say you Scrum.” Ouch! How do people interpret this?

Habits Most people are initially vary agile methods as they need to change their own working habits. Harsh corporate environments cause people to form their own patterns and strategies for survival and they may be very suspicious of “team work” and “collaboration”.

For example, we regularly meet engineers who have learned not to ever give honest estimates. They have formed habits of hiding the actual state of their work, giving vague reports like “90% done but we have some technical problems” or having a perpetual “coding” task that they move back and forth on the task board (When we see a task named “coding”, this gives us the signal that the team is tracking how they spend time rather than the outcome they produce.) Others feel that the daily standups are stupid — it takes weeks to implement this feature anyway so what need is there to report every day?

Territory Scrum can also be a threat to people’s territory. Former project managers that are now relabeled ScrumMasters or Product Owners suddenly find that they have lost a large portion of their former decision power. Deep specialists are forced to open up their work to the scrutiny of others. Software architects find that teams are doing unauthorized changes directly into the code base.

Existence Some people see agile methods as a threat to their existence in the organization. These include line managers whose teams are suddenly self-organizing; testers who learn that all testing will soon be automated; or specialists who learn that they are in fact not so special.

To the vast majority that is not directly involved in driving the agile transition, Scrum is a cause of anxiety or outright fear. How do they respond?

Fight Direct and indirect attacks. Badmouthing. Spreading fear, uncertainty and doubt. Passive-aggressive behavior in the Scrum meetings. “Here, let me help you with that… oops, so sorry.” Appearing to play along for a while, then a sudden explosion of this-will-never-work. And so on — the examples are countless.

Flee Some people grab the opportunity and move to other teams or escape the company altogether. The decision to flee is often made early, sometimes as soon as the news has broken, but it can take months for the fallout to appear. By the time people start understanding and accepting the new methods, they have already made new commitments and signed new contracts, and the decision is no longer reversible.

Freeze A surprisingly large number of people seem to lose their drive and become unable to produce anything of value for months on end. They are tapping on the keyboard and moving the mouse but nothing real comes out.

In almost every team we work with, we find examples of fighting and freezing, sometimes, but luckily very seldom, also of fleeing. This model has helped us make sense of why people behave irrationally during an agile deployment. As an agile coach, it is your job to navigate people past this stage of anxiety. The main problem is how to do that when people are not thinking rationally.

You will need to start by identifying and addressing their concerns, showing that the change is happening on their own terms. We have noticed that it is good to have a brief meet and greet with the team before the coaching starts. This could happen in conjunction with some team training or as a stand-alone meeting between 20 and 45 minutes in length. During the meet and greet we go through the upcoming coaching schedule, point out that we are here to support and guide the team, and underline that things will happen on their own terms.

With especially afflicted persons, we have also had good luck with informal one-on-one coffee discussions, alleviating their fears and giving ideas for how to move forward. Sometimes the best approach is to just listen and make it clear that you have heard their concerns. In the end, agile adoption is about teamification and while you may be able to help people find their new positions in the team, there are always going to be people who need to make some hard decisions for themselves.

Download The Hitchhiker’s Guide to Agile Coaching for free from here

Sponsoring Agile2017

/by

Sponsor of Agile2017Agile2017, the annual North American conference of the Agile Alliance, comes to sunny Orlando, August 7-11. The event is dedicated to furthering Agile principles and providing a venue for people and ideas to flourish.

agile42 is happy to be a Silver Sponsor, meet our coaches in Florida where we can talk about Agile change and pick up an early copy of the The Hitchhiker’s Guide to Agile Coaching!

 

 

Culture is the catalyst

/by

As an agile coach, I always look at everything in my life with my agile glasses. I always follow the agile philosophy. This happens while working professionally in my business life, and it also happens while pursuing family and other affairs in my private life.

I have a six year old daughter. My inspection about her learning journey on new skills and knowledge is that she gets the best results while playing games with her friends or me. Children like playing games all the time and every time they gain new knowledge and enhance their skills in the particular topic. At agile42 we believe that adults and professionals also best learn new concepts and understand them by practicing and by doing simulations in trainings and coaching sessions. Therefore we develop and use a lot of games and simulations while working with professionals.

I like to see how adults and kids act on the same context and environment while playing agile games, so I make some experiments to see how kids play agile games and how they act during the game and if there are any different learning topics out of the games.

I recently facilitated the Marshmallow Challenge in my daughter’s class who are at the age of five and six. I picked this particular game because I also facilitate this in my professional classes. Some colleagues from Canada has also facilitated this game previously with kids and you can find some good blog posts about the concept of this game on our website. The inventor of this game, Tom Wujec, has also a number of related stories on his blog.

My Marshmallow Challenge

Since it is so well described, I am not going to explain the game in this post. However, I want to share the outcomes and my observations about cultural effects and teamwork concept mostly.

My brief notes from the experience of the game are as follows:

  • Children were very excited and interested to play the game.
  • Children have no trouble understanding the game. We helped them to divide into two groups to play the game.
  • The first point to mention is that as soon as I said “go and build” they wanted to start building immediately.
  • Although they understood the rules of the games the most difficult thing for them was to work as a “team”.
  • They really struggled to work as a team, they were acting personally trying the get the materials to build the tower. More active kids obtained the most of the material leaving rest without materials.
  • So I and their class teacher stopped and reminded them to work as a team again.
  • Soon one of the groups realized that if they worked together and collaborated and used the distributed materials together they could reach the goal and they started working as a team.
  • At the end of time box, the group who realized the team concept were able to build the tower. The group who worked individually did not have anything but only wasted material in their hand.

Learning to work as a team

After the game I talked with their class teacher and discussed the fact about how the kids were struggling to work as a team. We agreed that they will not be used to the team concept, if the culture and education system does not encourage team work over individual performance. A natural consequence is that these kids will also be struggling to work as team members when they have grown up.

We all know that the problems we encounter in business are complicated, and the solutions we need to develop are not plug-and-play. It is often not possible to achieve the desired business outcome based solely on the competence of one person and her knowledge of the expertise. Therefore, professionals with different competencies and expertise need to come together as a team to produce solutions, test them quickly, and produce them iteratively.

There is no one-size-fits-all

Finally it was nice to experience the game with kids and results that was relevant to our context. Realizing one more time that culture is also the main catalyst to grow and let the concepts like self-organization, team work, experimentation, etc. live in organizations. As it is a fact that culture is different from country to country, it’s also different in various organizations even different in various parts of the same organization. So agile coaches, we can’t apply the same solutions in every single organization. We need to find solutions and optimize them through retrospection and continuous improvement relevant to the cultural context of the environment. There is not one size solution that fits all. There needs to be real focus and support to grow agile concepts individually in each of the organizations.

How to get your conference submissions accepted

/by

I have been part of either reviewing or organising multiple conferences, both locally and internationally. I am grateful for this because it helped me to learn about how to create a submission that has a better chance of getting accepted. During my reviewing for the AgileXX conferences I had the opportunity to pair with some experienced reviewers and agilists, which also helped me to grow and learn.

I’m going to share what I have gained from the experience, and hopefully, it can help others out there…

Conference schedule board

This is what I look for when I’m reviewing a submissions:

  • It’s new.
    It adds something that hasn’t been done or thought of before, or it combines things from different fields or thinks about things in a new way.
  • There is a takeaway.
    I feel that people will have great takeaways from it
  • It’s inspirational!
    When I read it, I think, “wow, I want to go to that.”
  • Real life experience.
    The submission shows there is real life experience behind it, not just reading.
  • It is well written and to the point.
    A well-written submission with zero buzzwords and enough information for me.
  • It shows confidence.
    I am confident that the submitter can deliver from a speaking or facilitation perspective.

Out of this list, the most important to me is the submission is well written and to the point. A great submission is well written, has zero buzzwords and has just the right information for me. Getting this right is key to getting your submissions accepted. Here are my pointers for getting it just right!

Tips for writing your submission

Short & Sweet: The Title

Your title needs to be interesting. Let it say something about your talk. Don’t make it too long unless that is an intentional learning point in your submission. Often people will decide where to go based on the title, and I can’t tell you how many times I’ve seen terrible or boring titles. As a reviewer, you often don’t want to read any further.

Punchy: The Abstract

Your abstract needs to be short and punchy. The abstract or summary is the part that goes on the program, so it needs enough information, that people know what they are getting and are excited about it. But not so much that they get bored and stop reading. Reviewers and conference participants are also not always looking for the same thing, so if you completely optimise for one, you might lose the other.

Not many people decide before a conference where to go, so the abstract is often the thing that helps them decide. If your abstract is too long, people get bored and stop reading. If your abstract is like a bad movie trailer and contains all the best bits from your talk, then people will be disappointed, because they got as much out of your talk as they did reading the abstract.

So think about a good movie trailer, an original abstract highlights the good bits, but makes sure that the meat will be in the talk itself. As a contrast, an abstract with loads of buzzwords and that looks like a sales pitch either for the submitter themselves or for something that they have developed or a book they have written, can turn a reviewer off very quickly. A good tip is to approach the abstract as if you were writing a tweet, write and rewrite until you get the key message under the (self-imposed) limit.

Sell it: Information for the program team

In this section you have the opportunity to sell your talk to the decisionmakers: the review committee. Here is where you want to be clear about what your talk or workshop is going to be about. If you have hinted at new models or exciting new thinking in your abstract, be clear about what that looks like here. If you aren’t, there is no way for the program committee to know what you will be talking about. Be clear about how your session looks. People from the program team want to know this for workshops and talks. We want to know that you have thought about this deeply and that you know how you are going to spend the time. If you are proposing a workshop, we want to know that you have thought about how to scale it. Have you thought about what it will look like for 20 people vs. 50 people vs. 100 people or even 200 people?

Let us know in detail how you will spend the time. A great submission lays out in detail how the 45 mins / 90 mins / 60 mins / 2 hours etc. will be used. If I can see that, then I know you have thought about what you are going to do. If I can picture your session in my head, either talk or workshop, and I think to myself, “Wow, I want to go to that!”, then I will rate your talk highly – and chances are, so will others.

If you are doing an experience report, here is where you highlight to the program committee the things that people will learn or take away from your talk. Here is where you explain at a high level, why your story is better than the next guys.

Checklist

The don’ts

A few things frustrate me when I’m reviewing, especially when it’s late and I’m tired. So here are some don’ts:

Don’t send links

Please do not send me to your blog or your book. I don’t have time to read your submission plus 50 blog posts on the topic, I have 100 other submissions to go through, and I just want to go to bed. If you can not get your ideas across succinctly in your submission, you will get a poor rating.

Don’t give a breakdown with no detail

What I am looking for in the breakdown is what your talk/ workshop looks like. I recieved the below breakdown recently and that doesn’t cut it. Show me what your talk or workshop looks like not what a generic structure could look like. A structure this limited, just shows me you haven’t thought about it at all.

– Intro and topic setup (10 min)

– Body of topic (20 min)

– Learning recap (5 min)

– Q&A (10 min)

Don’t tell me how awesome you are

Nothing is more frustrating than a submission that is filled with details about how fantastic the speaker is and that they just published their new book/blog/podcast…. With little or no information for me about what they are actually going to talk about, (since I haven’t read their book) and what the audience will get out of it.

You need to make an impression.

As an organiser, you are often doing this voluntarily. Meaning, you have to make time in your spare time to go through hundreds of submissions for a big conference or between sixty and a hundred for a smaller conference.

Often there are 80 – 100 submissions for maybe 25 slots. At the bigger conferences there are upwards of 200 submissions for every 20 – 25 slots available. These are the numbers, and your submission is just one of many.

Even if you have all the right detail and a great submission, most conferences will have a team of people reviewing and so there are many people you need to impress. Even if you manage to impress many people, if someone else has a similar topic or a better submission, then you are out. And if there are more submissions with new and exciting things again you will be out. Remember you need to stand out from the 100 other submissions that are vying for the 25 slots on a program, make yours the one that all the reviewers say “Wow, I want to go to that!”  There is nothing more disappointing or frustrating for a reviewer than a great title or idea, and the rest you can see took only 5 minutes to write.

You aren’t going to be successful every time, but keep going and the better you get, the better your chances will be.

Timing is everything.

More than 50% of the submissions come through on the last day that the system is open. From there, reviewers often don’t have much time to get through all of them or as many as possible so that each submission is seen by at least 3 or 4 people.

If yours comes through on the last day and is number 65 of 80 or number 45 of 50 or something like that, then chances are most people have reviewed that many already today and are grumpy with the crap submissions and probably tired. Unless yours is a “shoot the lights out” submission, it’s going to get a crap rating at that point.

One final tip.

If you submit to the AgileXX conferences and if you submit early, you can ask for help, and there will be a team of people ready to help you improve your submission. Submitting in this way is probably one of the best ways to learn!

I hope these tips help you to write a great submission. If you have other tips to share, I would love to see them in the comments!

Announcing: The Hitchhiker’s Guide to Agile Coaching

/by

As agile42 coaches we are proud to announce that our first proper coaching book has been released! This is the book we wish we had had when we started out as agile coaches, and it’s now available for download free of charge.

We take great pride in our tradition of coaching, which is continuously being adapted to the needs of our clients and our own company. Our approach is simple, but not necessarily easy. With this book we wanted to create an introductory reference for new agile coaches as well as experienced ScrumMasters. It contains much of the theory that we teach our new colleagues at agile42, and hopefully lots of insights for new coaches everywhere.

Cover of "The Hitchhiker’s Guide to Agile Coaching"

The book is primarily about coaching, but not so much about agility. We are not going to explain e.g. why it makes sense to slice large work items into smaller independent pieces, or how to choose between synchronized and unsynchronized releases. There are plenty of good books around for those purposes. We assume that all readers have adequate working knowledge of all things agile.

Instead we are going to teach you the basics of listening, how to maintain a structured conversation without inserting content, and how to facilitate conversations in teams. We’ll talk about how to help a group of people form an effective team and how you can help create heedfulness and synergy in a team. We’ll present structured means of collaborating on a team with ScrumMasters, development managers and other agile coaches. We’ll cover why change makes people nervous and discuss different ways of overcoming that. 

All of this and much more is now available in one book. Becoming an agile coach is a journey that has no end… and that’s why the name of this book is The Hitchhiker’s Guide to Agile Coaching.

Since this book was written by a team, we have chosen not to stand out individually. Instead, we have been writing this book as if it were software developed by a team. However, we can disclose that the main culprits include a number of CECs, at least one CTC, and a couple of CSTs. This is the very first public release and it will be improved and expanded with the feedback of the community. We are happy to show it to the world for the first time.

Download here the e-book in PDF or EPUB format