AgileData #4 - The Art of Data Story Telling

Welcome to the Agile BI Podcast, where we chat with guests or sometimes just to ourselves about being agile with teams who are delivering data analytics and visualizations. Hi, I'm Shane Gibson.

Hi, I'm Blair Tempro.

Hi, I'm Cat Greenbrook.

Hey Cat, welcome, thanks for taking the time to join us today. I suppose what really piqued my interest was this idea of data storytelling. So, yeah, we do a lot of work in the Agile BI space, we're working with data, we're working with analytics, we often talk about visualizations, but what we find is visualizations are synonymous with a dashboard. And, you know, I listen to a lot of Agile podcasts around the world, and when I hear podcasts about storytelling with Agile, what I tend to hear is about presentation skills, about way of people presenting their story verbally. At a conference or to the team they're coaching or to the stakeholders they're working with. Whereas from what I see you do, you tell about how you can tell stories with data when you're not actually there to verbalize it, to wave your hands, to give it that emphasis. So really keen to talk about that today, but before we get going, why don't you tell us a little bit about your journey to how you got to where you are now with data storytelling and Roopengam.

Yeah, sure. How far back do you want to go?

We've had back to 20 years, so whatever you think's interesting for the audience, or more importantly for us.

Well, I graduated university with a science degree. Back then it wasn't— you couldn't go to university and get a data science degree or an analytics degree or anything like that. That just wasn't done. So I came out with a science degree in genetics. Didn't want to work in genetics, so fell into business. And I started off in a customer service center because that was the only role that I could get with a science degree, and worked my way very flukily into analytics roles. And so my journey in this whole data space just kind of went from there by accident almost. And so I've done a lot of different analytics roles and right from reporting through to insight and then more predictive modeling. Worked in New Zealand and overseas. And I kind of got to a point about 10 years into my analytics journey where I was just getting really frustrated with the lack of action off the back of any of these outcomes or outputs. And I had it in my head that data visualization was was a solution to this. So for me, at the time, I thought data visualization would make analytics more engaging, which would lead to better decision-making off the back of it. And so data visualization then became the next step on the pathway, and I went and studied digital design to help me with that kind of side of things. Some of my early data visualizations were absolute crap. And I can say that because I did them.

And they were still better than anything I can do today.

Yeah, well, we learn, don't we? Yep, you do. And study really helped in that, to fill in my design, my design gaps. But what I found in the last couple of years since starting Rogue Penguin is that data visualization only takes you so far. And you can make something that's really pretty and really engaging, but actually really useless. And so for me, the whole data storytelling side of it is more around how do we effectively communicate our insights. And if you combine that with good data visualization, then that can help make a difference.

Cool.

So that's where I've ended up.

Excellent. So, so that combination of storytelling and data, right? So I remember, you know, when we were kids, I used to read comics, right? And I love comics. And I remember working with you quite a while ago where we We took this weird idea of taking a user guide with something that was quite complex and turning it into a comic, right? And it's still sitting on the wall, I still love it. For me, the amount of time you took to distill something that was quite complex and make it into something that was so easy to consume as a comic was a lot longer than I would have expected, right? How do you find that with data storytelling, right? How do you find that in this modern agile world where we get taught that, you know, I can grab a bit of data, I can I can whack it through these magic tools and I can just get a dashboard in 15 minutes or less. Where what you're trying to do is distill some complexity into something that can be consumed as if it was a comic. If that's how you still think about it, how do you find that process? Is that as hard as it's always seemed?

Yeah. And we don't spend enough time on it. It is the time, the longer time you spend on it, the more effective I think it ends up being. And if you're designing something for yourself, there's no need to worry about it, you already know it's effective for you, right? But as soon as you start designing or communicating to somebody else, that's when you've gotta put in the time. And I actually, I was having a chat to someone earlier, last week I think it was, and she said something and it really left me feeling like, oh yeah, you know, it really had an impact. And so she said that we put in the effort now, and even if it's 10 minutes extra of our time, well, if we combine all the time it takes all of the people that receive what we do and say they have to put in 10 minutes extra of their time, and then it adds up and adds up. So just a little bit extra of the storyteller's time actually is quite impactful if you think of how many other people then have to consume that information.

So I was wondering how you work with your customer on that. Do you spend a lot of time up front, you know, collecting requirements and kind of just fleshing it out, or do you bring them along for the journey as a kind of an agile type setup where you're alongside them for the whole thing?

Yeah, it works differently with different people, and I think it depends on the scope and the purpose of the the output. And so sometimes if it's a data visualization, it's got a completely different purpose maybe than a report or an A3 or something which combines more storytelling. But I'd like to split data storytelling into the writing part of it and then the visualization part of it. So if you can get the writing, the actual narrative written down first before you even start to think about any of the visuals and how you display the data, If everyone can agree on that first, then the visualization side of it is very easy to do. And I like to go back and forth a lot when I'm dealing with clients, just because you don't want to give them something at the very end of the process and have them, you know, take it to pieces because they haven't been involved.

And that's what Waterfall does, right? Is, you know, talk to them at the beginning, think you understand their expectation, and then come back at the end and be surprised where they go, "Yeah, that's not what I wanted." And we've all made those mistakes. No, no, no, we've all done that. Many years of our life. So what I really liked about that was what I think you said to me was you almost do a draft of the key points of the story, right? So this is the kind of story we're going to tell, and then you iteratively flesh out that story, and as you do that, you go back and talk to them. Do you find though, as you— so you have your narrative, you know, which is telling telling the story you want to tell, and then you go grab this thing called data, and no doubt at some stage you find that either the data doesn't support that story, or worse, you don't have data that can support it or not support it because the data is just not there for that piece of the sentence or that paragraph. Do you find that happens a lot, a little?

I find people think that that happens a lot, and you've pretty much just described what, what people are scared of, I think, around data storytelling, is that whole, that you're you're making up the narrative before you look at the data. But data storytelling, if you're thinking of the whole analytics process, comes at the very end. So you've already done all the analysis, you've got all the insight. It's just about arranging it in a way that makes it concise and compelling to consume.

So I suppose one of the things I've spent a lot of time working through when I'm teaching or coaching teams around agile and data now is this idea of natural language, you know. You've been through the BEAM stuff, and it's that thing of beauty of when you say, "Who does what?" It's a natural language. I still struggle with what a data story would be, right? Because I'm still used to dashboards or an A3 roadmap that tells us where we might be in 2 years. Have you got an example? I'm putting you on the spot here. An example in your head of what a data story, what a narrative might be, just so we have something to frame it with?

So the difference between a data story with a narrative and a dashboard has got to do a lot with the kind of visualization that it's communicated through. So dashboard visualizations are very exploratory. They're more operational. And they're designed for people to explore. So to find the information that they're looking for. Where an A3 or a narrative data story is more— it's not designed for someone to explore. It's designed for someone to consume. You're actually taking— you're designing the story for them rather than them having to explore it to find it themselves.

So effectively telling them the answer but taking them through the beginning, the middle, the end.

Yeah, and why it's important. So a lot of the time when we communicate insights, we might put it in a report. There'll be a whole bunch of graphs on a page, and people are kind of left to their own devices as to choose what's important to them. And if they don't understand something in a wider business sense, they may not get the full story or the big picture. Yep. And so the point of data stories is help to communicate insight that, that does show that big picture and it pulls in all those aspects of why it's important and why these particular data points or things that we're finding in the data is important.

So if I still think of a data story as like a comic, beginning, middle, and end, like any good story, have you got an example that you've done where you could tell us that really quickly, that narrative is an example of what a data story would read like?

So it doesn't have to have a beginning, middle, and end. I like to think of it, yes, it's not a story in the sense that we think story, it's more just narrative structure, and so we apply narrative structure into the way that we communicate insight, then it becomes more engaging. And so there's a great narrative structure by someone called Randy Olson, he's a science communicator, and he's called it an ABT structure, which stands for And But Therefore. So I like to think of the 'and' section, you can have something, and then something else, and that's kind of setting the scene, it provides a background, so any context that a reader needs to be able to understand what's coming next. And then the middle section is the problem, so you have something, and something else happens, and something else, and it goes on, and, and, and. And then you go 'but', which is a big contrast here, and that's what engages people, that's what wakes people up. And that's where you have this kind of problem statement that you can lay out using data or whatever you've got. And then the therefore statement at the bottom just sums it all up. It says, well, what's next? What are we going to do about it? What does this mean? And it's a really simple structure, but it provides a lot of, um, it's a lot better way of communication rather than just going, here's a graph of this, and here's a graph of that, and here's a graph of this, and kind of expecting the data to speak for itself.

Right.

Because the data never speaks for itself.

No, no, no. Well, it probably speaks in many different tongues, right?

It speaks for the person that's designing it or building this.

Yeah, exactly. And so you've got to be very careful, I think, as a data storyteller, not to put too much of your own bias or the business's bias even into what you're saying, because it can get very, very biased in the way that you present information because you are dictating the narrative.

Oh yeah, I've seen these complex spiderweb type I love those neural network graphs, yeah.

That's my standard storytelling.

Because, because, I mean, I think of them as London Underground, right? I love the London Underground as a visualization. But the reason I love it is that once I have the data in that format, once it's visualized, I can verbally tell multiple stories. I can say, hey, look, you know, this is what's happened. But I have to be there to verbalize it. As soon as it's on its own, yeah, you're overwhelmed, right? There's too much, you don't know what to focus on. You can tell yourself your own story.

Lots of different narratives that you can tell from one visualization.

Yeah, yeah, so that's a good point.

Yeah, so we're sort of moving towards the Qlik stories, you know, using the part of Qlik that you can actually build that narrative in, but we're not experts by any means.

So you know when you guys did that public-facing stuff that you've just done, where you're producing some data or some visualizations to to members of the public, did you guys take a storytelling approach or did you kind of reuse your dashboarding? We know these are things we want to count or present.

So this was very, very much the first prototype or the first example. So we took something that we already had and built it into QAP, using QAP. But that's certainly the journey we're going to go on now that we've got ClickForPublic. We're going to be building a roadmap so that we can, you know, start putting a bit more effort into the user experience and the storytelling. So the tool will become experts very quickly, or no one will look at them.

Well, it's interesting you say that you're relying on a tool to be able to tell stories. Yeah, because I don't, I don't think that's going to solve the problem.

Exactly. It's the old technology doesn't solve what people can't do. Yeah, but it might make us think about telling stories, whereas at the moment it's pretty much just—

it's going to make it easier.

Yeah, yeah, yeah, hopefully.

Or worse, because you'll bring back some visualizations where you could tell 4 or 5 stories with that one visualization. You know, you're not going to come back with a visualization that's one number. No. You're probably unlikely to come back with visualization that's one line on a bar chart.

Exactly.

You're going to bring back at least two dimensions, because that's how graphs work, if not three or four. And then you're going to try and either— either you're not going to write a narrative around the way you could look at and the outcome that you should get, or you're going to write one that's so complex with an if-then-else-but-but-could-be that actually I'm going to read it and go, yeah, that was overwhelming. Yeah. Maybe. I don't know. It's a good experiment.

Very good.

Wait till you do the next round and then we'll have a look and give you a retro. Awesome.

I always love Shane's retros.

Retro in process, not now.

Be ready to be told off.

Told off? You mean encouraged to review what you're doing in ways you could have improved?

Yeah, but told off is easier to say.

That's so un-Edgehold coaching, thank you very much. So I know you've kind of moved from doing right, to kind of teaching, and I'm assuming at some stage, or if you're not already now coaching and mentoring teams, you will be. Well, that's a good brand name, isn't it? Do Teach Coach? Or is it Teach Coach Do? So anyway, so the thing, you know, when you run your courses, right, when you teach people how to tell stories, what are you finding the majority of the audience is made up of? Is it BAs? Is it cool visualization people? Is it data transformation gurus? Is it BI data teams? Or, I mean, it's gonna be a mix, but what kind of— is your standard audience at the moment?

Definitely a mix. I've had a lot of different people write through, from engineers to HR people. But majority of them work in BI analytics teams for big companies, so the data that they're dealing with is obviously quite big. And they just need help with communicating their insights.

Cool. So they're trying to basically improve the way they behave. Yeah.

Improve their effectiveness of what they do, right? So they're really, really, really good at what they do analytics-wise. They just need a little bit of help with how do they communicate that elsewhere.

And do you find that that process of telling a story using data is a team sport, or is it at the moment kind of something where people tend to do it on their own?

Could be either, so it works well either way. I've had teams where we've had Post-it notes all over the wall trying to arrange a narrative structure, and it works well, but I guess it's like anything, the more people you have involved in something, the longer it's going to take. You've got more opinions, you've got more people that really, really want their data included, even if it doesn't actually have anything to do with the narrative, and so what we find is that maybe there's a couple of different narratives that come out of those kind of exercises as well. Cool. Which is okay.

There's nothing wrong with backlogging future stories.

Yeah, once you've proven the value of the first one. So is that more of like a storyboarding technique where you're starting to use Post-its on a whiteboard or a wall to see the different ways you could storyboard that and then focusing down onto which one, you know, thin slice, which one we're going to do first?

So I like to have it that it's really high-level first. So I kind of have a narrative structure that's just an elevator pitch, and then you flesh it out as you confirm those. So you might have a couple of different elevator pitches, and then maybe the team splits up and goes off and tries to nest other narrative structures under that one.

Cool, so kind of decomposing the backlog down into almost tasks, if not user stories. So on that, do you form a persona or an audience that the story's targeted at? Is that something that you kind of craft craft around it to help focus on the type of person that's going to consume the story, therefore the way you tell it and the way you visualize the data to support it is different.

Yeah, absolutely. So that comes before you even get to the narrative. So for me, data storytelling is 3 important things. So message is obviously a big one, which includes narrative and data, but you've also got purpose and you've also got audience. So it is a form of communication, so any form of communication needs to have a Purpose. Otherwise, what are you doing? There's no point trying to communicate something if you've got nothing to say, and so you've got no purpose. And audience— if you don't understand your audience fully, it doesn't really matter what you're saying if you're communicating it in the wrong way.

So these are the important questions you ask the customer up front, obviously.

And some of it is just going through certain exercises to unders— understand audience better, and it may be that you're just guessing, which is fine, but you're still putting yourself in a position to have a little bit of an opportunity to have empathy for someone else. And so audience understanding is all— it's really around thinking, how would this person like to be communicated to? Because this person is not me. A lot of the time we communicate things in the way that we want to be communicated to. And so if you're an analyst and you're loving a lot of detail in the way that you're communicated to, you tend to push that detail onto someone else, whether they like it or not.

Yeah, and I suppose the other thing you'll find is that when you say to them, "Who's the audience?" they'll go, "Everybody!" You go, "Oh no, no, no, everybody in the company!" You know, and so that's easy, right? I can opt out just by going, "Everybody." I don't have to think about it, I don't have to make a decision, I don't have to take a risk that I've got the wrong audience or communicated the wrong way.

And the thing is, if you try and please everyone, you end up with something so generic that it's not fit for purpose, of any purpose.

So when you talked about and, and, and, and, and, but, and then, you know, is the then an action? Therefore. Therefore, sorry. Is that an action? So, you know, years ago we kind of worked on this idea that there's no point building an analytical model if you didn't have a hypothesis about the action you're going to take. So, you know, you talk about, you know, one analytical model that's going to do cross-sell. Why are we doing this? Well, you know, the action we want to take is offer a person something else and hope they buy it, right? So that way it helped us kind of refine the model so that it was small enough, agile enough to just answer that, and we could build later, but we weren't boiling the ocean. Do you, in the way you talk about storytelling, the therefore seems to me to be, I'm inferring at the moment, that it's an action. Right at the beginning you were saying, what's the narrative we want to tell, who are we going to tell it to, and what action would we expect them to take as a result of that narrative if it was successful? Is that— did I get that right?

It can be an action, doesn't have to be, so it's just a structure. And so the therefore could just be reaffirming what you've already said. The therefore could be, therefore we need to look into this further, which I guess is an action as well.

Right, yep.

So it can be It doesn't have to be an action, no.

But if it's not an action, what's the point? Apart from it's pretty and cool and I can put it on my website.

Well, the therefore could be to say you've got a problem, I don't know, I'm thinking off the top of my head right now.

Sorry, on the spot now, yeah, that's what we do on the Ed LBI podcast.

What about therefore we accept that nothing's going to help this cause?

Well, that's I guess an inaction, but your therefore could back up your hypothesis. At the beginning, you can say. So therefore we were right in our thinking that the data backs us up.

Right, okay, so therefore the actions we're taking based on that data are now supported by the narrative. Yeah, okay, okay, I like that.

It's a bit like on the story card that we put up there.

So that.

So that.

Yeah, yeah, that's what I'm hearing.

I use user stories as well when I do audience understanding exercises.

Oh really?

Yeah.

Tell me about that.

So if a lot of the time when you're designing something, you, as you said before, you want to design it for everybody, But that doesn't work, as we've talked about. So I get people to write down all the possible different audience groups that could be interested in something like this. And we end up with a whole bunch of Post-its all over the room. And then for each of those audience, try and get people to write as many user stories as they can about those audience groups. And what we find from that exercise is you'll get certain audience groups that you know a lot about, and you can easily write user stories for. And most of the time, this audience group ends up being your primary audience. It's good to be aware of everyone else that could be interested and what motivates them, but at the end of the day, you're designing for a primary audience.

That's cool, because that's picking up that whole agile technique that as we learn how to do new things, we should try and isolate the risk or the change or the things that are hard in other areas. So if we picked a group where we didn't actually know a lot about them, we couldn't articulate a user story, and then we use them as the way of practicing and learning how to do data storytelling, then we're naturally having to learn two things: what do they want, what do they need, and how the hell do I do this process. By isolating it down to things we actually know quite well, then we're just focusing on that data storytelling. So, I'm stuck with user story land as "as that, I want so that," you know, and typically, because most of the data BI analyst teams I work with, we get down to a relatively basic technical user stories by natural. Have you got an example of what a user story would be for you in that kind of, in that framework?

So I do exercises in my workshops around climate change data. It's a very big topic. It involves a lot of different audiences.

And something you're passionate about.

And something I'm passionate about, yep. And so we go through an audience brainstorm exercise and A lot of the time the groups are quite big, and so what I like to do if we have like a general public audience is split it into what do they believe. Do they believe in climate change or do they not believe in climate change? And so writing user stories for those two different groups, you'll have quite different user stories. Yeah. And it goes back to actually understanding the purpose of why you're communicating to these groups. So I give them the purpose. The purpose is to, um, to get people to to change what they do to— against the negative effects of a changing climate. So get people to change what they do to counteract those effects. It's not to get people to believe in climate change, and that's the important thing. So purposes don't change when you're communicating something, but the message can be tailored to the audience. That's why it's so important to understand the audience before you start writing the message. And so writing a user story for someone who doesn't believe in climate change, it's never going to mention the word climate change. Versus someone who does believe in climate change, you can mention it at Growth Gold. But it's realizing what motivates people, and there could be really simple things. Like, a user story for someone who doesn't believe in climate change could be, "As a climate change non-believer, I want New Zealand to reduce their fossil fuel use, so that New Zealand can keep its clean, green image." So you're still designing for that purpose in mind, but the way that you communicate to that person is not going to mention the word climate change.

Cool, and then the narrative and the data is then to support that user story and encourage that behavior. Yeah, it's interesting you talk about, you know, you can't use the word climate change for the people that don't believe in climate change. The number of times I'm coaching a team where we have to use the word iterative or new way of working or agile BI way or iterative BI way or new way, Because, you know, somebody's experimented with doing stand-ups on a daily basis, haven't changed any of their other behavior, and therefore they've— I'm using my fingers with the quote marks— they've tried Agile and failed. So yeah, that's interesting. So when we bring up this lovely world of data science and all this new nirvana that will automate our lives, What I found is that the first part of data science, when we started that journey, we moved away from teams to teams of one, right? We had the unicorn. This was a person that I articulate could be a business analyst and engage and understand the narrative of the story that needed to be told, could go away and engineer the data in a repeatable way and write the code. And then for the third trifecta, it was, you know, actually could then write the do the analytic hypothesis science of it, of I have an experiment, I want to prove that's true or not, and then close that out. So the true unicorn that could do those three things well and repeatedly. What I've seen is actually we end up with teams of three, right? We end up with somebody that— or teams of two where there's a bit of an overlap, but typically three core skills: the facilitation, understanding, and dealing with people, the engineering of the data to see whether the data is— make the data available for testing the hypothesis and the testing of the hypothesis. But I don't often see the storytelling, right, in there. It's either— I'm not sure whether it's naturally a T skill within one of those three roles, or actually we just need to introduce that fourth skill. Yeah, and I don't know. I mean, I don't know whether the data scientists are naturally producing data stories that have narrative and content that can be used without them waving their hands and saying the words. What's your experience?

Data storytelling is a relatively new, I don't know if you call it a role yet, but it's in, I updated my website maybe 18 months ago with data storytelling more as the focus service. And I found that I didn't get as many hits. We weren't talking about it. So I rebranded to Data Visualization and made that the focus because everyone was talking about it. And even though it was the same thing, we didn't understand the concept of data storytelling back then, even just 18 months ago. Now data storytelling is the term that everyone understands and wants.

Do you think in New Zealand or globally?

I don't know yet.

'Cause I don't see it on the Gartner— oh, I have to check. I don't see it on the Gartner hype cycle, or—

Well, it was listed as something that teams should train or educate more around, the data storytelling field.

Right.

And, but it's never been listed, I don't think, before. So it is a relatively new thing, but I think a lot of the time it gets incorporated into data visualization as something that data visualizers would just naturally do, or should do. Especially if you're creating more of the infographic kind of visualizations. But the amount of infographics that you see that have no narrative whatsoever, they're just a bunch of statistics on a page, that's not a data story.

For me, I've seen infographics digress, or regress, sorry, is the word, right? They used to take a long time because you were handcrafting them, and I'm assuming that's because you're doing the process you're talking about. You figured out what you wanted to say, you wrote the narrative, and then you created the visualizations that supported the narrative. As more tools coming out with some form of infographic creation, really what you're doing now is just putting a bunch of graphs on a page that doesn't look like a standard matrix dashboard. You're not actually crafting the narrative. So I think, you know, we've lost the art of the infographic.

Well, I think the more tools that come along that make it easier for you to just put a bunch of graphs on a page and maybe an icon or two, make it look a little bit more engaging, maybe there's less value in the people that are actually crafting that narrative and spending that time.

I've seen some really good examples, probably the best one is during the Brexit voting where they had just a a map of the UK, and blue is yes and red is no, and just a heat map around the country, and no words were needed. It was just, this is where they're saying yes, this is where they're saying no. But it's pretty rare that you'd— I'd say that you wouldn't need words to back it up.

Well, that's— I would still call that an exploratory data viz, but you— they would have made it knowing that really there's one big narrative that people are going to see. Naturally from it, so they don't need words, they don't actually need to show that narrative, just the visuals enough.

But that's unusual, right, that we can distill our data and our hypothesis down to a single yes/no, or a pie chart with a big slice and a little slice, right? Yeah. Which is effectively what we're doing.

You're relying on the audience to have an understanding already of the background and what could contribute to that narrative.

Which comes back to right at the beginning, you you talked about who we're writing this narrative for, and therefore you could gauge their level of skill, their domain, or their knowledge around the subject, and therefore you're telling the narrative to support who they are and what they already know, teaching them something new, not teaching them the suck eggs, or making something incredibly complex where there's no way. I mean, Haley had a really interesting one, she's making sensors for houses that monitor carbon dioxide and humidity and that for healthy homes. And she talked about, you know, she was a product owner. She's been a product owner for a long time. This was her company. She took an experiment and it failed. And her experiment was she thought she could get them made in parts and then delivered out to the houses where they could put them together. And that way she would save money and make it cheaper for them to buy. But she found when she went and tested it, that actually a number of the people didn't actually know how to use a screwdriver. And so she had to document, you know, lefty loosey, tighty righty, righty tighty. And again, we forget that our audience is not us.

We design for ourselves.

We design for ourselves. Yeah, you said that. So yeah, really, really important. So the magic that's coming in terms of all these great tools, right, these storytelling visualization tools and AI, again finger quote, where it's going to look at my data and use natural language magic with machine learning and a neural machine AI thing and just tell me the story. Is it coming? I know it's coming in a hype cycle, but—

Different purposes. So I think yes, AI is going to get better and better and better, but that's something more, I think, when you're designing for maybe a tool or an operational purpose, incorporating AI into those kind of solutions works really well. Data storytelling is completely separate. It's far more communication than it is trying to create a tool or a software from it. So yeah, chalk and cheese, I think.

So coming back to those agile principles that conversations are important, collaboration is why we do it.

We actually have to think for ourselves.

I think I used to say, "Still need a brain." Yeah. Yeah, cool. So data storytelling in New Zealand, apart from yourself, how many other people would you say are teachers or coaches or experts in this domain in the whole of New Zealand?

Not, to be honest, there's probably not a lot of storytelling in the way that I've described it, in the way of actually including that narrative or writing that narrative first. There's a— Cole Neflix, she's from the US, she runs data storytelling workshops all around the world, she's been doing that for a while, and so she's really big internationally in this field. I think it's a very almost niche audience for this as well, so data storytelling, it's It's going to be really beneficial for people who are knee-deep in data, and have to communicate their insights that they find to a wider audience. If you're thinking at it from like a brand or a company point of view, trying to communicate to the general public, it would be quite different.

But don't you think that the idea of the way you teach data storytelling, the way you teach it, that you need to understand the message you think you want to tell, you need to understand the audience you're going to tell it to, you need to craft a narrative. But it's a process, right? And it's a process that any team that deals with data analytics or BI or visualization, that process itself is really valuable. It's a process of iteration, it's a process of collaboration, it's a process of learning fast whether you're not actually going to do what you committed to. I just, I heard a whole lot of agile techniques even though you never use the word agile, but they're just implicit in the way you're behaving and the way you're coaching. So for me, that's cool, right? Yeah, it's again, it's just a reuse of better ways of working, but in a whole new area, which is an area that's been around for a long time, but, you know, underserved.

Well, I think it's like any new discipline that comes along, it kind of incorporates a whole lot of things from a whole bunch of other different disciplines and then creates its own.

And I think for me, that's the key word, right, is is I think data storytelling is becoming a discipline, you know, so we may end up talking about data analytics visualization and storytelling, right, as a fourth discipline, because at the moment I don't think it's yet seen as a discipline, but I think it may be coming that way. Cool. Yeah. Excellent, well that was the siren for, that was just the cargo bus with the siren. Hey look, thank you, thank you for your time. That's been pretty awesome. I know that the company you started, Rogue Penguin, you're kind of doing some really cool stuff. Do you want to kind of close out with just a little bit about what you guys— well, you or you guys— you or you guys though. Sorry, what you or you and others do?

Yes, so Rogue Penguin is 2 and a half years old now. Started off as offering a range of very broad services. And right through from graphic design to analytical modeling. And so it's kind of been narrowed down in the service offering based on what, what the need was. So data storytelling has come out as the one challenge I think that a lot of analytics teams have. And I'd like to work from the point that I don't want to do the work and then leave. I want to teach other people how to do this so they can carry on doing it. And it's not going to be something that everyone wants to do, but I think if you can get a team educated on the basics, then you're going to have those champions come out within a team. So what I'm finding is that if I go in and do training within a team, there are going to be a couple of people come out as data storytelling champions who are really, really interested in this kind of thing. And so then I work with those people on a mentoring one-on-one basis. And so half of the businesses get around workshops, and so I'm running them across New Zealand at the moment. And the other half will be me actually doing, being involved in those client projects and doing more data storytelling and visualization work as a service.

Excellent. And if someone wants to get hold of you after this podcast and have a chat, best way to get hold of you?

Pretty much get me on any social media channel or go straight through to the website roguepenguin.co.nz.

Cool. And once I do figure out how to put those contact details on the podcast when we publish them, I'll add those to the podcast so they're there. It's a backlog story for me at the moment that I haven't quite worked out yet, but not a priority yet until we do publish.

Excellent.

Hey, look, thanks for your time. It's been frickin' awesome. Good to catch up and—

Really nice to meet you.

Yeah, and we might get you back on in 6 months or a year's time when Gartner hype cycles his data stories, the thing, there's the—

Fingers crossed.

The cat book and the online training course and you're keynoting around the world and it becomes actually a discipline that everybody's doing as they should.

Hopefully.

Yeah, yeah, I hope so too. Excellent, thank you very much.

Thank you.

You've been listening to another podcast from Blair and Shane, where we discuss all things Agile BI. For more podcasts and resources, please go to agilebi.guru.