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 Temporo.

Hi, I'm Cat Greenbrook.

Hey, Kat, welcome. Thanks for taking the time to join us today. I suppose what really piqued my interest was this idea of data storytelling.

So.

So 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 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 Rogue Penguin.

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

We've had back to 20 years, so whatever you think is 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 centre because that was the only role that I could get with a science degree and worked my way very flukingly into analytics roles. And so my journey in this whole data space just kind of went from there by accident almost. So I've done a lot of different analytics roles, 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, they were still better than anything I can do today.

We learn, don't we?

Yep, we 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 that combination of storytelling and data. So I remember when we were kids, I used to read comics 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. 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.

How do you find that with data storytelling? How do you find that in this modern agile world where we get taught that? I can grab a bit of 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. And it is the time. The longer the 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 got to put in the time. And I actually, I was having a chat to someone earlier last week, I think it was, and she had, she said something and it really left me feeling like, oh, yeah, 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 will 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 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 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 would 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 take it to pieces because they haven't been involved.

That's what waterfall does, right? 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, 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, 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 people are scared of. I think around data storytelling, is it how you are? 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 thing 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'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 two years. Have you got an example, I'm putting you on 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. So you're, 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, 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. And so the point of data stories is help to communicate insight 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.

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 a problem. So you have something and something else happens and something else, and it goes. 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 summed it all up and 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.

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. Because the data never speaks for itself.

No. Well, it probably speaks in many different tongues. Right.

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

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 spider web type.

I love those neural net network graphs.

Yeah, that's my standard storytelling.

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 that's visualized, I can verbally tell multiple stories. I can say, hey, look, this is what's happened, but I have to be there to verbalize it. As soon as it's on its own, you're overwhelmed. Right. There's too much. You don't know what to focus on. You can tell yourself your own story.

But lots of different narratives that you can tell from one visualization.

Yeah, so that's a good point.

Yeah.

So we're sort of moving towards the clique stories, you know, using the part of clique 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 there's some 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 click for public, we're going to be building a roadmap so that we can start putting a bit more effort into user experience and the storytelling to 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 because 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.

It's gonna make it easier.

Yeah, yeah, yeah, hopefully.

Or worse. Because you'll bring back some visualizations where you could tell four or five stories with that one visualization. You know, you're not gonna come back with a visualization. That's one number. 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 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 a if then else. But it could be that actually I'm going to read it and go, yeah, that was overwhelming. 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.

Shane's retros.

Retro and process. Be ready. Toad off. You mean encouraged to review what you're doing in ways you could have.

Yeah, but told off is easier to say.

It's so unediled 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, 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. Was it Teach Coach do. So anyway, so the thing, 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? I mean it's going to be a mix, but what kind of standard audience at the moment?

Definitely a mix. I've had a lot of different people right 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, 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?

It 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 something along 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 thin slice, which one we're gonna 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 crush 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 three 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 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 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. 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 communicate it 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, yeah, therefore. 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 analytical model that's going to do cross sell. And why are we doing this? Well, the action we want to take is offer a person something else and hope they buy it. 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.

The way you talk about storytelling, the therefore seems to me to be. I'm inferring at the moment that it's an action. So 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? 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 have to look on my website.

Well, 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 Agile BI podcast.

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

Well, that's, I guess, an inaction. But you therefore could back up your hypothesis at the beginning, you can say so. So therefore we were right now thinking that the data backs is up.

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, that's what I'm hearing.

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

Oh really? Yeah, tell me about that.

So if a lot of the time when you're designing something, as you said before, you want to design it for everybody, but, 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 where you actually know quite well, then we're just focusing on that data storytelling. So I'm stuck with user story land as I want. So that. And typically because most of data BI analysis teams I work with, we get down to a relatively technical user stories by natural. Have you got an example of what a user story would be for you 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 brainstorming exercise And a lot of the time the groups are quite big. And so what I like to do, if we have 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 have quite different user stories for them. 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 get people to change what they do 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 realising what motivates people. And they 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 can't use the word climate change for the people that don't believe in climate change. 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 somebody's experimented with doing stand ups on a daily basis, haven't changed any of their other behavior and therefore 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. 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 was actually could then write the do the analytical 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 repeatably. What I've seen is actually we end up with teams of three, 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 make the data available for testing the hypothesis and the testing of the hypothesis. But I don't often see the storytelling 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 because I don't.

See it on the Gartner. Oh, I have to check. I don't see it on the Gartner hype cycle.

Well, it was listed as something that teams should train or educate more around the data storytelling field. 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 up 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 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. I'd say that you wouldn't need words to back it up.

Well, that's. I would still call that an exploratory database, but 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.

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. 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 are we 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 to suck eggs, or making something incredibly complex where there's no way. I mean, Helia had a really interesting one. She's making senses for houses that monitor.

Carbon dioxide. Humidity and that for healthy homes. And she talked about as 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. I think, 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, 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. Yep. Cool. So data storytelling in New Zealand, apart from yourself, how many other people would you say, teachers or coaches or experts in this domain? In the whole of New Zealand.

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 Cole Netflix, 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 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.

Oh, It's a thing.

101.

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 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. 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 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.

So we may end up talking about data analytics, visualization and storytelling 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 a siren for. That was just a car going past. 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 us a little bit? About what you guys. Well, you or you guys. Sorry, what you or you and others.

Do.

Yes. So Rogue Penguin is two 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. So it's kind of been.

Narrowed down in the service offering based on 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 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. 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 ahold of you after this podcast and have.

A chat, best way to get ahold 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. We might get you back on in six months or a year's time when Gartner Hype Cycle sees 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, 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.

Sam.