Join Shane and Blair as they chat to Sam Sewell on his experience adopting the AgileData way of working as part of building a new agile team.

Read along you will

PODCAST INTRO: Welcome to the “AgileData” podcast where we talk about the merging of agile and data ways of working in a simply magical way.

Shane Gibson: Excellent. Well, today, we've got Sam Sewell, who's come to join us to have a little chat about the thing we love to call the AgileBI way. Sam, welcome to the AgileBI weekly podcast.

Sam Sewell: Hi guys, glad to be here.

Shane Gibson: So I think probably the start off, maybe you could just tell us a little bit about your background and what you've been up to for the last 10 or 20 years?

Sam Sewell: Absolutely. So I've been mainly involved in the data BI reporting world for about 20 years. So it was my first actual office job was data entry. And from there I moved into, can I get a report on the data that I've entered, and somebody said, Hey, that's kind of BI, you're now a BI person. And I've kind of grown in that way. So I didn't study this at Uni, or anything. So for around 10, 20 years, I've been involved in this, and I don't think I knew I had a profession for probably the first 10 years. It probably wasn't until I met yourself, Shane, back a good long time ago, where I started realizing how much depth and how much knowledge and history and how much of a big industry and professional this was. And in the period of I've been working in this space, I think I've touched on a number of different areas of these disciplines. So I've had roles looking after platforms. I've been a consumer, I've been somebody who writes reports. I've worked with people do modeling, but not probably not smart enough to do it myself. I've managed teams across a lot of different technologies. So I do love what I do, and I'm always interested in where it's going.

Blair Tempero: That sounds great. It sounds very similar to my background actually, Sam and banking and dealing with data more and more and every role that I moved into, until I kind of realized that I was a data person. So when did you actually hear about this thing called AgileBI? And what was your first experience with it?

Sam Sewell: Well, AgileBI has been really recent for me. I mean, I only started hearing about agile about five years ago. So I've worked in banks, I've worked in some public sector, I've worked in energy sector. And I think that probably some of the leaders for agile in my understanding in Wellington, where we are where some of the tech companies who were embracing there was small enough and fluid enough to have a good go at making these new ways of working work and be effective. So my introduction to just agile itself is been very, very slow and gradual. And I'll be honest with you, I know most about it, because my partner worked at one of these tech firms, and she embraced it. And she learned about and she blogged about it. And she really introduced me to what an effective way of working it can be. And it's really being mindful about the way you work was one of the big benefits of Agile, it's working more deliberately. And then AgileBI was something I started hearing about with some of the people we've got in the market here some of the luminaries in this country, we're starting to think about applying agile and BI together. I encountered it myself a few years ago when I was put in a position to be working in an AgileBI team. But none of the people had necessarily been agile before or had thought about how you apply BI to agile and there was a lot of head scratching and a lot of challenges we knew we had to work through in that space. But we didn't have the answers. But luckily there are some people on the market and we're starting to come through with ways of meshing BI and agile together to make it work.

Shane Gibson: So when you were looking at that back in the early days, how much content could you find about how to actually apply agile in a data space?

Sam Sewell: Next to nothing. So it really, again, it's been in conversations with you where I've really come across someone who's put some proper thought into it and then a had an opportunity to work with him in the market in real life situations. Because there's lots of things on paper, on books, lots of people thinking about things, but you really need to connect with people who have done it in anger on programs on projects in real life situations.

Shane Gibson: So given that we've just been through a project where we've kind of are on a delivery where we were definitely doing it when anger. Tell us about your experience with some of the patterns we kind of worked on together and started implementing with the team there.

Sam Sewell: So overall, it goes back to me to two things. One, it's taking a new approach, because I think for most of the time I've been in BI, we've known this challenges about how BI programs and projects run, we know their delivery challenges, whether they're a scope challenges, we know these are some of the more difficult projects that you're working on in organizations. So having a new approach, having a new way to look at old problems was really exciting. I can gave you a chance, well, maybe this is the one because I've spent 20 years working BI projects where we've not always been as successful as we'd like to be. But maybe this is the paradigm shift at complete different way of thinking and looking at from so that been really exciting. And then because you're doing that, we go back to working deliberately, you're not just here's some problems, let's try and solve them. You're looking at approaches, you're looking at techniques, you're looking at tactics to approach the work to help you be successful. So the work we did recently, the way that the approaches, the patterns, the techniques, were able to connect with the teams who were going to be applying them, resonate with them, give them hope, that there you've got a good chance, because you don't want to start a program unless you really believe you've got a good chance of pulling it through. So to be able to put that into people to be able to bring them on the journey to say we're going to do this, and we're going to do this. And this is how we're going to do it. And this is why we're doing these those techniques, I found was a really good way of doing it. And the approaches, the patterns, the techniques that we were implementing all seem really solid, they all had good background behind them. They were all there to fix specific challenges that we've all seen before in the past.

Blair Tempero: So the business, the product owners that you brought along on the journey with you, what was their reaction with an experience with this previously, or was this all new to them? And how did they come along with you on the journey?

Sam Sewell: So a lot of this is new to a lot of people. And in programs, you'll often have people come on who aren't necessarily bi or data people background. So it worked well, because all the tendrils start coming together, this is what we're doing. This is why we're doing it, this is how we're going to do it. So we found with the techniques, it was relatively straightforward to bring people on the journey for how we're going to do it and why we're going to do it. Because often people are looking for someone with an approach with a vision. And this is all part of a vision and approach and the technique, it doesn't have many or any sort of gaps in what you're doing. You can see a path, you can see the way that you run the workshops, you can see the way that you listen and capture the information, why you capture that information, a requirements document, an old waterfall requirements documents got lots in it. I don't know if there's, it's always simple to justify why you're putting all those bits of information while you're gathering that putting it in a big document. It's not all going to be needed. But this approach was everything had its purpose, I need to ask you this question, so that I can make this decision and do this piece of design.

Blair Tempero: Sounds great.

Shane Gibson: So with the team, you're working with you, you started tailoring the patterns or the processes. So you kind of started forming different ways of working by using those techniques and ways that I hadn't seen before. You want to tell us about some of the things that you saw the team kind of do as part of them?

Sam Sewell: So we found that we would take the ways of working and we had to allow the incumbent team members, the people who worked at that organization, an opportunity to take ownership of those ways of working and invest in them so that they became their own way of working. And when you do that it allows them also to do some tailoring to put it into the vernacular of the organization, and help them sell it within your organization. So you take this great way of working, and then you put your own organization's branding, ways of thinking, ways of working on top of it. So it's still very much the same underneath, it's still very much the same approach, series of technique, patterns and processes, but it's branded for that organization for that team. And then you allow the people in the team to make small changes and edits, keeping consistent with the philosophy of it, but in such a way that enables them to sell it, and push it and go out there. And it really has taken off in the organization. The terminology is the labels for the information products, and the labels for the type of workshop and why they have them are being adopted at all levels of the organization, because it makes sense to everybody, and it resonates with them. So it was a very, very simple set of techniques to apply even to a very large organization.

Blair Tempero: Yeah, so it's kind of a best fit for the organization. Not this is the agile Manifesto. And we're going to follow this to the letter. And we found that in my organization as well, that if you just tailor it a little bit to get a few people across the line, then it's worth it definitely.

Sam Sewell: Well, the challenge is by so you can have the most amazing approach. And I've seen agile applied in organizations where it hasn't landed because the people around it changes the hardest thing in the world, in organizations change the way you're thinking, working, come to an acceptance that the way you do your job today is not necessarily the most effective way of doing it. Not everybody is open to that time and change. In all organizations, you get people who are career people in the field, but you also get people who are there because it's their day job. And they're not necessarily students of what they do for a living. So you've got to be able to excite everybody in the team and have everybody on the team on the journey. But you do need to keep the philosophy, you need to keep the why, why do we have this way of working? How do we structure our conversations to capture the why the whole time? The same, but you can change sort of the colors and some of the looks in the fields of the thing. But it's the philosophy, that's key.

Shane Gibson: So on there, I mean, often what we find is, especially when we're working with organizations where agile is new, there's a vision, the desire to behave differently to work in a different way. And teams of people are normally then mandated or seconded or encouraged or dictated to work in this new way. And for some people, it's really uncomfortable, but they make that change. And for some other people, it's really uncomfortable, and they don't make that change. Did you find that given that a team kind of went on this journey, that there were people amongst the team who opted out? And how did you deal with that?

Sam Sewell: Yeah. So we found that actually a higher percentage of people were able to pick it up and adopt it than I was expecting. And because it does speak for itself, we're not trying to sell fairy dust and magic we are. As someone says, magic doesn't happen here. I can't remember who said that someone I know says that on a regular basis, but you're selling something, that's got good reasoning behind it. So a small number of people really struggle but that's an organizational challenge, I guess. Often I found the people that aren't as open to picking up new ways of working will find a role for themselves to still be effective in their role. I've never found that I've been able to get 100% sort of change everybody on board. And you don't want to go in and necessarily change the people in your organization. But I do believe there is a pot for every lead, as it were so the people that are not able to embrace it, I think it's more of a time and an exposure thing. But in our world, there's always work that that needs to be done. So it's about harnessing the energy of those who are excited by the change, and hope that over time they bring everyone on the journey in a show don't tell way. So there may be skeptics, but you can. If you do things really well, you will bring people on the journey, that's my hope.

Blair Tempero: Yeah. So we've found that the retrospectives actually expose people's lack of buy in and we've used retrospectives to try and change things to fit everyone into the way of working and get everyone feeling comfortable and having those tough conversations as a after your time box period is finished, and you're looking at improving the next one. So have you used retrospectives and in your workplace and how have they gone down?

Sam Sewell: Yeah, we absolutely have, I think we probably could have run more. And retros, I think one of the ceremonies in the agile world that that can be run in very different ways and have very different feeling around them. And I'd my partner, I think bought a series of flashcards to run retros that gave you lots of different ways to phrase the conversations and get people to interact. So I think the retros take a little while to get going to be effective. And I'm not sure I've seen them reach that stage yet. Where I'm currently am. I think they exist for a very good reason. And it's part of the change to get people to that openness and that honesty, to work together to not to blame, to not to point fingers, but to collaboratively work on better ways of working moving forward.

Shane Gibson: Yeah, so I think we've retros it's interesting, from my point of view. Retros tend to come out of using Scrum. But they seem to also have the most available list of games in the marketplace. Till make it richer is fun. There's lots and lots of places you can go to find awesome games for retros, not so much for backlog grooming, story mapping, or any of those other things come a little bit more boring. But flashcards and different retro games is kind of exciting. So obviously, we'll both partner, what you did is, you've come along on a journey with their current process or project that you're working through, what would you say is the hardest part that you hardest thing you've encountered, kind of introducing agile ways of working into an organization that is going through massive transformation, and is probably going on at the beginning of their agile journey as a business versus, the difficulty of moving to an agile delivery method?

Sam Sewell: So I think if the organization was already there for Agile, if I were to work at one of these tech companies that's been doing agile for over a decade, and everyone in the organizations bought in, I'd say the most difficult thing would be transitioning the team and getting them to embrace the new ways of working. But when you're actually part of the Vanguard into agile ways of working in your organization, you not only have to change the way the team work, the way your stakeholders work, but also really the way the enterprise operates, the way it thinks about funding and deadlines and imbalancing organizational change. So for me, the most difficult thing probably is that that wider the senior stakeholder management of setting expectations, or finding space to learn and grow and move while still being able to sort of consistently and constantly deliver to the organizational needs. So that's always been a problem. But it's also fighting the temptation for me to just go, oh okay, fine, I'll just get a whole load of old school developers, and we'll just put them in a room. And we'll just, because this is really important, so we'll do this bit waterfall just to get it done. So having to fight myself a lot to sort of hold my line, hold my course, to push the change through.

Shane Gibson: Yeah, and I found the same thing as I change, as I move across organizations, and I start moving into a new organization to help coach them or their teams. It took me a while to realize that at the beginning, I was focused on agile delivery, I was focused on the team and how the team works and giving the team up to be self-organizing and responsible and self-aware and optimizing themselves and bringing their change their team. But actually, there were two things around there that were just as important as agile delivery, there was business agility. So the number of times you work with an organization that talks about a project with a funding for a window, heaven forbid, project manager or program manager and a Gantt chart that sits above an agile way of working. So it's the ability for the organization to become agile and change the way it operates. And then the second part was kind of the after the agile team has delivered is getting everything into to front of the user. So automating the deployment, automating the operations, stopping the problem of as the team delivered more and more. They were often held responsible for maintaining it. And that wasn't automated. So he saw by the drain right, we saw the team's velocity for new stuff kind of die as the BAU, bleed I call it happened. So for me, it's we focused on agile delivery to begin with, because that's the problem we wanted to solve, that now, actually, it's realizing that business agility and automation of the delivery, and ongoing management of is just as important. I mean, you've probably found that as well player in terms of going from the early days where the teams were just rocking it to, now you've got stuff to maintain, because it's the same team.

Blair Tempero: Absolutely, yes. And you've got to balance it with the news, and shiny stuff we've found. And the product owners haven't, I've found an hour, an hour set up, they haven't let go of the product. So they still feel a sense of ownership, because they went through the whole thing with you and, and some of their some of the refinements we've had to squeeze into building new stuff. And it's just that whole squeeze. But the thing I've noticed is that ownership aspect that they don't just go with you on the journey, and then just go, boom, thanks for coming. Let me built this great thing,

Shane Gibson: That's great as well. Because now you've got somebody who actually owns the product. Somebody's gonna fight for adding to it, it's not going to sit on the shelf, we used to buy enterprise software. You go and buy it, sit on the shelf, you come back a year later, and nobody used it was like, wow, that was a thing. You've got that adoption problem. As you get more and more product owners, they want more and more done. And you've maxed your velocity. How do you scale? And what do you prioritize? And actually on there, so one of the things for me was the number of information products that you actually defined upfront as part of your roadmap, and the fact that because of the type of work you were working on, you had multiple product owners, each with a relatively heavy list of information products to be delivered. How did you manage the prioritization across that nightmare?

Sam Sewell: Yeah, it's difficult. So to your point, a few seconds ago, I played some. I don't think we've reached that crunch point where you're trying to balance the delivery with the support. And I think that's a challenge, and now I've got coming up, which I'm excited about tackling with the IP. So we've gathered a good few 100 IP’s. And there was a real burst of excitement initially with the IP’s because again, you're giving the business a good vernacular, one of the ways that I describe these BI way, the agile ways of working is it's a common language between the three groups that you're working with, between the people in the business who want the outcome, the analysts who are there to facilitate that outcome, and the people in the information or data teams, who are the custodians and prepares that information. It gives all of those three groups a way of speaking to each other that makes sense to everybody, which I hadn't seen before. You're always talking different languages. This gave it a conformed language that everybody understood. So there was huge excitement around the IP’s. Everybody wanted an IP, everybody wanted a workshop. Everybody wanted a session, and we flood in lots of these. One of the challenges was probably consistency and quality. Because it was so exciting to go out and run as many workshops as you could is how do you ensure ongoing that you're working in a consistent way, which is part of why you have the workshops is to work consistently, but you can still have different people interpreting in different ways. So that was one of our challenge. Prioritization, I think along with a lot of agile ways of working, we have to really road tested to see if it is successful. Transparency and visibility are one of the keys that we've been trying to work on. So the whole enterprise can understand what is on the backlog, and can understand the importance of everything on the backlog. And then it's finding the right group of stakeholders at the right level in the organization who can collaboratively work together to balance that priority. But that's still a work in progress for us. We definitely mindful of it. We're definitely getting the conversation rolling around the organization and within the governance groups to let people know that they need to be aware, this is working. We have our backlog. We have it in an agile tool in JIRA. So it is very accessible. We keep it up to date, but how that journey is gonna go over the next year for how we work through that. I think that's something I'll come back and tell you.

Shane Gibson: And I think things are that you did that I really liked was you've got your backlog or JIRA. You've got boards and then that's visible. But in my opinion, JIRA is not the easiest product to look at and understand. So one of the things I really liked was he almost took an infographic approach to creating some really high level infographics around the IP’s, the backlog ways or lenses of looking at it to say, maybe by kind of event or by subject area or by you put some lenses on there that explained the different ways the backlog could be viewed. How do you find that in terms of that if it actually come up with value that the stakeholders actually look at it and understand a little bit more how big the elephant was the different ways they could prioritize? What was first and what was second?

Sam Sewell: Yeah, absolutely. It's something I try, and applying whenever I'm working with BI teams is to use BI. We are the BI people. So we should be using our own techniques and tools internally BI on BI. So creating the infographics been able to pictorially demonstrate if we do ‘A’ that unlocked ‘B’ which unlocked ‘C’, ‘D’ and ‘E’, and put it in colors, patterns, shapes, that are accessible to everybody that people can put in their hands, as much as we're digital people still want things in their hands in their book that they can open and say, well, this is where we are, this is what we're working on. So being able to give people pictorial aids that show the different lenses, as he said around subject area around if we want unlock other things, because at the start of a warehousing project, you have nothing, and you can't get right down to your nuanced products until you've done all the foundational work to show how all of that stacks up and adds up to grow something that's greater than all the component pieces in a way that resonates with people we found really effective. So if we hadn't done that, life would be a lot more difficult for us. It's been a really good sales tool for the team, what they're doing.

Shane Gibson: So for me, when I do my personal retrospective around the AgileBI way, one of the patterns that we kind of came up with during that process, and it comes back to your comment around scaling the facilitation of the information products as people kind of do it the first time and you get more than one or two people kind of running out and trying to scale that facilitation. , the quality of what they capture becomes slightly variable. And I think in hindsight, it wasn't till we went into the sizing workshops for each of the IP, where we actually sat down together with the team and actually talk through each of the information products that really the gaps started to become visible. And the people that are gathered them realized, where the focus should have been, because they knew actually got more of an insight into the outcome. And so for me, the extending that patent out to, if we're bringing new teams on go, show them how to do the IP facilitation, work through the first couple with them, let them go out on their own but very quickly bring it back to a sizing workshop. Because by talking through it, and people who weren't involved in the facilitation, actually be able to ask those questions that I think helped refine the process for the people that win and gather that and make them better. So if you look at it from their point of view what’s the next piece of work you're going to do when you're going to bring the AgileBI Way to another team, what do you recommend the one thing you'll probably focus on improving next will be? Where's the gap? Where's the thing you're gonna bring to the world as what are the patents that the rest of the AgileBI Way? We got to call them can now leverage?

Blair Tempero: That's a good question.

Shane Gibson: And not one that we wrote down, you’re on the spot.

Blair Tempero: It's a sort of thing.

Sam Sewell: Bribery and threats. I think it's something I like to utilize more in the workplace. But I think very much a show don't tell very early on, I think is going to be maybe an approach to take. So as soon as you've got enough arms and legs and heads in a room that you can actually run through these techniques, and get people access to a system where they can put them to practice. I think being able to create a really transparent use case where you can say this is what we did on this day. This is what we got, look at what we can do. Because a lot of experience in the BI way was selling the value of it. And a lot of people grabbing onto that really understand doing it. But for the wider organization, it wasn't visible, it wasn't transparent. So being able to actually do an early proof of concept, to go all the way through and prove to the doubters around you and get people on board, I think is what I'd like to do, because we tried to do that where we are, but I think probably could have pushed to do something faster earlier.           

Shane Gibson: But using this, because although the organization said they wanted to be Agile, they really weren't business Agile. And so there was an outcome, there was a number of information products or dashboards or reports or datasets or API. There are a whole lot of things that needed to be delivered. And it's just the fact that you and the team decided you want to take an AgileBI approach to deliver them in a better way. Therefore, actually, a lot of your time was selling to the organization, why this approach is actually valuable? Why you're investing in these teams doing things slightly differently? Do you think that's kind of why that was the focus area for you next?

Sam Sewell: Certainly, yeah. I mean, a lot of energy goes into that sales work. So if you could almost deliver two different ways at once early on to make it really clearly articulate the value of the ways of working. But that overhead of selling the techniques to sort of the stakeholders was where a lot of the energy goes, if you can get someone to do that work for you, so that you and the team can just plow through the work.

Blair Tempero: We've found that as well with the concept of MVP in front of stakeholders early on, gives them something that they can report back to their managers and potentially becoming a thing is quite exciting. And I think they'll be working on the MVP a lot closer next time too.

Sam Sewell: So we've talked about MVP, IP. And that was one thing I saw at Saito was that previously where they were able to, to get one number one number all the way through, and they weren't using a true AgileBI way of working, they were doing traditional BI and trying to apply agile principles to it. But they were able to take one number all the way through and put it on a dashboard. That was a dashboard of nothing except one number. But they were able to get that number through in one sprint.

Shane Gibson: And we always say, , vertical slice, thin slice all the way through, if you can, is what we should do, sometimes 401 reasons, it's not normal approach we can take asleep, but if you can slice it all the way through. And the other one, I think picking up on your point, we talked about being ad hoc, we talked about doing Agile, and we talked about being Agile, but it's a journey. I would rather have hear the words, we weren't really being Agile, if we came in and somebody audited us of our behaviors and the way we're working, we're not going to come through with the retrospective would have lots of things we could do better. But we're starting that change, we're starting to adopt those behaviors, and we're seeing the benefit of it. And then reinvesting and improving the way we work, to me is still better than saying it's been six months out front planning have been Gearson hope, like, that in two years’ time, we had was right and nothing changed in between, because we all know, that doesn't work. And especially in the world of data and analytics is moving so fast, business is changing so fast, so we know what's going to happen.

Sam Sewell: Yeah.

Shane Gibson: Excellent. Well, thank you very much, Sam. It's great to catch up again.

Sam Sewell: Thanks Shane, let’s make it.

Blair Tempero: Thank you very much for having me.

Shane Gibson: And we'll catch you soon.

Sam Sewell: Thanks guys.

Blair Tempero: Alright, cheers.

PODCAST OUTRO: Data magicians was another AgileData podcast. If you'd like to learn more on applying an agile way of working to your data and analytics, head over to agiledata.io.