Why (and How) I Started Speaking at Conferences

I did my first public speaking event at DDDNorth in February and then followed it up with a second presentation recently at the Leeds Testing Atelier. In this post I want to discuss why (and how) I went from audience member to speaker.

I’ve always been slightly in awe of people who have the confidence to speak in front of fifty, a hundred, or even more people! A friend of mine started doing technical talks a few years ago and after meeting a few more people who give talks I was rabidly running out of excuses.

I read somewhere that the fear of public speaking comes from our most basic tribe instinct. We’re afraid of making a fool of ourselves, of being ostracised from the tribe, and ultimately being seen as an unworthy partner. Even today, when we strive to create safe teams we’re still afraid of standing up and giving presentations to our colleagues.

So the question becomes what changed to make me want to push through this fear?

I’d been giving internal tech talks at work for several months. We used to do them over Skype, personally I found talking to a microphone much easier than talking to a group.

Something interesting happened when I started speaking about various topics at work. People came to talk to me about them!

I quickly realised that the natural progression of learning was to present. The work you do when you put a presentation together helps you focus your ideas, strip out what isn’t important, and ensure you have your topics clear in your mind. The best way to continue your learning is to allow other people to challenge you. In other words, the only way to become the expert is to act like an expert.

Now, I don’t claim to be an expert. But I like to think that the work I’ve put in pulling these presentations together has helped me learn the topics, but also clarify things in my own mind. There’s always the fear of a question you can’t answer, but there’s never any shame in not knowing something – that’s another opportunity to learn!

That brings us to the How. That part is actually surprisingly easy. There are loads of local tech community groups around, and you can quickly find a list of conferences in your area. Chances are they’re the same ones you’ve been going to for years!

Most of these conferences and groups are run by volunteers and most are crying out for speakers. Get in touch, get a date – nothing focuses the mind like a deadline!

Hopefully that’s encouraged you to go and give speaking ago – remember your audience want your talk to be a good one. Here are my top three(ish) tips to public speaking:

  • Submit the topic you want to talk about, not the one you think your audience wants
  • Don’t put bullet points in your slides, they steal your thunder and effectively makes you, the speaker superfluous
  • Don’t talk about pet projects (in the nicest way no one cares) or give sneak precious into something you’re selling (be generous with your knowledge)

And one for luck

  • Memorise your opening, the hardest bit is the moment just before you start speaking!

Is Velocity a Vanity Metric?

A few weeks ago I went to a talk at Agile Yorkshire by Tom Hoyland where he discussed the how he formed an agile team. In it he claimed that Velocity is a Vanity Metric.

If you haven’t read it then I highly recommend you pick up a copy of The Lean Startup by Eric Ries, this was my main introduction to the term. In the book Eric talks about how a Vanity Metric is any figure which is skewed to inflate the success of a product. One of the example he gives is Number of Registered Users, a figure which will clearly go up and up over time. A better metric, Ries argues, would be Number of Active Users. Obviously if you’re looking for a successful product you’re more interested in how many users are currently using it than how many people completed the signup process.

He claims that by basing metrics and KPIs on these Vanity Metrics is akin to giving yourself a pat on the back for building a successful product while sticking your head in the sand about why your business was losing money (or the startup running out of runway as he describes it in his book).

photo of woman looking at the mirror
Beware the Vanity metric! Photo by bruce mars on Pexels.com

So, to return to Tom’s question – is Velocity a vanity metric?

Most Scrum Masters calculate a teams’ velocity by taking an average over the previous sprints. The number of sprints varies but six (around 12 weeks of work) is the norm. Using this figure the the team can then calculate how far a particular story is away from delivery or epic from completion.

person typing on laptop
Photo by rawpixel.com on Pexels.com

There’s no doubt that Velocity is a useful forecasting tool (although, as one of my colleagues pointed out recently that if you plan a sprint on your average velocity then you will, by definition, fail 50% of the time). However, is it deluding us into thinking we’re a successful team and detracting us from more accurate measurement?

I think this comes down to how you measure success. Most people would agree that judging a development team on how many features they can deliver is fairly narrow minded. A development team includes a Product Owner, their remit should be to develop a product not to simply crunch features. If that was their goal then they could simply create huge numbers of easy, yet useless features just to score points.

In this new age of DevOps a Development Team should use their PO’s expertise and take ownership of the success of their product. For them to be judged on how much work they produce, rather than how much success they’ve had is a limited measure. It reminds me of the from the book The Goal where they measured and optimised the workstations rather than asking whether the system was effective.

Therefore, although shocked when I heard it I agree with Tom. Velocity is a useful tool for the team to forecast. But if it’s chased as a KPI or used to measure the team then it is indeed a vanity metric and will distract the team from trying to improve their product. If we want to measure our teams’ success then we should look at the metrics of our products, not try to calculate some kind of Hours to Story Point ratio or chase an ever increasing Velocity. We should focus on Number of Active Users or Number of Requests via the API, this will measure the teams’ success, rather than it’s productivity. As a friend of mine is fond of saying, effective rather than efficient.

Leeds Testing Atelier VIII

Last week I was lucky enough to go to the Leeds Testing Atelier which was hosted, once again at the Wharf Chambers in Leeds.

This was the 8th Atelier and the fourth (I think) that is been to. If you’ve not been along before then I highly recommend it as a conference, it’s a very unusual meet up – partially because of the informality of the event (did I mention it was hosted in a bar/music venue) but also because of the wide range of topics and speakers. Although centred in testing, the organisers understand that quality comes from a wide range of interpersonal, technical, and communication techniques and they encourage sessions on these topics at the event. I debuted my Communication talk at the event, but more on that later.

The first talk of the day I went to was The Sleepy Tester by Hannah Prestwell. Hannah’s talk was inspired by a book called Why We Sleep by Matthew Walker, it’s a book I’ve heard from before and I really need to add to my reading list.

Hannah talked to us about the importance of getting enough sleep, the value of sleep in forming memories and learning, and it’s value in emotionally reflecting on recent events. It turns out the phrase “sleep of it” really is based in science.

The next talk I went to was Imposter Syndrome by Beth North. Beth had the outstanding idea of creating imposter personas to identify the different ways Imposter Syndrome can impact people. It was a great talk and really engaged a lot of people in the audience (myself included). I had the sudden urge to run out half way through and update my slides to include her great ideas.

I spoke downstairs next. My talk was entitled Performance Testing Your Communication and I spoke about various ways of monitoring and maintaining safety in a conversations as well as how to influence people around you by understanding their personality and values. I was quite pleased with how it went, especially as this was the first time I’d done this talk outside work and I was delighted to see the tweets roll in afterwards.

The final talk I saw (I had to head back to the office for the afternoon) was a lightening talk by Sophie Weston about lightening talks. In house presentations is a topic very close to my heart. Not only do I think they’re a great way to share knowledge but doing internal presentations was how I got started before I moved onto external conferences – I can’t think of a better way to boost your confidence. I’m definitely going to take a few of her tips back to the office to see if we can use them to improve ours!

The team stayed later, really enjoying their afternoon sessions and talks. I went back to an afternoon in the office but really enjoyed my morning – the organisers were a great high and really made me feel welcome and looked after (especially when I had projector woes).

A huge thanks to the Atelier Gang – I hope to see you all next time!

Just How Safe Do You Feel?

I’ve written quite a lot over the last few weeks about Safety in team discussions. What I haven’t really discussed is how to detect when the safety is starting to fail. Imagine you’re in a conversation with someone, at work or at home and they’re starting to feel unsafe. We know that this means they will stop sharing and will result is poorer group decisions. But how do we know if someone is feeling like that and what can we do to prevent it?

If you haven’t read it already I strongly recommend picking up a copy of the book Crucial Conversations. In it, the authors discuss that people generally go one of two ways when they’re feeling unsafe. They either go to silence or violence.

When someone goes silent they often stop talking or become very monosyllabic in their responses. Perhaps they want to shut down the conversation or move onto another, safer topic or maybe they’re only sharing certain parts of the story – the parts which support their argument rather than discussing the potential problems with it. However silence manifests it’s usually because the person doesn’t feel comfortable with the topic and wants to move on or gloss over the real issue.

black and white black and white depressed depression

Photo by Kat Jayne on Pexels.com

 

Other people tend to go to violence. I’m not talking about physical violence (at least I hope we’re not making people so unsafe they have to lash out). I’m talking about attacking an idea or, even worse, a person. Comments like “that’s the stupidest thing I’ve ever heard” or “only a moron would say that” are attacks. People raise their voices and try to dominate the conversation through shear volume rather than calmly discussing the topic with someone else.

man couple people woman
Photo by Gratisography on Pexels.com

 

It’s important to realise that both of these are natural reactions when someone feels insecure discussing something. It may be that you’ve said something which has upset them, or it may be that they’re worried about the whole topic of conversation.

In the example I gave a few weeks ago the developer had an idea which he refused to share with the group because he didn’t think the team would listen to his opinion. However, he could equally have turned to violence and tried to force his point on the group by making them feel unsafe challenging him. Both of these are defense mechanisms. It’s our role as colleagues, as human beings, to look for signs that someone is starting to feel unsafe in a conversation and to look for ways to reassure them so we can resume constructive dialogue.

Collaboration is hard, if we really want the best decisions then we need to hear all viewpoints and listen to everyone’s experience. We can’t do that if we bulldoze our view too firmly. The next time you’re passionate about an idea take a look around you and see how others are reacting to you… are they going to silence or violence? We cannot change other people’s behaviour but if we try and support other people’s confidence then we’re likely to get ideas and suggestions presented which we’d never have considered ourselves – after all, isn’t that the point of a team?

Growing Agile Teams at Agile Yorkshire

I attended Agile Yorkshire last week and saw two great talks by Tom Hoyland and Jon Fulton. I really enjoyed both but a few points in Tom’s talk really interested me and I’d like to take a few minutes to share them.

Tom is a Scrum Master at Sky Betting and Gaming, I’ve heard good things about the company in the past so I was interested to hear one of their success stories. It turns out that Tom was part of a team of twelve who really stripped Agile “back to basics” and conducted a series of experiments on the road to continuous delivery. Working in a regulated industry myself I was intrigued how they’d got on.

One of the first things Tom talked about was how many different people in the team came to the table with ideas of what was agile best practice. We all laughed at his “my guru is better than your guru” but it makes a lot of sense! I am heavily influenced by Jez Humble, Gene Kim, and Clarke Ching but many of my colleagues may watch talks and read blogs from very different thought leaders. Tom explained that one of the first thing they had to do in the team’s formation was break many of the concepts down to their fundamental concepts and understand what worked for them.

Something else Tom discussed was how the team consolidated their own backlog. This was not controversial, how else would you prioritise the work against it? It was only when he gave examples of some of the different backlogs they’re identified that I became intrigued. Risk Logs, Retro Actions, and Design Session – all of these moved onto the board and each became visible and prioritised.

It’s dangerous out there – take your buddy! I’ve heard many of the advocates or pair programming before but the idea of your buddy following you into meetings, design sessions, and CABs!? Tom explained that if your buddy went with you to these sessions not only would they learn how to design, and walk work through the CAB but they’d also know the current state of everything you were working on. If you were sick or the proverbial bus came along the team wouldn’t need to bother you because everyone would know what was going on.

group hand fist bump
Photo by rawpixel.com on Pexels.com

 

There were many other good ideas (and I intend to borrow quite a few of them myself) but the final one I’m going to mention was the idea that Velocity is in fact a vanity metric (read The Lean Startup if you have no idea what I’m talking about). Velocity is just a number, like Number of Users or Number of Page Views). What we want are actionable metrics, like team predictability and accuracy of forecasts. As a Development Manager I frequently use the team’s average velocity to forecast delivery dates, Tom recommended that there are better measures out there such as a temperature check of the team’s current mood (which would often dip before any reduction in velocity). It’s an interesting idea, and one I intend to think more about over the next few weeks!

A big thank you to Royd and the guys who put Agile Yorkshire together each month. An equally big thank you to Tom and Jon for their great talks!

The Lock Complex

I have recently coined the term Lock Concept as a symptom of what many people call Fake Agile. Allow me to explain…

Waterfall development is often described with the Design, Development, and Testing phase structure. Many teams adopting Scrum tend to fall into one of two mistakes.

waterfalls
Photo by Trace Hudson on Pexels.com

The first mistake is to split up these into sprints. So Sprint 1 is for design. Sprints 2, 3, and 4 are for development and testing and bug fixing will go into Sprints 5 and 6. This isn’t Scrum. Clarke Ching uses a phrase I like in his book Rolling Rocks Downhill, he talks about GETS software. That’s Good Enough To Ship, at the end of each sprint the software must be production ready. By falling into the sprint phase trap you’re lowering quality between releases and not realising the value of scrum.

The second mistake teams make is to try and run each Sprint as a mini waterfall. This is what I now describe as The Lock Complex. Teams falling into this trap will design in the first few days, develop for a few more, and then test their work towards the end. Yes, the software is GETS at the end… but doesn’t this look like a waterfall on a smaller scale?

neptune27s_staircase_2017_head-on
Canal Locks of Neptune’s Staircase by aeroid CC BY-SA 3.0

The main symptom with this approach is people twiddling their thumbs (testers at the start of the sprint and developers at the end). While wasted time is frustrating, the real problem is the lack of shared knowledge and by unlocking that you can quickly raise your game towards Continuous Delivery.

The way to solve this becomes quite apparent if you look at the DevOps utopia we’re all told about. In a world of Continuous Delivery and automated approvals we create automated acceptance tests to ensure that our code functions as expected. If the feature doesn’t meet these automated tests then it will not be merged in, or if it has been then the deployment pipeline will stop.

In this world, not only are we deploying faster and achieving single piece flow but we’re breaking that Lock Complex. People are busy all the time and pair and mob programming becomes the norm. Instead of having a testing phase where it’s our QA’s engineers’ time to shine we have continuous collaboration and our quality specialists advising on the best tests and mechanisms to be implemented. Testers no longer run manual tests, we get computers to do that. Testers work to ensure that the automated tests give us a coherent test strategy.

If we can help our teams to break the Lock Complex and stop working in mini-waterfall sprints then we’ll see the benefits as people collaborate more and achieve better velocities and higher qualities as a result.

Crucial Conversations Book Review

I’ve been posting a lot about communication and safety recently and I want to give credit to the book which kickstarted my renewed interest.

Crucial Conversations is by Kerry Patterson, Joseph Grenny, and Ron Mcmillan. In the opening chapters the authors explain that a crucial conversation is any exchange where the stakes are high and emotions are running rampant. They describe how avoiding these conversations or handling them badly can leave lasting repercussions on our wellbeing.

Over the following chapters they describe how to recognise safety, how to reinforce it, and how to reach a positive outcome. It’s really strong stuff, in fact I’ve incorporated many of their ideas in my own style and recent talks.

The book isn’t targeted to a work environment, in fact many of the examples are close to home and personal scenarios. Asking for a raise or disagreeing with someone over a design choice will seem like small fry compared to some of the issues the characters in the book face.

However, I believe strongly that by using these techniques teams can communicate more effectively. By using some of the ideas Kerry and his fellow authors use to monitor safety in a conversation we’ll have better retros, planning sessions, and general collaboration.

If you’ve not read it then I strongly suggest you pick up a copy – it’s one of the few books I’ve rated 5* this year.

CCBook