E117 – Agile Working (w/ Sathpal Singh)

E117 Agile (w_ Sathpal Singh) 2

SUMMARY KEYWORDS agile methodology, workplace culture, continuous improvement, product backlogs, role clarity, Scrum framework, team empowerment, transparency, feedback loops, learning culture, agile values, project management, task switching, leadership mindset, organizational alignment This is the world of work podcast with James and James. is James, and this is Jane, and here we are again with another

episode of a world of work podcast. We've got another exciting one for you today, Jen, what are we speaking about?

Well, today, we are talking about something which I must confess, has been a bit of a mystery to me. Over the years, we have got lovely friend of the show Seth coming on to talk to us about agile in the workplace and hopefully, finally explain to me exactly what Agile is and what it isn't.

Brilliant. Let's get into the conversation and see where we end up. Okay, so here we are on the main body of today's podcast, and we've got another really exciting one lined up for you. Today. We're going to be speaking about agile, and we've got a great guest. We're joined by SAF Sathpal Singh, who's one of our neighbors here in Edinburgh, which is fantastic. And as I said, we're going to be exploring agile and looking at a lot of aspects of that that we can use to bring in and improve our workplaces. But before we get into that South, could you introduce yourself and say a bit more about yourself and your background to the audience?

Yeah, sure. Hi James, Thanks for Thanks for having me. Yes, yeah, as you, as you said, I'm South Sathpal Singh, most people know me as South and I'm an Edinburgh, Edinburgh, Scotland, based over the accent. So really, in the day job, I kind of sit at the intersection of engineering and agile with a focus on people, culture and communities. That's kind of where my passions lie. And I've been in industry so little over 20 years, and I kind of moved from, you know, hands on sort of software roles to more kind of managerial, sort of leadership type role spanning various industries and sectors with national clients and global brands. Also do a bunch of voluntary stuff, so notably with the BCS, so that's the industry body for it, and the chart Management Institute, and chart with both of them. And I'm the organizer at the future work Scotland meetup. So we do kind of host sort of fortnightly events with various industry leaders looking at all aspects of how work is evolving, a bit like you could

serve, yeah, and, well, I've come to some of those sessions and look great fun. So if, if people want to check them out, they can check them out on Eventbrite. Is that right stuff? Is that the best way to find this one a meetup? Yeah, brilliant. Something else that you were working on recently that sounds really interesting is you've been involved in helping to run the Agile 21 reflect festival. Could you say a little bit about that? Yeah, yeah,

absolutely. So, yeah. So this February passed, we saw us reach the 20th anniversary since the original authoring of the Agile Manifesto. So fearless were talking about how we might sort of mark that occasion. And the original idea had been to kind of do a retrospective of the manifesto since the last over the last 20 years. But then we kind of got to the view that really, actually, that was a little bit modest in its aims. So we, you know, so we decided we wanted to do something more of a celebration, have a bit of a global party, bring the global, agile sort of community together, and from there, you know, we want to kind of bring that vision for life and make it reality. So, you know, we can form the global team, all made up of volunteers. I should add everybody was involved was, you know, a volunteer. And then really we kind of collaborated to to create this kind of ecosystem, distributed ecosystem, what kind of program of events all over the world to mark and celebrate the occasion. But what we were really doing was celebrating agile past, agile present. And, you know, it's possible futures. I was really great. And, you know, over, over February, we had a kind of festival of a program of events, which saw the hosting of over 800 events around the world. It's phenomenal, yeah. So, yeah, that was that was really kind of unexpected. And, you know, the global response was overwhelming. And you know, we've had a kind of, I think it was 140 countries involved, 19 languages, and nothing of that scale had ever really been kind of done kind of with the Agile community over really agile 20 year history. So, yeah, really quite something. And you know, at the heart of it all for us was kind of diversity, inclusion, yeah. So we wanted to kind of, you know, lower the barrier to entry, some of the challenges sometimes people face with sort of conferences, etc, and really welcoming fresh voices. And also we were really keen to make sure you had a strong desire for equality, so not everyone was in the spotlight. So you know what? About, you know, experienced people, the leaders. It was about everyone didn't matter on your level of expertise or how long you've been a practitioner. Everybody had a voice. And, yeah, everybody, everybody was in spotlight.

It sounds absolutely fantastic. And hopefully there will be more events coming up that people can get involved in. We're going to start really at the beginning. Start with real basics here. So a lot of our listeners will have heard of agile, but maybe don't know too much about it. So could I just ask you to introduce agile as a concept or as a methodology? How would you describe agile?

Well, that's always a good question, because if you ask six people, you'll get six different and over the actual festival, we had lots of events which spoke to that for me, I guess my view so really agile is a kind of way of working and thinking that's important, the mindset piece which kind of enables you to really respond effectively, to change and optimize, kind of, you know, the flow of valuable outcomes to whoever you know, whoever the recipients are of whatever you're trying to do. So, you know, your products and your services. That's the way I tried to look at it. It's, it's responding well to change,

right? And when we think about agile, a lot of a lot of people who think about agile associate it with, you know, Engineering and IT, do you think it sits specifically within that sector, or do you or reverse functions? Or do you think it's other functions as well? Absolutely,

it's not. Those were its origins, right? So, so, so the thing here is, the manifesto was, was written by by 17 men. And, you know, the ski resort back in an event in 2001 so you just mentioned, I just wanted flight. So, 20 years on, and they were in the tech industry, but it's come on so much since then. So, so a lot of the values and principles are applicable way broader than technology. And actually, what we've seen is we've seen amazing application outside the tech. And that's really, you know, what a lot of my interests are these days, and that's quite exciting to see. So those origins were, you know, tech, it's used in applications we brought up. And

when you were speaking about it earlier, you you mentioned the phrase culture, and you talked a little bit about it being to do with our ability to respond well, to change if we drill in on that culture piece, how would you describe an agile working culture in whatever team that happened to be, what what sort of comes to the surface in terms of those ways of working our behaviors and the culture that shaped, nice

question. So I think, I think to think of it so agile cultures, really the key is that teams, that teams are empowered, so agile, so cultures that truly agile in the way they're adopting the values the teams are empowered, you know, they're engaging effectively with the customers, and they've got really good, effective kind of feedback loops and short feedback loops of getting a lot of engagement. They're figuring it what's not working, and they're very focused on delivering value, you know, through the products and services. And what that means, really, is the way it feels culturally, is sorts of transparency. No, people know what's going on, right? They understand the goals, they understand the why, and those who are delivering are able to get on with the how. So they, you know, they're trusted, they're empowered, they're able to focus, and they're able to kind of forecast what they think they can get done in given periods of time, because they're trusted to do so, so trust empowerment, you know, the kind of visibility of work and everybody knowing what's going on is kind of what it feels like when it's being done. Well, does that? Does that make sense? Yeah,

yeah, it does. So trust and empowerment come through really strongly. One of the things that we see often when we're speaking to teams where we're looking to create trust and empowerment is a real need and a real clarity for, I guess, those goals and those objectives, and it's something that you, you touched on a little bit at the beginning. How do you, how do you in an Agile team make it really clear as to what the larger goals and objectives are, and how do you connect people to those,

right? Okay, well, um, well, there's lots of different ways people do that. But I think I talked there about sort of transparency, so, so, so from a kind of implementation perspective, so to speak, you know, a lot of this sits around this idea of having, like product backlogs. So, you know, when you're trying to do things, you're capturing the work that needs to get done. You know, you've got a backlog. You've got a sort of prioritization around that, and that's visible. And the point is, you know, you have a single source of truth, so people know where to go to see what's going on right now in any given time. And the visualization of work is really key to being successful at this, because you know what it's like when stakeholders want to know what's going on, they want to know what things are getting done. And by making this stuff visible and getting everybody onto the same page, that's really how you can make this stuff work.

Yeah, yeah. I'd like to ask a little bit more about that visual representation in a little bit, in a couple of minutes. I think one thing. I'd just like to touch on now is the the, I guess, the importance of role clarity, or how does role clarity fit within this? Because in a lot of organizations, individuals don't necessarily know really what their role is, and it seems like in what you're describing within agile, you've got that clarity of task and clarity of purpose and some clarity around broader ways of working. But how do, how do you get that real clarity on what my role is as an individual in a team? Or how is that defined? Or is it defined?

Yeah, very much. So well, it will vary across. You know, there's lots of different frameworks and methodologies, etc. To be honest, there can be a lot of fixation about Scrum versus Kanban, safe scrum at scale, all this stuff that I'm sure you're kind of familiar with them, or you certainly have encountered it before, but when I'm thinking about this, one of the things I quite like is if you take something like Scrum, so Scrum is quite a prominent framework in the Agile space, and it has kind of three key roles, So you have the concept of a product owner. So I touched on product earlier, and really the idea there is, you've got someone who's focused on the goals, know the why, the vision, and they're kind of interacting with whoever the other stakeholders might be, and really almost as effectively the voice of the customer. So they should understand the customer. They should understand the needs. What are we trying to achieve? And then you would have the role of someone called the scrum master. Again, these are just roles, but one person should be focused on playing that role. And a scrum Master's role is really to facilitate and coach and ensure that the adoption of that particular method, in this case, the framework Scrum is being as well adopted by the team as it possibly can to help them achieve the aims and goals that the product owner you know is interested in. And then you've got the team, so the doers, you know, the team, whoever might make up that team. And you want those guys to be empowered, but the scrum master will typically support them on that journey. And it's the product owner who is going to set, you know, set that, set the goal, set the objectives, and the team are then empowered to get on with that. So that's how these these roles should collaborate. The scrum master is key, because the scrum master is there to support the product owner, but also help support the team. So when there are challenges, you know, blockers, etc, it's usually a role like the scrum master that would facilitate these conversations with a product owner, to get them to speak to, for example, say, the stakeholders, to make them aware and try to get you know remedial action, etc. In all this, by doing all of that and having strong communication between key roles over time, that's going to improve, and that's where your agility comes from. Does that? Does that make sense?

Yeah, I think that makes really good sense. And I just while you're talking, it really struck me. So for a lot of our listeners who aren't familiar with the space, some of the terminology that you might be using might be new to them, and they might be like, Oh, that sounds exciting. What's that? And it just struck me how powerful actually, let me rephrase that. How powerful Do you think it is that there's just a set of common language that everyone who's working on the project understands in terms of role, name, role, purpose, the way tasks are allocated. You know, the length of time that phases of the project are going to be because that every time I ever speak to someone about agile, which whatever framework they're using, it's very clear that language has been carefully chosen so that it's not confusing with anything else that might exist in the workspace. And I just, I'd love your reflections as someone who's so familiar with it, of how important is that language and having a common understanding of it, and and do you think that is part of what makes sort of an agile approach quite, quite different from what's gone before it in terms of project management and stuff

like that? Great question, I think so, yeah, very much so. But there's a couple of things here that are interested in. We asked the question now, I think part of this is those roles exist and those are captured, and you know the scrum guide, etc, but it also does require sort of reinforcing within your org, so it takes time for people to truly understand what these roles are about and what they should be doing. But again, a lot of this stuff is guidelines. That's what a framework is. So you're working within, you know, almost some guardrails, but you're not really it's not too prescriptive, but the roles really help with, I guess, accountability, right? So that's something that we see, something suffers an organization. So you know, if you if someone truly understands all the scrum master and the good Scrum Master knows what they should be doing to really help the team succeed, and supporting the product owner. The product owner role has a key set of sort of objectives as well. It's really what that role is about. But it can take time to really embed that and make it work well. And to be honest, Scott is one of those things that you know, if you look at a lot of literature, and there's countless books on the subject, you'll often hear statements. Like Scrum is quite easy to set up and put in place, but it's really hard to master. It's like a lot of things. These things take deliberate required deliberate practice. One of the things that mostly appeals to me about agile ways of working is this idea of continuous improvement, right? So you're constantly learning. You're doing things in short cycles, and your feedback loops are strong and you're learning, and we touched on there about traditional project management. That was why agile kind of really came about. Because back then, and I was at uni at the time, actually, you know, the old sort of it, projects were failing a lot, you know, they were over budget, they weren't delivering what they should, and they were just feeling left, right and center. A lot of that was ultimately because of the way things were being planned, and folk weren't thinking a lot actually, but actually, in a lot of these types of environments, there's a lot of uncertainty. There's a lot of ambiguity. So this is really about actually finding means and ways to actually manage that and stay on top of that and handle that, because these things don't go away. Change is just inevitable. It's part of working life. You know, we talk a lot about VUCA, right? So that kind of volatility, uncertainty, ambiguity, but those, those things are just part of working life for us. You know, we're knowledge workers. That's where agile ways of working really kind of support us, because you can create a plan, but very quickly plans become kind of useless, you know, because things have moved on.

Yeah. And, you know, speaking as someone who I suspect might be slightly older than you, because I think I might have been in the world of work when that was happening, when you refer to projects, I like that. All of that sounds familiar to me, right? The fact that the minute it's written, it's, it's it's redundant effectively, and there wasn't necessarily an appetite to manage in the process. And I guess that that makes me ask questions. So I've you that's a really good understanding of, like, why something new and a new approach was needed. Um, but could you explain a bit, a lot I've heard the phrase agile manifesto is that, could you talk a little bit about is that, was that in response to the things that were going wrong, or was that something different?

No, that's very much what it was. So what? So when the the original 17 sort of co authors, original co authors came together, and that's really what they were trying to do. So I think they'd seen a lot of the challenges they you know, they'd experienced a lot of that at that time. And a lot of the stuff actually does go back to kind of the sort of 80s and the kind of early 90s, so kind of slightly predates my, my sort of promotion, professional sort of working life, but when they create the original sort of value. So this folk a manifesto basically consists of four values and 12 principles. And what they were, what they were trying to say by sort of creating those. And, you know, they created the values over over three days, was that there were certain things that they'd kind of identified were really valuable to try to focus on. So the values themselves, you know, the first ones, like individuals and interactions over processes and tools. So really, what they were trying to say was, look, if you focus in on collaboration and the way people communicate, and focus on delivering sort of working software. So a lot of that at the time was centered around the delivery of software projects. They weren't saying that they didn't value processes and tools or documentation or contracts or plans. They just valued the other stuff more because they found that it was more effective in enabling them to get things done the way that people actually wanted to get things done. And you know, if you're really going to deliver value on a product or a service, it probably makes sense to be working closely with your customer, right?

Yeah, absolutely. And it's just it, I've got to say, right? Don't take this the wrong way. But this is the first time I've really started to understand, like agile as a I guess I don't want to say movement, because I don't know if that's the right word, but as a different way of working and addressing problems and product products and services development. And I guess, like, Thank you for explaining that, because I've never been quite sure, so it makes a lot of sense as to why a group of people would respond in that way to some of the current challenges, which I guess, then asks the question for me about, like, who, who were the first adopters within our within our industry, and what you know, why do you think they're the ones who gravitated to it, in terms of, like, what type of product services or businesses were the first to get get stuck in? Oh, wow.

So it's interesting. You kind of mentioned some of what you've just said there, Jane, because it was a paper written, and that goes back to kind of the mid 80s, and it's called, like. The new new product development game that was written by two sort of Japanese gents. So some of this stuff did kind of come out the early you know that the kind of lean the tail to manufacturing industry. And the thing to remember is a lot of this stuff was going from sort of almost like production, factory type, kind of delivery, which really isn't the way a lot of these things work, to where we are now. So I think a lot of the early sort of, you know, the larger sort of tech companies were starting to kind of embrace this stuff, I would say I don't honestly know who were the the actual first companies that you know that kind of predates me, and if I'm honest, I'm not sure I massively, really kind of care about that. But what I what interests me, and I guess what I'm speaking to, is they kind of identified that things weren't going as well as they could do, and these projects were over running, and budgets were being blown left front and center. And the manifesto actually is talking about, you know, that that would, that was written at a point in time, so things have moved on again since. And really, the point is they were finding better ways to deliver software, right? And actually, as someone who was a software engineer for many years, and even I know a few of the Agile Manifesto authors, I think we're still learning right? So to me, it's actually more about creating learning cultures. So I'm probably not entirely answered your question, but I would say that the focus is actually more on that desire for continuous learning and trying to reduce complexity and reduce ambiguity as time goes on. Because I think way back, there wasn't enough acknowledgement in some of those big programs and projects that you know what you can't plan 1824, months ahead. That's madness.

I think you very much underplay both how much you know, and also like the insight you have on it, because you talked there about this idea of this idea of really, it was it that fundamentally took a grasp. And I think you pinpoint something that I hadn't sort of conceived of until you said it, which is this, this shift away from two things, really, one is the shift away from, like manufacturing and physical products, right? And this, so there is this. There is a far more options of things like rolling out unfinished or test products to, you know, select groups of users, and all of those sorts of things that it can do that lots of other people can't. But also, I think that's really important, is things were changing so fast in terms of the tools and the resources that people could use. And I'm thinking about One unnamed UK IT project from the 90s that that I'm not going to mention that, like, by the time they were in, you know what they considered phase one, which was the first three years, the, I suspect, billions. I certainly it was in the 100 millions that they'd invested in some of the some of the tools were redundant, because other developments in the sector, and particularly in tech, had moved beyond that. And so like listening to you and hearing about the values, it makes total sense that you would get frustrated working in that environment, or the 17 people who came together and say, there has to be a better way. We have to be more quite, and I can't believe I'm going to say this, but we have to be quite literally more agile in response to the environment that we're in. And so, yeah, like, I think that's really interesting. It makes sense. And I really love what you were saying about the organizations that you saw or have seen as having a learning orientation. We talk about learning orientation a lot within organizations, and I guess that kind of takes me on to that question about, like, what if people are thinking about, what does agile look like? So imagine, you know, someone who's never come across it works in a traditional organization that maybe hasn't touched on those processes, what would be some of the actual practices they might see if they walked in and sat in on a team for a week.

So, okay, so scrumza was a good example for me, but there are numerous, you know, one your methods and frameworks out there. And to be honest, the a lot of Agile is we've got to space now where I like to, you know, I'm quite sort of framework agnostic, so to speak. So, you know, I'm not wedded to one sort of way of doing things over another. Ultimately, you want what's best for the org and the team that's going to support them in wherever they want to get to. But, but some of the things that you will see in those types of environments and organizations where they've adopted those ways of working, as you'll see lots of events or ceremonies, depending on which kind of you know sort of terminology you're using. So you'll see things like stand ups. So the point there is a delivery team will meet a given time every day for 15 min. It. So it's deliberately time boxed to talk about where things are and surface the challenges. And the whole point of that is, by doing that on a daily basis, they're able to try to get these things resolved in a 24 hour cycle. That's the point. So it's those types of events that if done well, right? And that's really important, if done well and you're true to them and you practice them, over time, those teams will improve, and with those teams improving, they will see agility, and their customers will see value, and they will push out products and services faster. So you know, stand ups, planning sessions, actually trying to figure out, what is it we can actually do? So, you know, product people, stakeholders, they'll have some ideas, right? And you've captured things in an artifact. That's the backlog, that's where everything is, that stuff's been prioritized. But the team, if they're in power, the team's got to be told, Look, we want to do this stuff, and the team is going to figure out, well, what's the best way to do it? So that's where that concept of self organization comes in. Teams are empowered. They're able to go, right? We have a two week iteration. What can we realistically do in that two weeks? And as you know, they go from one iteration to the next to another. As they go from one to the next, they're learning more. They're learning more what they're able to do. They get better acquainted with themselves around their dynamics. They learn more about the challenges people build familiarity with. You know the stakeholders. They speak regularly because they'll have review meetings. So at the end of an iteration, you'll have a review you'll you'll ideally demonstrate some progress to your stakeholders. Hopefully they'll like what they see, but they're quite short cycles, right? And with those short cycles, you're getting that transparency I talked about earlier. You're giving visibility, getting to a common one up on the same page and what's going on and where things are, and as trust builds this stuff approves, and that's, you know, if you get that stuff right, truly right, and you're committed to continuous improvement and the mastery of these ways of working, that's where agility comes from. So organizations who have really mastered this stuff, that's where they see the benefits, and they're pushing stuff out, right? So you take Amazon. Amazon does a release every point eight of a second or something. You know, the tech giants who empowered their teams and let them go and push these products like that's how they came to these places, because of introducing those ways of working and and basically let clever people come together and figure out how to get stuff done. Yeah, yeah.

So I've got a question for you, when you're speaking about all of that, if I were to to, you know, imagine myself as a traditional, historic leader, what you're saying is petrifying, because I don't have any control, right? So how do you go about that process of helping maybe more historical organizations say, You know what, your role as a leader isn't to control and own and dictate everything, but it's more to empower and keep space. How does that dynamic change happen?

That's a great question. James, so it's funny. It's funny. You kind of say it like that, because to me, I think what you're describing has actually not got a great deal to do with agile, but it's much broader, okay, in terms of how leaders should actually be empowering their teams and thinking about their role to, you know, create a very clear vision, right? And I touched on that earlier we talked about goals. So, you know, one of the things Jane was asking about some of these kind of methods, what does it look like in reality? So in things like Scrum, you would have a sprint, which might be, you know, week cycle, traditionally, two weeks, maybe three weeks, there's going to be a goal, right? And as long as the leaders and the product owners make these goals clear, and then the team is able to get on, the team have to be empowered, because when you don't empower your teams, and there's lot, you know, there's lots of hierarchy in organizations. There's lots of silos, there's lots of bureaucracy. Those are, those are the enemies of agility, right?

So those things have to evolve and change, and leaders who want to be able to truly meet the needs of their customers and deliver value to them and see their customer base grow. That's the kind of mindset shift that they're going to have to kind of try to get into, because you will then see your results

and which, which do you think comes first? Is it chicken or egg? I mean, do you think that leaders need to go through that personal journey, or leadership journey, or leadership team journey, to be prepared for that different mindset. Or do you think that if you bring in an Agile team, you will, I guess, feed upwards and influence leaders? Or does it depend

that's really good, to be honest, I think you've got to kind of start. You hear a lot of people say things that you start where you are right. That's absolutely the right thing to do. And. You don't, you will never see this stuff in bed. Well, if you just jump straight to the practices and the tools, you know you have to think about the cultural shift, because they will need to be one. You know, you've both effectively said that. You know you're questioning, and that is absolutely 100% the case, that because there is a different mindset, and it is about the mind and the values and the principles that were authored in the original manifesto. Those are, those are effectively speaking to that, to that mindset. It's an attitude thing. So, you know, Jen used the idea of it being a movement those who really embraced it. And, you know, exists in many forms and flavors all over the world, and where it's been successful. It's, it's because people are in the mindset, you know, they've got the right attitude to change and handling change and how you most effectively enable collaboration. One

of the things that's in my mind when we're when you're speaking about this, is the sort of distinction that exists between different tasks that we do and the need for deep work. And even as we started this conversation, before we started recording, you were talking about task switching and the burden that comes with task switching and how it makes us makes it harder for us to focus some of the things that you described when you're talking through some of the tools that you'll use when working in Agile way, are things like meetings and things like that. What's the burden of that on an individual from a task switching perspective and and what scope is there within agile teams for serious, deep, focused work?

Yeah. So I think yeah, you're right. So I think with the way the world of work is for us, right? And the amount of stuff typically, that you know, we're juggling, we're jumping in meetings. And obviously that's changed again, with the, you know, with the with the impact of the global pandemic, you know you need to so when I talked earlier about empowerment, right? And letting your team self organize, one of the other key things of that is you need to let the team get on with the work, right? So some of these methods and frameworks, they advocate their own sort of ideas and values, right? So Scrum, for example, right? Has five values, okay? And those values are, courage, commitment, focus, respect, openness, right? And I focus in on a focus, because you have to focus on what you're doing. The team has to focus, right? And people also have to be able to be committed, to have to be committed to what they're doing. And, you know, people kind of get quite deflated and demoralized when you can't get on with what their actual job is, right? So we see it in cultures and workplaces all the time. People are there, they're trying to do their job, and they're getting pulled at the meetings, left at the center, and at the end of a given period of time, you know, managers and leaders are saying, where's this and where's that, and why is that not done? It's not done because they've not been able to focus, if not, being able to commit to what they should actually be focused on doing, which is delivering the stuff that everybody wants to see them deliver, right?

And that, that both, both makes an excellent point, but also raises a bit of a question that I have for you around so you mentioned the values, and I think there's something really powerful in a principles of working also having values. But does that sometimes create challenge between where organizations have existing wider strategic values or organizational values that they, you know, do things like recruit on, etc, and just, does that become a challenge? So if you're, I don't know if you're running a division that runs on agile, do you, do you find yourself sometimes, maybe in a conflict between, do you recruit to the organizational values or to the Agile values? Or how do you and do you ever see like challenges for teams in terms of how they interpret that?

Yeah, yeah. Great question. Um, there's got to be alignment, right? So, the thing is, if, if an organization, so, so we talk about agile businesses, and that was a that was a kind of term coined, like, a good few years ago. Now, the whole idea is, if you, if you're going to truly see agility, and you know, there's a whole bunch of, you know, amazing people out there doing work in the business agility space, you know you do have to kind of start with your organizational values. And if you know your values are such, it's going to be very easy for you to adopt agile ways of working if there's an alignment. So for me, it's still going to come back to alignment if an organizational values are kind of misaligned with, you know, values for some of these frameworks, etc, you're not going to be able to kind of use them effectively. There's going to be a tension, and it's not going to be a good tension, right? So some things, you know, we talk about healthy tension, it's not going to be a healthy tension and, and, basically. One will hinder the other. And it to me, it's kind of as simple as that, so I think you have to think about it in its totality.

Does that make sense? Yep, makes absolutely. I think you're right. And I think I guess, in my head, I'm just trying to imagine what it would be, how challenging it might be to transition into a place where Agile is embraced fully, versus maybe organizations not fully getting it and then going, Oh, it's not working for us, and giving up, which I feel like could be a challenge. And I guess that that also I'm curious. So you mentioned, you described yourself, I think as I hope I got this right, framework agnostic? Is that? Is that the phrase used? Yeah, yeah. So, just you mentioned a couple of the frameworks. How? How would an organization go about deciding what framework to use or what parts? I mean, can you interchange them? Is it something where you can go? I'm going to take that bit from that framework and that bit from that. Or when you say agnostic, do you mean you don't mind which one in its entirety?

Well, that's, uh, that's such a big topic, right? So, you know, we could be talking for days about this. Okay, so what stuff out there, right? So the point here is, don't fixate about frameworks, because these methods and frameworks and tools, etc, they're all They're all enablers, right? Ultimately, it's not about agile. It's about agility, you know, actually being able to create environments where you see agility, where you you know, you're able to get things done in a way that delivers value, and do them in an optimal way. I talked about that earlier on, I think when James asked me, you know what? What's my view on what is agile? To me, it's optimizing the way you get things done. So it's less about the frame, it's more about what what is, if you think of it at a team level, you've got to think about what does the team want to achieve? It should always come back to, what are you trying to do, right? What are you trying to achieve? Why are you trying to achieve that and work from there? So, so again, to me, some of these things go way beyond, you know, agile, but you know, you can tease these things out through agile ways of working. So, you know, good agile coaches, good Scrum Masters other people in that kind of space. That's the way that they would be thinking. And they would be encouraging, you know, those that they work with, the stakeholders, you know, the project people, the business stakeholders, to be trying to articulate and answer those questions. And until you've answered those questions, you shouldn't be jumping into certain three months. That isn't the right way to do it.

Okay? That is wise and sage advice. I would say, um, I just want to ask now, because I've never worked in an Agile team. It's, it's something that, you know, I've heard about. I've come across lots of people doing it, but it's to be honest, until we've had this conversation today, it's the first time I've got real clarity on like, what it is and what it isn't. What's it like working an Agile team? What's the difference between working in a team that doesn't use those kind of practices versus one that does? What's the experience for the individual there? Or what's it what's the ambition for

it to be? Do you think, yeah, that's nice. So to me, right? So when you see a team really embracing agile, and it's working for them, right? The cultures healthy, right? You don't see those sorts of, you know, behaviors. And, you know, we talk a lot about, like, toxic cultures, etc. So I talk, I talked a lot during this discussion about, you know, values, principles, you know, mindset, culture. So in a, you know, on a team that's really got it work feels fun, right? People are getting things done. They're working well together. There's a lot of trust. The transparency means that people aren't afraid to, kind of, you know, express when there's a challenge. You know, the raises of a stand up product owners become aware. The product owner goes away and speaks to senior stakeholders, and, you know, gets resolution. The team moves forward. Is a clear goal. Things are happening, you know, things are getting going out the door. You know, teams are doing regular product releases and getting them to the customers. Customers are satisfied. You know, you're getting good feedback on this stuff that that's kind of what it feels like. So when we did agile 20 reflect, right? Lots and lots of us came together a global team from all over the world. We lived in, you know, you know, a platform called slack and various WhatsApp groups, but we were just organizing ourselves around the work. We were driven by the, you know, the vision of the festival, our aims and mission. You know, what we were trying to achieve. People swarmed around the work. You know, they just got involved in the things that needed to get done, and collaborate and work together, and trusted one another, respected, you. Each other's views and opinions. Don't get me wrong. There were challenges. Of course, there were challenges. We were doing something really ambitious. That's what it feels like. People just get involved. They swarm around the work, they understand the priorities, and they simply focus on doing the things that deem to be of highest priority and greatest impact to whoever they're trying to serve. So

I'm I now have so many questions, because that sounds amazing, and I kind of wish my work life in organizations had been a little bit more like that. So it's going to make me think, but I do. I'm going to try and squeeze in before James cuts me off. I'm going to try and squeeze in one last question for you, because what you've just said strikes me as there might be a difference in the way leaders above those teams or even indeed leading those the teams that are using Agile have to behave differently. And I just, I'd love your reflections. Do you think there are specific skills or attributes that better suit leaders who are responsible or in some ways, managing or leading agile teams. Are they're different? Are they? They're different things that it really shows up where a leader is good at something, do you think if they're able to do it? Well, yeah,

yeah. And that's great question. So I think where organizations have made it work for them, and it's and it's and it's proving to be successful, the leaders are they've got the growth mindset, you know, the open to change that. There's a there's a healthy culture of experimentation, right? So some of the stuff I've talked about today, you know, the test and learn piece, right? So that's the whole point. You know, you've got cycles of work. Team are trusted to do it. They're getting stuff out the door, they're getting the feedback, but, you know, they're learning from so we talk a lot about failure, right? And traditionally, in a lot of the organization we worked and certainly it was a big part of my own sort of past in my sort of various jobs I've had in my working life where failure was a difficult thing to deal with. People made mistakes. You know, they couldn't feel like they could. Whereas a lot of the agile ways of working, it's like you're embracing that you're learning from that as long as you do it quickly, people talk about or fail fast. I don't massively like that phrase. I much prefer the phrase, learn fast, right? So if you do something quickly, and it's enough, right? This concept of a minimal viable product, and you push it out there, and the customers get to use it, and you've got a good feedback loop, and you know, they can get that back to you, you can learn from that. So I think great leaders have embraced that understand these types of concepts, and actually their risk appetite is such that they can embrace that. But again, to some of the questions you asked earlier, that's going to vary a lot from organization to organization and sector to sector, right? So more heavily regulated organizations, right? In more heavily regulated industries, are going to struggle with a lot of the stuff that we've been talking about in this in this conversation, and they're gonna have to think about how they can embrace that, which might means they might need to think a little bit differently about how they do what they do, right? But that's going to be quite those are going to be quite challenging conversations. And when I was talking about values in scrum Earlier, I talked about courage, right? So that's when that those types of values really surface, right? Do we have the courage to embrace failure? Do we have the courage to ask those difficult questions? Can we create a culture of experimentation? If you can do these things, you're probably going to see some benefits.

It sounds, again, like leaders need to have that mindset and have, to some extent, a fair amount of agility in themselves and an ability to interpret and flex their own behaviors and to learn and to bring that, that approach into the teams that they're working with. I've got one, one sort of last question for you, and then I am going to wrap us up in the interest of time, how can you know if people are up there and they think this sounds really interesting, where would you direct people to learn a little bit more about agile? Have you got any initial starting points that people could go

to to learn? Oh, well, I'm certainly well, not my office, my home office, and there's like stack of books behind you which speak to the subject in various in various forms. To be honest, I would say, you know, start, start with, start with the manifesto. You know, you just Google that you'll get to the website, jump manifesto.org, and you know, you read the vows, you read the principles, and even if you were to go and then follow, you know, the work of some of the original, you know, manifesto authors, a lot of them are, you know, still very active in the space and doing great work. And you know, they themselves have evolved as well, because that was done at a point in time. And there's lots of people do great blogs out there. So there's lots of great blogs. Dogs, as I say, there's lots of really good books on the subject. You know, the, you know, the various certification bodies you can, you know, you can learn stuff through some of them. But, yeah, I mean, that's quite a difficult question to answer James, actually, because there's a wealth of material out there. It's difficult to to pinpoint one, one particular thing, but I would say, if you don't know anything about it at all, to me, you could do a lot of worse than start by reading the manifesto. Yeah,

that sounds like a great piece of starting advice, which is good. So I'm going to draw us up just before we go though stuff. Could you let people know how they can find out a little bit more about you and, oh, groups that you're part of and things like that as well. Yeah,

sure. Well, you'll find me on LinkedIn. Yeah, I'm pretty active on LinkedIn. So you know, if you want to kind of reach out and connect, or anything else you're welcome to do. So again, pretty active on various social channels. They'll get me on Twitter, you know, at South pal, that's, that's my handle. I didn't really talk about, but I do a lot of stuff and kind of visualization as well visual storytelling stuff. So, you know, visual South is my, my Instagram channel. And, yeah, you can, you can, you'll find a lot of my own stuff on future of work Scotland. You can find them on, meet up and join the group, or, you know, you search for them. You'll, you know, you'll find our YouTube channel with all our previous events and sessions, and you mentioned earlier, James, you've joined a few. Yeah, they're probably the best ways to get me, actually, yeah. But I think if you Google me, you could probably find some of these things. But, yeah, share any information.

And one thing I just say is for future of work Scotland events I've been to have involved people from all around the world, so you might be outgrowing the name Future of Work Scotland. That's

a very good point. Yeah. So, so the original thing, much like anybody else, was the, you know, we've done localized going to meet up group, and, you know, we did the BI monthly face to face events. As you rightly point out, we've shifted all that, you know, again, we've been talking about agile here, you know, we made a change there. We adapted, we pivoted, we learned from it, and we shifted our cadence greatly to, you know, a weekly event series. So that's very different to doing, you know, bi monthly face to face event to then doing, you know, a virtual event every week. And that's what we did over 2020 and this year we've moved to a fortnightly cadence. So that's what agility looks like. I think there's a there's an example for you. Great example.

Great way to wrap it up. All right, well, we're gonna leave it there. So just a huge thank you for me, Seth, that was really interesting. And as Jane said, really eye opening in terms of what Agile is, and it's great to benefit from all your knowledge. It was really excellent. So thank you. No, enjoyed the conversation. Thanks, Robin. Good to chat to you both.

Okay, so that was our conversation with Seth, and you were back in the room with us. I thought that was a really fun conversation. Jane, it's a subject I really enjoy, and I think it links so well with so many of the other things that we speak about. Did you have any specific takeaways that you'd like to reflect on from our chat with South Yeah,

I think so. I've always found the conversations and topics and the material online about Agile to be a little bit almost feeling like it's a little bit deliberately mysterious, not being absolutely specific about, like, what's a framework, what you have to do, what is it? What is it, and what's its purpose, and that it's some kind of I always had this, like, slight suspicion it was emperor's new clothes, if you like. But what I really liked about our conversation with Saturday just debunked all the mystique, and was like, look, it's a way of thinking about organizing your work. There are specific frameworks that people have written, and you can pick and choose from them, in his view, to make the best practices for your organization. I thought that was just like, really helpful.

Yeah, it's lovely. Lovely the way that he brings such a wealth of experience, but manages to compress it into such a simple explanation of what Agile is. Like You I like the simplicity of what he talked about, and one of the things that I really liked, that I just want to call out, is the link back to the culture, almost more than the tools and techniques that he speaks about. So underlying, you know, this approach to Agile is a need to do things more effectively and more responsibly, and, you know, to change and predict and move and work in an agile way to achieve your objectives and to have a culture that supports that. And I really like that simplicity. So, um, so like you, I found it quite an enlightening episode.

Yeah, I would, I would wholeheartedly echo that. And I think, I think it's a really interesting thing, right? Because I think organizations grab onto the frameworks and they go, Oh, we're going to work in two week sprints or bursts or whatever, but they don't really embrace the underpinning necessities of having absolute clarity on task and time and pace and all that sort of stuff. So I would imagine implementation fails quite a lot because the culture and the understanding of what is required in a change of culture just isn't there. Yeah,

and as we spoke about in our conversation, the role of leaders sort of changes, but need to let go a little bit. Can be difficult for some people. It's one of those times where you need to empower people as much as we've got some problems about language. You need to get out of people's way, and that's not always easy for people to do. Well,

maybe. Maybe James, that's why we liked the conversation. So you and I, you and I are always championing for more autonomy in the workplace. Yeah, exactly. Maybe we're like, Ooh, this is about autonomy. We like this. Yes,

exactly, confirming all our all our biases are brilliant. Okay, well, let's end the conversation there. It was an excellent one. So it's goodbye from me and it's goodbye from me. Have a good week. Hi everyone. This is James. Thank you very much for listening to that podcast, and please do share it and review it if you enjoyed it. And don't forget you can learn more about our coaching, workshops, courses and development programs on our website, that's www, dot World of work.io, again, www, dot World of work.io, you