[00:00:00] Dan: Hello, and welcome back to we, not me, the podcast where we explore, how humans connect to get stuff done together. I'm Dan Hammond.

[00:00:13] Pia: and I am purely well, Mr. Hammond, we have an episode today that is very close to your heart. We're going to focus about agile teams and talk to Nat pieces from nap. Now what let's explore, a little bit with you. Come on, open up. Why is this subject? So close to your heart. 

[00:00:33] Dan: So, um, in the mid nineties, obviously when I was incredibly young chap, um, 

[00:00:40] Pia: you six? 

[00:00:41] Dan: six. Exactly, I was, um, working, working in the U S um, in a big pharma company and we were. It was pretty advanced actually, cause we were already working in cross-functional teams. So I was leading a team. it was in medical devices and I was leading a team with some amazing engineers, regulatory people, all kinds of, you know, really across the business.

[00:01:00] And we were delivering a product, designing and delivering, a new implant actually. And so it's complicated because. The thing about this was though I spent most of my time leading that project staring at Microsoft project, the project planner, making a big Gantt chart with all the tasks that had to be done over a six, nine month. R and D cycle and trying to make all the dependencies work. So once we've done that, then we can do that or to do that. We need to have done that. And literally I spent most of my time on that project trying to make that, keep that right. Which is just not time well spent. And if we'd had agile at the time, I honestly think pier we'd have moved.

[00:01:44] I'd have spent it, wouldn't have spent that time. We'd have just done things, being much more task focused, got really into it And we'd have executed far more quickly. So when I discovered agile years later, it was a real faceplant, um, whatever, part of face palm, face Palm, to sort of say, ah, All that wasted time. So I'm really excited to hear from that about how this is. This can be done in a large organization like that. 

[00:02:07] Pia: And I doubt Dan, you are on your own. I think there's a lot of us that have spent a lot of time on Gantt charts, excel spreadsheets, a Microsoft project. So yeah let's listen to Nat. Who's going to really explain to us what it is and how the value it is inside organizations today. 

[00:02:28] Hi, not it is so good to have you on the show today. Welcome. 

[00:02:32] Natalie: Hi, Pia. Hi Dan. It's an absolute pleasure to be with you. And thanks so much for asking 

[00:02:37] Pia: Oh, we are delighted. Just tell us a little bit about yourself. Give us a little bit of your agile resume 

[00:02:43] Natalie: Sure. I'm probably not your traditional agile person given I've spent about 20 years of my career, very early on in HR roles. And it was probably at about that 20 year mark. I've got the 20 years each and thought, surely there's something else I can do with my. And this ways of working world started opening up to me.

[00:03:06] And I jumped on board that when I was at Telstra and then started to explore the world of bad job, all things, agile, human centered design lane, all of these methods, and I've spent in and around the last, nearly six years Doing that kind of work in organizations here. I did a little bit of it in London and I'm back here again with NAB leading a transformation for the bank. 

[00:03:30] Dan: Brilliant. And let's dive straight into this because agile is a word that is misused and maligned, I would say. So can you start with some definitions? What do you know? What are we talking about here? What is it?

[00:03:41] Natalie: Oh, I love this and I'll start with what it's not. 

[00:03:45] So when someone comes late to a meeting and says, oh, I'm really agile 

[00:03:49] because I'm a bit late and I'm going to 

[00:03:51] Pia: do star jumps and twists or things like that. Is that why they do that? Yeah. 

[00:03:55] Natalie: Exactly. Yeah.

[00:03:56] He's a Cartwheel. I'm really agile. It's not that that is not our job or Hey, look at what I did with my office.

[00:04:03] I've put hoops of beanbags in it. I'm agile. It's it's actually traditionally method of working that applied mostly to software development and to project work and. A lot of people working in technology would really understand this method very well. And it's a method now that's being expanded into organizations as a way to more modernize or change the way people work.

[00:04:28] And one of the big myths I want to bust around agile is that it is in fact quite loose and it is ambiguous. It's actually the most. Measurable and tog driven way of working. I've seen in an organization in all my years, working in many organizations and many industries. Yeah it's definitely not loose or late as some 

[00:04:49] Pia: W. And so I'm wondering if I'm listening to this, if you're not agile, what's the other world, what's that called? And how does that work in as opposed to not being agile,

[00:04:59] Natalie: It depends on how much the method expands in your organization. But if you relate it to projects by and large, you'd say the way that most organizations work is through a waterfall method. So it's a, top-down, there's a very traditional way. Running a project full of Gantt charts and Excel spreadsheets and timelines and deliverables. And agile, in fact is a method that applies by and large to projects, although it can expand to run parts of the organization, but it's made up of. cross-functional teams, mostly of technology and business people, delivering outcomes for customers. So it's a little bit different. It's probably a bit flatter and runs in a completely different cadence.

[00:05:41] So rather than having a very traditional. Attended by executives. One of the great principles of agile is that executives have to come to the work. So they'd go and visit the teams themselves and see their ceremonies, their sprint plans, their retrospectives, and they engage with the teams as opposed to hi, I'm a big leader. I have a big, important job. You've got to come and bring your PowerPoint pack to me and present to me on your project and all your milestones and how you're spending the money. a job pools, leaders more to the teams, which I think is a wonderful. again, more modern way of thinking about how organizations.

[00:06:21] Dan: That is wonderful. And we may revisit that later now, but I'm wondering if you could just, could you T you mentioned teams. That's what we're all about here on we, not B could you take us into one of those teams? What's that experience like you mentioned ceremonies. What, w what's it like being in a team that's operating in an agile environment?

[00:06:38] Natalie: it will take different forms in different companies, depending on their application of which agile methods they use, because it's not a one size fits all is the first thing that I would say so we can subscribe to various. Methods. The one that I've mostly used is scrum, And that takes a different form of what a squad looks like. But mostly it's about 10 people that sit in a squad or a two. It's pretty flat in the organization. So I like to keep my squads no more than three layers in total. And what I mean by that is there's an executive, there's a leader that sits on top and then there's the squad or the team itself, so that you're not too far.

[00:07:19] Again, from having executive engagement and you're also really close to the customer really importantly. So those teams have to be very in close proximity to the distribution or front end of the business. And then in that squat itself is a beautiful collection of really capable people driving a business outcome or a mission.

[00:07:39] However you want to describe that. So you'll have some pretty key roles in there, like a product. Who helps refine the backlog and helps the team move through the work. But you've got a whole cross section of experts. Again, most of our modern work that we think about for customers is very digital or has a, a development software development orientation to it.

[00:08:00] So about 70% of the squads that. So to work through the design process or technology resources that could be architects or developers, and then the rest could be marketing, pricing, product management, people who come together to deliver on that new customer product or proposition into the market.

[00:08:18] Pia: And when you've got, so you talked about having these experts. And something we've talked about it. I think Owen Finnegan talked about it. Do you have a team of champions or a champion team? How'd you harmonize them together? So how do you bring them together? All this level of expertise are being a master in specific things? but 

[00:08:35] Natalie: Yeah, I've thought about this a lot. And I see it in action and the best teams, the best, most successful teams are really low ego. So I think you can have a team of champions as long as their egos kind of checked at the beginning of the sprint or when they get in the team. When you're in this kind of way of working, you are connected with a whole bunch of ceremonies. So it doesn't matter whether you're paid $200,000 a year or $50,000 a year, you're equal in the squad. You are just as valuable and just as important because you have a contribution to make. This whole. Oh, you're from the technology team or you're from the business. And you're a bit this, and you're a bit that I've heard that everywhere I go. In the squad, they are beautifully connected on a common goal and a purpose, which is great. So I think all of those they go in the baggage of way you come from and where you've been and what you're paid, the ambition with that squad is that it's it, everyone is valued, everyone's contribution is equal. 

[00:09:38] And then when you're setting up your sprint, which is normally a two week package of work that you're delivering to get to the ultimate mission, your all us for exactly what the work is that you're going to do over that period to contribute to the goal. Again, if I've got 20 years experience or five years experience, it really doesn't matter because I still have to deliver those outcomes and service of what the team's trying to do. And you can see the power of the collective. Whereas perhaps sitting in your normal silo in an organization, you don't see that you don't really see the value of what you do to drive the outcome. And so I think over time you could see yourself as a champion, but you get into this squad or this team in your flat, in the S in the hierarchy, and you're all really accountable.

[00:10:25] And I give you feedback, whether I think you have some fancy title or not, you are just as accountable. I don't know. I think that you're actually a champion team. You might not start that way, but the cadence and the rhythm of agile will get you to a place where you're a champion team.

[00:10:40] Dan: you mentioned sprints. Can you talk about how those, how they work in teams and why they're better than just normal project management?

[00:10:48] Natalie: What I like about them is the decomposition of work in agile is pretty clear. So you'd go from. I think we've probably all worked in organizations where you see a company strategy and you say that's really great. And maybe at some point they all look a little bit the same, but you're saying, okay, That's the longterm vision, how do I break that down into what I do every single day? And the decomposition of work in agile is pretty clear. So you take the strategy and what we do at NAB is take that into a business outcome. And these are the outcomes that are going to be driven by this particular part of the business to deliver that strategy. We have a whole lot of checks in place that we put in place to make sure it's actually going to execute on the outcome. Then you break that outcome into what we call an epic. 

[00:11:27] So the business outcomes, normally one to three years depending, and we put the investment In the same time horizon so that the business leader knows they've got funding for that period as well. But normally it's about a 12 month container, the business outcome. And then we break that into what we call epics. So we time box them into three month cycles. So we say every three months, we're going to deliver some. Shippable product. We would describe it to deliver that business outcome, ultimately to achieve that goal.

[00:11:55] And then that epic is broken into features and then stories. So they become smaller containers of work. So a feature might be anywhere from four weeks to 12 weeks to get to that epic. And then the stories again is another layer. The story level is very much for me as an individual and that forms part of the sprint plan. So that effectively a sprint is, ah, okay, we're going to achieve this three month epic. We're going to break that down into two week sprints and every two weeks, these are the stories we're going to deliver and I'm going to deliver it. If I'm in marketing, I'm going to deliver these eight stories. If that's, what is I'm accountable for in these two weeks, that's going to get me to the ultimate outcome.

[00:12:37] So what's different about that. It's not a project manager. Who's doing that and saying, these are the tasks that you will deliver in this time to achieve this goal. And we've all seen varying degrees of success. Some of those project managers really deliver well, but some of those can go there's delays and there's all those unexpected factors that can put constraints into the project because it needs a bottom up view as well. Having the squad do it. You actually get a more accurate view. Now, of course, we always have delays in, in delivering in agile, but you're constantly iterating and refining and getting better at being able to put a time box around your work, but that's effectively how it works.

[00:13:18] Pia: I'm just thinking if, if somebody is listening to this and hasn't applied agile. They'd be feeling a bit bamboozled possibly because the language is initially one. So my question is, what do you notice about teams that transitioned from a traditional way of working, you talked about waterfall top-down and then they say we're going agile. What do you notice about that that journey, I think it's bridges. The change, man, William Bridges said, you know, organizations change and people transition. And generally that's got a bit of a bad loop to it. So what have you seen how you're trying to help people move towards this very different way of working?

[00:13:57] Natalie: This is a really fascinating question, because if you know agile, you will have a little bit of anxiety about going into the model because. Oh, wow. I'm really going to be accountable. We talk so much about empowering teams. You actually do empower teams when you implement an agile model, because you are pushing the decision rights down into the team.

[00:14:21] Some people are terrified by that because there's some safety in being able to put blame somewhere else or for things working a certain way. And the dysfunction in an organization becomes very normal and safe in some way, albeit frustrating. So people that know agile normally feel a bit of anxiety about it. And people who are just crying to deliver outcomes and cut through all the complexity and simplify things and drive good outcomes and do good work, they love it as well. So the people who are ready seem to love it. The people who don't know anything about it seem to love it. And the people who know something about it and are a bit cautious and not quite sure, there's a path that they have to go on to, to really adjust to the way of working? 

[00:15:09] Pia: Dan, I don't know whether you remember this, we brought agile to. LIW. And we were both working in there, which is a professional service business, and that wasn't necessarily your archetypal type of business for that. And I'll never forget, round the Kanban. So, you know, You're putting this sort of like diagram where you could you can monitor your flow of work.

[00:15:28] And I remember the team gathered round it and everyone started crying. I thought this was going really well. This is fantastic. So there was just that, just that emotional and what it was, which I think is an interesting psychological thing. People had work that they held to themselves so there's suddenly felt out of control and a little bit exposed. 

[00:15:50] Natalie: Yes. And it's a great point because again, I think one of the wonderful ways that agile impacts an organization is that peer to peer for. So it's very transparent what everybody's working on, and if I'm not delivering P a, you should be saying to me that, where are you at this last sprint you were off? And you've only delivered two days of work out of this 10 day sprint, what was going on for you? And what do we need to do as a team to plan this better for you next time? And we've had to share the load and now we're. 

[00:16:24] All of those things become much more transparent and your, again, as an individual accountable for that. So it can be terrifying, but what, when you're in it, it's like everything once you're in it, and I really believe in people learning through doing, I think as much as you can put people into a classroom and say, this is agile, this is a product owner. This is an agile coach, and this is a sprint you learn when you're in it.

[00:16:49] And the way I've seen leaders transform is. Again, trying to do leadership, boot camps and leadership training. And all of these things are really important inputs. But when you get into the work, that's when you need to train them. 

[00:17:03] Two months in, when they're terrified saying, I don't even know what I do anymore, I'm telling these people what to do, and they're telling me to go away that they've got the plan. And so I'm just, what do I do now? Purpose. What's my role? That's when you know they need that, that nurturing and that support. I think it can be, it's quite a process to actually go through all of that change and really make the shift. But I think that happens in iterations actually. And I. It's like any change. It's a massive rollercoaster. It's filled with Tara and joy and pride and tea is it's an old change in life and it's no different in organizations. It's not, it's no different doing something like this.

[00:17:47] Dan: Now, when you were talking through that example of something is not done and that, our experience of certainly my experience of agile is that's very transparent execution. This is my task for this time. And it was not done actually, peer we were on a team yesterday and there's something I hadn't done. It was really clear that, that, that had 

[00:18:03] Pia: You didn't 

[00:18:04] Dan: How do you, I didn't cry. Not after the meeting, I had a little I had a little cry, but The there's a danger then potentially is there that you become very actually task-focused and you don't ask the question as you did what was happening for you. There's a piece that, how do you balance the sort of discipline with the understanding of. What conditions did that person have that meant that they didn't deliver. I'm not making excuses my task, there are all kinds of things that might have affected that. How do you balance those two in an organization?

[00:18:36] Natalie: I think that's that's where the mindset element of all of this and the cultural element of what you're trying to change in the organization comes into play. Because When we think about agile, the safe place to go is to the method, right? The method gives you safety because you can follow. If you like to do this, a rule book that just lays out the method, but the mindset element is massive in all of that.

[00:19:01] I think that takes a lot of nurturing actually, and a lot of care over time to create that safe place where people can have that conversation together. And it's without judgment and again, in service of the outcome, not to penalize the individual necessarily. Albeit you still want a bit of performance age, but it's where the agile roles is really important.

[00:19:21] Where I've seen agile succeed and where I've seen it fail has all been pretty much predicated on the kinds of people that. we've put into key agile roles, like the product owner, like the agile coach, because they play wonderful support roles to really build that capability in the squad or in the team. And the coach plays a critical role. So the coach is always looking at me. And mindset. So in things like retrospectives, when you do things like that, and you look back on the last sprint, the team had should have an opportunity to give each other feedback. What went well, what didn't work well, that's a live conversation in something like a retrospective where I've seen it work well.

[00:20:02] If you've got a wonderful PO or an agile coach, they should be facilitating that conversation and making it more normal and acceptable. And again, role modeling that Behavior is really important. 

[00:20:14] I think also for senior leaders to come to those ceremonies and again, listen without judgment and not jump in and ask a million questions and that's a really hard thing to do. But not default to some of those traditional behaviors is really important because what you want to do is you want the team to be self managing. You want them to drive performance for each other in the right care and consideration, as opposed to a leader, constantly feeling like they have to come in over the top. 

[00:20:42] Pia: And that y'all was really born in the sort of development space in technology, but is now, I mean, you're in a bank is there a certain type of organization this works better full or maybe one that it doesn't work? Or is it something that you're now saying, no, this is, pretty across the board.

[00:20:58] Natalie: Yeah. I think I've worked in telecommunications, media and telco, and now banking. And I would say it's worked in each one of those. Industries and organizations. Varying sizes vary in global reach varying challenges that they were facing that, that sort of prompted a more dramatic change. Yeah, I think it's industry agnostic actually. I don't think that it works better in one organization or another. I actually think some of the digital natives, some of the fintechs, these smaller organizations that are disrupting some of these traditional companies are born. So they've got no choice. They have to operate this way. You've got to be much clearer on what you're driving, you've got to know who's accountable for what, and you're naturally working in a digital born way because that's the way that you're engaging in the markets that you're operating in. And so it Naturally. Becomes that.

[00:21:58] I think organizations we've just complicate things over time because. Someone needs to govern that and someone needs to lead that, and who's the, what throat am I going to choke for this particular thing? And I've heard all these things in my career, but these are the things that we've put in place in companies to make someone at the top, I think, feel really safe about all of that. And that's not necessarily right. I mean, I think that Now. We have to think and adopt the ways of the disruptors otherwise we won't survive. I mean, I just, I think that applies in a lot of industries, so yeah, I would say if you're not adapting your ways of working, I would worry actually about. Th the longevity of the, of that industry or that business that you're in. 

[00:22:43] Dan: And in terms of team type net, you've painted a picture of a very flat organization where the teams are genuinely empowered to deliver. What about um, you know, do executive teams still exist in this environment and in, in which case and how do they 

[00:22:57] Pia: going to say, yeah, how, yeah. How much do they like 

[00:23:00] Dan: Yeah. How much they like it. Exactly. The people who found the dysfunction to be safe. 

[00:23:05] Natalie: Yeah. It's a big change when you're on an executive team at that level to change The way you work, given the way you work. Got you to where you are. So that's difficult to say. Okay, so everything that made you really successful, you have to forget about that and operate a different way. So I would say the ability to adapt to that happens over time. It's not dramatic. It's not like you say, we're launching into an agile organization and we're all operating our job. Some companies have done that, but the executive team adapts over time. Normally, what I see happen is and for me, I get a lot of air time with the executive team and with Ross at NAB because they are very passionate and committed to making the right level of change and conscious design choices as we go through this. So they're very engaged in it themselves.

[00:23:54] And I hear a lot. Oh, they need to role model it and they need to be an agile squad at the executive team. Otherwise it won't change. I actually don't believe that. I believe that depending on the scale of the change, part of how they work has to be agile, but part of it, there's a whole lot of risk and governance work to how you run a bank that actually does not apply to agile. I respect that they've got to balance both, but when they're in with their teams, what's most important is they role model the behaviors. So go to the work, make sure you're going to the ceremonies, go to the teams if you have a question, don't have the teams come to you. That's the most important change I think. And then over time. I think we can make the executive team work more agile, particularly when they're driving common goals and common outcomes as a team, because they're already have all the capabilities around the table, so to speak. But I wouldn't say that they would be working as a squad necessarily. 

[00:24:49] Pia: Yeah. And that's interesting because I think sometimes that is, there's a bit of a sheep dip approach. Isn't it? Everybody's got to be the same, but actually there's more about how do we set the conditions for success? So their role as executives is not to get in the way. But actually to enable the organization. So you know that there may be behaviors or their approach, their support a bit, but it doesn't necessarily mean as you say, they have to adopt that.

[00:25:16] Natalie: Yeah. And what I see in the NAB context now is, when we have to make rapid decisions around prioritization of resources or business outcomes. And we get stuck in some about operating model areas and we can't move forward because we've got resource constraints and they have to make a call, they would jump on a call very fast for me, 15 minutes, rapid fire, we looked through the list. They make a choice as a team, and then we move on. Now that to me is incredibly powerful because that happens very fast. If you think about getting in the queue to go and present to an executive and giving a business case and it pack, I don't have to do that. I just send them a note and say, we're getting stuck on this, we need you to make a decision and they do it. So for me, that's incredibly powerful and that's showing really good leadership of the agile model.

[00:26:01] So I don't need them to be a squad. I need them to provide leadership across the organization, so the squads can perform and they don't. do anything. Like we call them break-ins at NAB, but executive break-ins are the most disruptive thing. So going to the squads and saying, Hey, I've got an idea. Why don't you try and do this? That's very unhelpful. So making sure they don't do those things, I think is really powerful 

[00:26:24] Pia: Yeah. A break in a bank probably 

[00:26:26] Natalie: Yeah, 

[00:26:26] Pia: one. Is it?

[00:26:27] Dan: It's great. We call them drop-ins but I think they're more, it's more like a break in it. It definitely.

[00:26:32] Pia: now that, this is so rich and I think you've really articulated it really clearly for us, and they're going to, there's going to be, I think some people listening now who is teetering on the edge of the waterfall thinking, can I take the leap into agile? So what would you as a rat? What would you suggest like maybe two or three things they've got to really think about or got to consider. That could make that transition easier as they start to think of how to apply it.

[00:27:00] Natalie: Yeah. When I started this, I wish someone had given me. A list of things to think about as well, because I think it's really important to know what you're getting yourself in for. The first thing I would say is it's all big changes you make in life. This might be a bit philosophical given what we've been through the last couple of years, but as you're making big changes in your life, you're never going to feel ready for that, there's always going to be that part in your stomach that is anxious and unsure because you haven't done it before. And you're on the edge of trying something new. My life motto is always, foot to the floor mate. When you're feeling that you've got to go, you've got to go for it because you'll never feel ready. You'll never have all of the perfect bits in place that make you feel beautiful and comfortable about change. It's not the way change is.

[00:27:51] The second thing I would say is be really clear why you want to make the change. So don't just do it for change sake and all the cool kids are doing agile. Maybe that's the thing I would say no. The way I'm applying the agile method at NAB is very different to how I did it at Telstra, because the challenges of. And it's not the same organization. It's not the same industry and I'm solving for something different. So I'd say, be really clear what you're trying to change in your organization and then work out if agile is going to provide you with the right solution.

[00:28:26] And then the third thing I would say. Make the change within your own organization. It's really important to have great partners, really strong consultants experts that can help you, but you have to lead the change in your organization from within the company. So it has to be a leader led change. 

[00:28:46] One consistent thing that I've applied across all of the transformations has been co-creation. So it's another little thing that I'd add in there as a a special extra for your listeners, but you have to design the future state organization with the people who are doing the work, not a bunch of people who think they know how things work around a white board that is unhelpful, that gets you to a theoretical place. It doesn't get you to a practical place. So you have to involve your teams, the people that you want to liberate, the people that you want to make, go faster and have decisions and live their purpose, let them design it because any day of the week, when it's not working, they will work hard to make it better for you, because it's their model. And so I think that's an incredibly powerful way that you can open up the organization and break some of those traditional barriers as by bringing people into the fold and co-create with them. 

[00:29:46] Dan: Wonderful now, thank you so much. I think you've painted for us an amazing picture, not of that sort of, you know, the trendy agile thing that sometimes people have a picture of, but really a an opportunity to. Build teams that feel that our accounts will and genuinely feel accountable and and where an organization that can execute at speed.

[00:30:06] I think it's been just really refreshing to hear from the inside of a large organization, how that can be done. So thank you so much for joining us on we, not me, Nat.

[00:30:14] Natalie: It's my absolute pleasure. Thanks for having me. It's been Great 

[00:30:17] Pia: Thank you. 

[00:30:18] Well that's was really insightful and not gave us a lot to think about. And it's great to hear from someone who's a real expert in that field, but it took me down. Memory lane took me down a few years back and I was thinking about Lew's transformation in a professional service business. Traditional way of working incredibly customer centric and then positioning itself for a major transformation to the organization that it is today.

[00:30:54] We talked about that standing around the project board known as the Kanban, and people's emotional response, but it actually also made me realize there's a lot of language that can be quite overwhelming and it's like anything it's different. And so therefore you can dismiss it, but I think there's so much more to it that once you've experienced it and got your head around it, it's difficult to go back.

[00:31:21] Dan: Yeah, very difficult. And I really hope that people who haven't used agile or to be honest, which I've heard from, from people are quite skeptical about it. Even the name seems to be, it doesn't always have positive connotations, but I would really hope that the listeners will will consider this, because I think for us in that organizing, you know, as you say, both working in a professional services business, very fast moving customer centric, but we wanted to transform. I think we actually had a history to be honest of delivering for the customer, but actually we'd have these strategic projects that were transformational that would take us onto the next curve if you like. They tended not to get done because there was always a customer need, that was the, you know, the crocodile nearest the canoe. And, so the shift to agile actually helped us to deliver some of those in a really disciplined way. And it accelerated us hugely. So, but as you say, some of the language and also that cultural shift it's not a slam dunk. You can't just say, oh, here it is. Let's move to that. There's, there's a lot of sort of skills, but also some mindsets that required shifting for all of us. 

[00:32:25] Pia: And I think the other part was it really enabled talent within our organization to shine. People who were brilliant at organizing things and running things. You know, this whole idea of scrum masters, you know, we'd never had that concept. So it was really liberating. And I think what we'd ended up doing was that some of us that were very busy were just like huge bottlenecks in the business's transformation. So I released it, brought all that talent together, and enabled with really quite astonishing speed for us to start to grow and transform into, at one stage, both the professional service and a platform business, 

[00:33:07] Dan: And it comes back to the story I told at the top of the show, which is actually just getting everyone to talk, get really clear on your goals, but G get everyone to share all the tasks that is, which they've been possibly doing, just doing themselves share those. And then you've got, what's called a backlog. And, um, Nat mentioned that there's literally the list of all the things that you need to do that you can think of to do. But then that moment of right, we're going to set a two week sprint, just a sort of simple time and we're going to move, we're going then to go and decide what we are going to do in that time box. And we put that into, in progress and we all work on it's really transparent. You might have these little meetings, quick meetings called stand-ups to just check in and see if there are any, any barriers to completing it, um, and then at the end of the time, end of the sprint, very simply you just have a conversation to see what's left, went so well, how can we accelerate?

[00:33:58] And I think the essence of that while there's a lot of jargon to me at the heart of scrum, is that really simple cadence and it's so It makes common sense. And honestly, I've worked with clients and, um, we started using it within 15 minutes. I mean, obviously there's more to it than that but it it's sort of a very simple thing to do. So I would encourage people to cut through the jargon and just really think about the basics of this, this idea. And, um, give it a try and keep learning. learning. 

[00:34:25] Pia: And what dan, would you recommend to read? W if you've got 1 book that you would recommend or for people who are thinking about this, that, that isn't going to overwhelm?

[00:34:36] Dan: The book scrum by Jeff Sutherland actually is a is a good read, it's not too thick, you know, i'm an engineer. So I sub vocalize my lips move and I'm reading and I got through it in reasonable time. But that, that really sets it out in a, just a really pragmatic way. And and will just get you started. It's a good read and it's pragmatic so you can use that as a good starter. one. 

[00:34:59] Pia: fingers crossed one day jeff can, we can get him on the show and then he can actually talk about the book then. 

[00:35:03] Dan: That will be wonderful. I think he has many hair raising stories to tell there's some pretty major projects in in NASA and elsewhere. So that will be wonderful. 

[00:35:11] Pia: Great. 

[00:35:12] Dan: So that's a wrap for this week. Next week, Pia, we are taking a bit of a shift into looking at customer centric teams at the heart of agile is this customer as well. So we're going to be talking to Stuart Dalziel who's really spent his career looking at and helping organizations and teams build customer centricity. So I think we'll have a really good conversation with him.

[00:35:33] Pia: Can't wait.

[00:35:34] Dan: So that's it for this episode, you can find show notes and resources at Squadify dot net. Just click on the we, not me podcast link. If you've enjoyed the show, please do share the love and recommend it to your friends. We're not me is produced by Mark Steadman of origin.fm. Thank you so much for listening. It's goodbye from me.

[00:35:52] Pia: And it's goodbye from me.