Speaking publicly about something I know nothing about

After years of working as a Business Analyst, I have always wanted to try my hand at public speaking in order to share some insights on topics I feel passionate about and things I have experienced.  

I have been lucky enough to have performed varying types of music in front of tens of thousands of people around the world, but there has always been something nerve-racking about public speaking that put me off.  

I feel my face go bright red if someone even just mentions my name in a crowd of people or in the open office at work.

However, I’m pushing 40 and wanted to confront some of my fears.  So, go big or go home right?  I applied to speak at the IIBA Business Analysis Conference Europe 2019 and they said yes!

To make this a bigger challenge, I chose a topic I knew nothing about with a view of learning about it: “Horizontal vs vertical user story slicing”.

What is horizontal or vertical user story slicing?

The most common analogy you will come across is the depiction of a cake.  A horizontal slice could be the bottom layer of sponge (a database), then a layer of cream (back-end java code), then another layer of sponge (APIs) and so on and so forth.  The idea being that a team would develop each of these layers and then pass it on.  On the other hand, a vertical slice would be an actual slice of the cake with a little bit of each layer.  Or in the tech world it would be a little bit of functionality of a product that can be tested end-to-end.

BUT

I’m really bored of seeing the same picture of the the same cake on article after article.  So, I want to relate it to something I am passionate about.  Music.  In particular, recording music.

So picture this – you have written 10 songs, you like them and your adoring fans like them too, so you decide to record them.  You head into the studio for a 7 day slot and the following happens:

• The drummer records all 10 songs in 2 days
• The bass player records all 10 songs in 1 day
• The guitarist records all 10 songs in 2 days

The singer now has 2 days to record their parts…plenty of time. This is great!

HOWEVER

There is a problem.  The bass player and guitarist tuned their respective instruments to each others and didn’t use a proper tuning system.  When the singer comes to record their part the pitch is too high and they can’t reach all of the notes.

You have some options… record it anyway and ship some sub-standard recordings.  Or you could redo the bass and guitar and pay more money and invest more time in correcting what isn’t working.  Eventually you will probably get to the end, but it will be more expensive or it might not be what you wanted in the beginning.

What would you rather do, ship sub-standard product or increase costs?

At this point it’s also worth noting that it took 5 days to spot this problem!

What’s the alternative?

Well, you could vertically slice the recording of the songs. The situation is the same, you have 10 songs and 7 days. From the very start you record everything at the same time.  Within a couple of minutes the singer tells you that they can’t reach the high notes and can the bass player and guitarist check their tuning.

They do and they correct it.  Takes 2 minutes.  The band carries on recording.  After the first song is done, they can listen to the final version, assess whether they are happy with it, does something need to be louder, quieter, faster, slower, have some kind of sound effect…that’s right, you couldn’t have done ANY of this when recording it the other way.  At least not until the very end and at an extra cost.

Your feedback loop has shortened from 5 days to less than 5 minutes.  Imagine doing that at work!  Not having to compromise on quality or increase costs AND being able to innovate (adding those sound effects) as the project progresses.

Do you have a project example?

Yes, I do.  It’s a fictional one, but none the less it could be real!

Imagine creating the software for one of those self checkouts you see in Supermarkets.  If you were to horizontally slice the project, you might have some stories that look like this:

1. Set up a database
2. Set up an API
3. Design the UI
4. Some backend code
5. Some front end code
6. Set up bank contact
7. Read payment card data
8. Receive bank acknowledgement

What if the designers have’t finished the designs after the back-end code is finished? Well, you’ll have a front end developer waiting to get started.  Sure, they could work on something else, but it means the momentum of this project is slowing down and you have to deal with context switching.

Even worse, the CEO or MD might say that the design team have to focus on something completely different, so the project stops all together.  You have now introduced waste.  All that time spent by the teams working on the database, APIs and back end code just sitting neglected, lonely and cold in a bitbucket or github somewhere.

What if you were to slice the story vertically?

1. Be able to scan an item
2. Verify item scanned
3. Calculate & display amount
4. Offer payment option(s)
5. Acknowledge card and PIN
6. Verify PIN
7. Accept / decline payment
8. Print a receipt

Each of these points is a shippable product. It might not do much, but you can test them end-to-end. More importantly, you can get feedback on them quickly and inexpensively. 

What does this comparison look like?

With art not being my forte, but in a spirit of new challenges I drew a graph to demonstrate the timeline of a project and the delivery of value from all the hard work you might put into it.  It looks like this:

The red line depicts the continuous delivery of a vertically sliced project and the yellow line shows the value delivery of a horizontally sliced project – the difference is clear!

Summary

Horizontally sliced project will give you:

• No demonstrable product until the end
• Increased chance of bottlenecks
• Difficult to prioritise
• No items deliver value
• Technical slices
• Creates distance from the client

Vertically sliced project will give you:

• Shorter feedback loop
• Innovate and improve throughout the project
• Visually informed client
• Vision of value
• Anybody can understand the requirement
• More manageable

So how did speaking publicly about something I know nothing about work out for me?

The pressure of committing to deliver something is something that I quite enjoyed. 

I spent more time on my personal development. And this worked twofold, first to learn a new topic, but most importantly to put myself in a position where I would really push the boundaries of public speaking.

Admittedly, the best part was at the end and I could let out a sigh of relief and people told me how much they enjoyed it.

Would I do it again? Definitely!