AgileData #6 - The art of Business Agility

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

I'm Blair Tempero.

And I'm Andy Cooper.

Hi Andy, welcome and thanks for joining us. Today we're going to kind of have a bit of a chat about business agility and I suppose what What tweaked my interest is, as I coach teams, I've kind of come to a view now that there's 3 types of agility we need to introduce into an organization. So in the middle, we have agile delivery, which is pretty much where I'm focused on coaching teams about techniques and tools and approaches for doing that with data. Underneath, at the bottom, we kind of have automated operations or DevOps or DataOps and how we can automate these things so that We don't get the dreaded BAU bleed as we deliver more and more value that we have to maintain. But at the top, there's this, this thing called business agility, which is enabling the organization to operate in a way that makes those delivery and DevOps types of teams and approaches successful. And so for me, the easiest way I always explain it is with anti-patterns. So, you know, an organization where everything has to be signed off as an acceptance criteria by a committee or an organization where funding is based on a project budget lifecycle, or an organization where there's a large PMO with program managers, project managers, and the Agile team somehow integrates with their fixed view of a roadmap for a while. So, you know, we hadn't caught up for a long, long time, so when we did, and as we talked through kind of what you've moved into in terms of this world of helping organizations understand what business agility is and how to move into that paradigm, I thought it would be great to have a chat today. So, as a way of a background, why don't you tell us a little bit of a story or background about where you started, how you got to this land of business agility?

Sure. I think like a lot of people, I sort of stumbled my way into it over time. And my first sort of understanding of agile Probably was about 10 years ago when I was working at a software company called CA, known as Computer Associates, big company. I was running quite a large marketing team, so not in IT. I'm an IT user, and one of the things that we did, or we owned, was the web, which obviously, you know, even 10 years ago was important. So we were rolling out a brand new website. and it was quite a complex thing, and the person who headed that up decided that we should try and do it a little differently, and they had read a book about Scrum, and they said, why don't we try this? So I sort of got my first insights probably about 10 years ago as a user of Agile about that sort of whole iterative model, and it seemed to work very well for that type of project, and so that sort of gave me a sort of practical insight that Agile, as opposed to the traditional long planning horizons and wait to the end and see if it works, which I'd seen before many times, it didn't work. This seemed to offer a lot, from my mind, flexibility and the opportunity for a lot more interaction so that as a user at the other end, I didn't feel like we were having something thrown at us. We were actually involved in it, and therefore it felt like it was something that we could use and be happy with, which normally wasn't the case. We were at the back end of it and normally had something thrown at us and were expected to use it and like it. And of course, even if it was good, we didn't. That's the reality of users. So Agile seemed to me to make sense. After leaving CA about 8 years ago, I went to SoftEd, otherwise known as Software Education. So by its nature, we teach about we teach people about software. Agile has been around now for about 18 years. When I started at SoftEd, we've already been involved in that space for some time and we're already doing training, quite a lot of training in that space. So I sort of, you know, as head of sales and marketing for SoftEd, I had to quickly get my head around what this was. So there was sort of that need. Being a relatively small company, I also inherited the job of CIO for a while, which was interesting. And as part of that, we were also looking at a new website, and we also want to try and develop a couple of apps to help improve some of the efficiency. So I thought this would be a good opportunity of, again, putting theory into practice. So as the CIO, I sort of try to make sure that when we develop things that we applied what we taught. And that again gave me a good practical understanding of agile, you know, as a sort of user and, you know, as a delivery. And the technical side of it as well, which is often undervalued. You know, I see a lot of, you know, what I call sort of fake agile, which is sort of the veneer of agile, but in a lot of cases it's just sort of a few ceremonies, the trappings of it. So it looks shiny like the apple on the outside, but on the inside it's not very agile at all. And that's quite common. And part of that is that people don't actually focus on, from a software point of view, on actually developing agile, using principles that were built for that and with that in mind. The whole XP, which has been around for a long time, and all of the things that surround that, or the things that enabled us to move towards DevOps and all that sort of wonderful stuff. Was good to see how that actually worked in practice. And then since then, I moved out of that role, but I've now been doing a lot more advising. So as I sort of deepen my understanding of agile, and coming back to my more business focus, so obviously I have a technology background working for technology companies, but I've also been, you know, a business user in marketing and other roles. So I look at it from that perspective. Perspective as well, to sort of how does it help other parts of the business like marketing or finance or other things. And so that sort of attracted me into the whole business agility space, which was taking the principles first and the mindset that supports that, and then how do we apply that in a business context to sort of remove some of the problems that you have well articulated before, to create the agile organization. And that's a small A as well, so that we're able to sort of see some of the benefits that you see some of the fast-moving organizations, the Netflixes and the Amazons and locally the BitZeros and those sort of companies that have applied some of those principles at the start and how they're able to grow and respond quickly. So, as I said, more recently I'm doing more advisory sort of thing. A lot of it's now comes back to my sort of real core belief now that, you know, this has got to be a whole of business thing, and the people that will influence that are the leaders. So we need to really lift the understanding of agility as a discipline for the leaders. And so that's sort of my personal goal, is to try and help the leaders understand what agility means, not agile per se, but agility, and how they can help their people and their organization become more agile. And then within that, apply agile practices within the right context.

So are you seeing that appetite start to evolve? Are you seeing people at senior roles in organizations now wanting to understand what this small a agile thing is, what it means to them, or is it still kind of in a very much an early adopter phase where they they still see it as something for IT, something for software, something for your digital transformation project, or something that a vendor's going to bring that they need to be aware of but not really involved with. I suppose if you use the analogy of the pig and the chicken, they might not even be the egg, right? They might just be the farmer watching the animals. What are you finding?

I think it's very Different companies are at different stages. So some have bought into it in a big way. You know, we've seen some local examples like Spark, you know, it's been sort of heavily sort of guided by McKinsey, you know, who have a very clear operating, you know, agile operating model that they're trying to implement. So that's a C-level, board-level, you know, sort of interaction. And so they've got a very deep sort of focus on it at that level. We've seen other examples, ANZ in Australia, but obviously now in New Zealand as well, where, you know, the CEO has come out and publicly stated that, you know, they want to become an agile organization, and they're basically transitioning the whole organization to an agile way of working. So we're seeing, you know, we're seeing the whole organization moved into, you know, cross-functional teams. You know, they're using the Spotify-type tribes and guilds and all that stuff, which again, I think personally is a little overused, but anyway, they're using that with the purpose of trying to move their people closer to the customer, and that's the big focus behind it. So, that's big organizations, seeing that with Spark. I know of other telcos in Asia that also have done that whole reorganization of their business to the cross-functional—

Vodafone.

Vodafone is another one. Vodafone is another one. Westpac is another one, you know, both in Australia and locally that's doing that. I work with a lot of other banks in Asia. DBS is a very well-known example. ComBank I work with in Asia as well. A lot of these organizations are now, you know, sort of going through this. So I think it's some— you could say it's somewhat industry-based, like the banks are probably are moving faster. And also, not all of them necessarily, but a lot of them are. I think that sort of closely follows what I've seen described as like a disruption index. So the organizations that either are currently being disrupted or actually are aware that they could be are probably the fastest to move. The ones where perhaps there's less competition and less pressure are probably slower to move.

So that's really interesting because when we worked at a software vendor many, many years ago together, I remember the saying, you're either in e-business or you're out of business.

Yeah.

And it was the whole idea of, you know, with dot-com before it became dot-bomb, that, you know, if you didn't change and adapt, you wouldn't survive. And a lot of those organizations actually survived more than the the dot-commers. And so if I think about business agility, I was listening to a podcast the other day on it, and the people talking about it, they talked about Taylorism, right? They talked about the organizational structures we have today have come out of the Industrial Revolution, when we have factories, and when we wanted to make factories more efficient, we train people in specific roles, and then As we need to scale, we brought in managers and people at a high level make decisions, and we got the hierarchy of decision makers. And the point they were making on that podcast was, you know, for those organizations to change is incredibly disruptive. So, you know, I've seen ones where organizations that are large and behave that way try to do innovation labs, or they try to create a subsidiary. I mean, I suppose You know, one of the companies I love from a brand point of view in New Zealand is Powershop. They're owned by Meridian, so you kind of look at it and think, well, obviously Meridian spun off a small startup to disrupt the market without disrupting the way they work. But all those ones are out on the sides, right? They're not changing the core part of what that organization is and how it behaves. And then if I apply that concept of large organizations with very large hierarchies with lots of decision-making who are probably the least able to move towards an Agile paradigm. I call banks, right? You know, for me, it's, it's, I've worked with some of those banks, and even though we were doing Agile projects in there or Agile ways of working, we were pockets. We were small pockets that had to fit into the rest of the organization. So Do you think it's the fact that with the FinSec and all those startups that the banks are now looking and saying, actually, we do have to make a change, or the disruptors will disrupt us. They will Uber us. They will Netflix us. So we have no choice. But if that's the case, there must be turmoil in there to take away an organization that's worked with that many people for that long and somehow disrupt it without complete completely going to chaos.

Yeah, well, that's a good point. I mean, I wouldn't say that any of those organizations find it easy, but I think the other side of that is that, you know, once they've done that, I mean, I know people that work in some of those organizations, and they've moved into cross-functional teams, and it's sort of hallelujah, you know, we're actually now in a team where we've got everyone together to be able to get something done. We didn't have to go and get 5 levels of permissions from you know, from that manager and, you know, fill out 10 forms to do something. We can actually, if we've got a problem, we've got people here who can actually fix it. So, you know, at the grassroots level, you know, they may have been skeptical at the start of it because, you know, I think Agile sometimes can be pushed, you know, too heavily without the right understanding or context. But once people sort of realize that this is what it's actually about, it's about, you know, having a group of people together that can react quickly to a customer need and deliver value quickly, then they think, "Well, about time." So, I think that there is always going to be, when people roll this stuff out, concern about change. I think that's partly because we're not very good at doing it and we're not very good at receiving it as people. One of the big things that needs to happen with this is we're starting to see sort of more enlightened organizations like Microsoft, and I use them as a good case study of someone of, even though Microsoft you would say is relatively new, it's now an old software company like we came from it like Oracle. And they had their problems, but with a really smart CEO coming on board who realized that for Microsoft to survive and thrive needed to really change the way it went about its work. And so he has really instilled this whole concept of agility from a mindset perspective. So they have a big focus on the core principles that underpin agility. So, for example, what is an agile mindset or growth mindset using the Carol Dweck sort of terminology? So how do we Accept that we can grow, we can change. How do we develop the behaviors and the actions that allow us to do that? And when we do that as an individual, then as an organization, we can respond to change much faster. So when you start attacking the things that stop change, the things that stop people moving quickly, then it can happen. So Microsoft is a good example of a big organization, smart leader, are working with, you know, really good people below that. So he's got a very good HR group that is really looking at this from a systematic way. What are all the barriers that stop us from being innovative? So things like, and this is some of the common things we see, like what are the HR practices that a lot of organizations have that prevent us from being agile, moving fast, and working as a team. So things like performance appraisals, where those things have often been, um, somewhat punitive in some organizations, you know, they've sort of had the forced ranking, um, which has led to people being fired or, you know, promoted, um, and then sort of force in some Belka. Didn't matter how good your team was, you were forced into that sort of mode, um, and there were an annual painful event. So though a lot of organizations are moving completely away from that and moving to a much more dynamic sort of approach, you know, it's about having clear goals at a corporate level. You know, the OKR sort of model has become very popular amongst the high-growth companies, so that's objectives and key result areas. Having clear line of sight of what those are and then as an individual and as a team, being focused on them. And so that comes back to clarity of purpose as well. That's another key thing that I think a lot of people have lost sight of. So what am I here for? What is the purpose of the organization? And so good leaders really have that, provide that clarity.

Yeah, and I suppose those examples you used is where it comes from the top, right?

Absolutely.

And we might come back to that in a minute, but there's a really interesting one in there that you mentioned that I've never actually heard myself before, which is what I kind of picked up on is, you know, it's coming from the top and it's saying it's a culture change, which we know is hard, but actually what they sound like they were doing is taking more of a lean approach to processes, but not naturally going after the manufacturing type processes, not how we build software or how we, you know, service an account, actually looking at their processes that will stop a culture change happening. So actually being quite inwardly focusing, saying what internal processes do we have where we need to take more of a lean approach and remove totally wastage.

Absolutely.

And why do we do an annual review every year? You know, just because.

Well, exactly. I think, you know, like we talk about innovation a lot, you know, the innovation economy, innovative organizations. So one of the key aspects of innovation is to allow people to think, which is really where innovation comes from. You've got to remove the practices and the thinking that creates waste. So, you know, some really good research has been coming out recently which has shown that, you know, for average knowledge worker, which is, you know, what a lot of us are, we probably only spend a maximum of about 20% of our time doing valuable knowledge work. The other 80% is actually doing sort of tasks without any specific outcomes in mind. I'm not saying these things are not always important, but they're not always the most important. So part of this is to try and develop that sort of lean approach to work, which is, you know, by clearly understanding what— where my value is to the organization and how our organization creates value, Then I try and figure out, you know, like in the Agile sense of prioritization, what's my own backlog? You know, how do I prioritize what I do? Do I really need to attend that meeting? Do I need to block time out of my schedule to get knowledge work done rather than just be available all the time, which is what part of the issue.

So have you seen organizations sort of bring out agility in the business in other ways and What I mean is that you start with your traditional agile, your development shop, you bring in product owners, you train them how to act as product owners and represent the business, and then it spreads out rather than the top approach. Have you seen that succeed?

No, no, short answer is no. It's not that it can't, it succeeds to a point. But it's sort of like this, then the antibodies of the rest of the organization swarm around this Agile thing. So, you know, I think like everything, you're only as good as the weakest piece. So goodness will still happen, and being organic is good from the sense that people see the value of it and want to do it. But it's got to be embraced through and through. Because again, what I've seen happen is that that may happen, but if we're not looking at our HR policy, we're not looking at our finance policies to move away from this big bang multi-year project to a much more investor-like sort of funding model, then you're not really agile. This is part of what I see happening time and time again. There's sort of like these anti-patterns that that will come in and swarm around. And one of the common things I keep hearing from my customers is, this is all very well, but you need to talk to my manager, you need to talk to finance, you need to talk to procurement, you need to talk to HR, you need to talk to this, this, and that, and the other. And so this is what happens. It can happen, but it happens slowly. And it'll still stop at the weakest point. So if the finance chief doesn't get it and doesn't want to change, then that remains the bottleneck. So, if the HR manager doesn't want to change, then—

some value, but not as much as they should.

We've seen stand-ups pop up around the organization, and they think, you know, because we've been doing Agile for 3 years, that that's all it's all about. And they will have their morning stand-up, everyone would have a say, and then they'd go back to doing the same stuff.

And what I say to people is stand-ups have value, right?

Yes, communication.

To have communication on a daily basis about what you're doing, or even just how you're feeling, is valuable, right? It's better than doing it once a week, right? It's better than going into a room for 2 hours and having somebody talk at you for 2 hours, not actually ask the team to talk to themselves. So stand-ups have value, but stand-ups are not agile.

As long as you're not under the notion that you've got business agility.

Or even agile delivery, right, because you don't. I suppose one of the things I always struggle with is, you know, the majority of the organizations I work with, I get brought in to coach delivery team. And so one of the things, before I start that work, I kind of talk through with the stakeholders is how much business agility there is. Often I get, "Yeah, yeah, we're doing transformation," or, "We're going agile." What I know is that if there's not a business agility process going on, one of the first indications we get hit with is we never get given a product owner. We get a proxy product owner or an absent product owner because HR can't, you know, the HR processes, they can't come and work with of your team full-time for 3 months because that's an FTE shift. And so there's a whole lot of organizational issues around that. So what I say to them is, there is value in doing agile delivery, right? We will get value, we will get better, it will be better than not doing it, but we won't get the whole benefit until it's solved. And the second thing I've learned is that if there's not what I call my agile umbrella, If there's not a person above that delivery team who has mana or is senior enough in the organization to, I think what Aliya called it, you know, to stop shit flowing downhill, right, you know, if that's not in place, then actually we often fail because we're not safe. You know, we have, somebody can fly in and fundamentally disrupt and change the way the team are behaving and working and not allow them to to fail safely, iterate their own behavior. So for me, that's kind of, you know, I'm still not at a stage where I've been lucky enough to go into an organization that has true business agility and work from there, but I've got a bunch of kind of non-negotiables now, which is if I don't see the agile umbrella, then really we're all going to be unhappy at the end of this, so it's not worth my time and not worth their money. Do you find that? I mean, You're obviously lucky enough to go in at the right organizations at the right level and help them on that journey rather than down at that delivery phase.

Yeah, but it's still, I'd say, in your case, the umbrella at the moment, for most people, it's a little umbrella. It needs to be much bigger. That's just the reality. So, yeah, I mean, absolutely, I think that's normal for a lot of organizations. But I think the challenge in this is that this is an organizational-wide change program that they're trying to do. It's not an Agile transformation or digital transformation. It may be directed towards digital technology or whatever, if that's where they're going to get their competitive advantage, but to become a digital culture, which is really another sort of part of it, is quite a massive undertaking, you know, and it requires a lot of discussion, you know, and a lot of thought to do it well. Because it's all very well to say we're going to move to cross-functional teams, but, you know, that's going to disrupt a whole lot of people's lives. You know, people who've built their careers around being functional managers and what's their role going to be, you know, and if we don't think that through and we don't provide provide them opportunities to grow, and then the outcome of that, in my view, is always that they'll either actively or passively resist it. We get this concept that's sort of pejoratively known as the frozen middle, where a lot of middle managers, you know, which as Shane and I, you know, talked about, you know, they're actually— middle managers are actually super important. If you want to get innovation and deliver innovation, They're the ones that will enable or disable it because they're the closest to customer. So if you think about it, by leaving them out, we're actually probably not going to actually achieve what we want. So really focusing a lot of effort— and we've got to have the top support, we've got to have the people on the ground doing it— but if you don't put effort into that middle layer to help them be the ones that actually do this, then you're not going to get the fast returns. You're not going to get real agility.

And they're supplying the resources to the sprint teams too.

Exactly. So if they're seen as, if they are treated, you know, as part of this and provided the opportunity to grow, you know, to help them learn what this means, because this is quite a big shift in what they've done. So we've really got to retrain them around what is the role of a leader or manager in an agile organization. It's a much different type of role than what they may be used to. So, if we think about it, what, you know, if you think about the whole goal of the team is to deliver value fast. So, if I'm a manager, what am I trying to do? Make that team do that or help them do that. And that's not tell them what to do, that's get out of the way somewhat, but Provide the clarity about purpose and try and remove the things that— this is what, you know, being the person that shields them from some of the other stuff or goes and unblocks the issue with finance or wherever else. That's the role of an agile leader, is to help them make sure they understand what the purpose is, so be clear about what they're there to do and make sure they do that, but then remove the things that prevent them from delivering the value fast.

So where I'm at at the moment, because you kind of go, you've got a team lead, you've got a manager, right? So yes, yes, I need an Agile umbrella, but really that's a temporary role until the organization has business agility. That umbrella role is consumed by many other roles in an organization that's been through the change.

Wouldn't there be a lot of well-trained, skillful product owners?

Yeah, who, as Andy said, who found an impediment and helped the team Team unblock it. But where I'm at at the moment is the way I articulate it is that, you know, that instead of being a manager or a leader, there really is two roles you can assume. One of a coach and one of pastoral care. So pastoral care for me is, you know, your role is to work with people to make sure they're happy, safe, growing, right? You're there as pastoral care, right? You're there to make them successful with their personal and their work life, and they need that safety because, especially in a Scrum, you know, when you're— we call it a sprint, you know, but really it's a sprint, a marathon of sprints, right? It's a slog. It's a slog, right?

It's unrelenting in a way.

Yeah, it is unrelenting.

That's the thing, I mean, it's not easy, you know, every 2 weeks you're up, you know, you're up to deliver something, and that's pretty tough. It's tiring.

Yeah, so you need that pastoral care, right? You need somebody that's not part of that delivery delivery cycle that, you know, is going to look after you, help you look after your health and wellbeing. And so what that leaves is, yes, we have a Scrum, if we're running Scrum, we have a Scrum Master, right? We have somebody that helps the team iterate and unblock, run ceremonies, but we need those coaching roles, right? We need the people that can look at where the organization's going and help the organization and the teams kind of get better. From your point of view, is that, have you seen any other ways of articulating creating what that— I love that frozen middle. That's a great term. I'm stealing that one. You know, how can we make the frozen middle kind of have a purpose in life? Because those roles are really important. And we don't need to fly in new people. No. Right? We just need to help people morph what they do to one— in my head, to one of those two roles that they're good at. Typically, I'll see a person as typically a good coach or typically they've got pastoral care. Have you seen any other type of roles off the top of the head that you would be able to articulate?

I think those are good, I mean, those are good sort of descriptions in a way. So, again, if you think for like a functional manager, so let's just say that in a traditional software team, you've got devs, we've still got some testing, and we've got, you know, product owners, and, you know, and scrum masters. So, in the sort of more of those sort of agile organizations, there's still typically a line manager for those different areas, and they are more in the pastoral sort of sense, but not, you know, just, you know, they're thinking about what's the needs of— so how is that guild or whatever you want to call it, how do we make sure that we've got, you know, we're keeping up with the skills and, you know, and looking out for the things that are preventing us as team. So yeah, those things, that's a pretty important role.

Yeah, I'd hate to lose it.

But it's not about, you know, the difference there is not like, well, they're my team member and, you know, you can't have them, you know, which tends to be, you know, how it sort of still is to a large degree in a lot of organizations. It's, you know, that sort of ownership and then people fighting for resources. Or you have the people, which still can have to happen sometimes, but they're spread across a number of teams. Again, that's a reality. Some organizations are not big enough to have a product owner for every team. You may have to have that. So, again, we don't think we can be too pedantic about some of this stuff, but we need to be realistic about what that compromise might mean.

Because you're still going to have data standards that your organization wants to— data governance, um, totally best practice.

Yeah.

And, and so there's—

you're all using the words I hate, mate. Well, I saw it on a board. Things, but the words that come with those words come with a whole lot of committee behavior or default. I just, I just, I'm getting—

yeah, well, there's a lot of unagile or thinking that comes with that sometimes. We're trying to create— again, we think, well, what drives that? What drives that is that humans hate being criticized or punished or we avoid that stuff, right? So if we think about a lot of the organizations that we probably work in, they're not safe organizations. So government organizations are not safe. Whereas the public, you know, who who get jumps up and down about any expenditure that's not, you know, wise in their eyes. And we have politicians that will change their minds and also, you know, argue with each other and put a lot of pressure on. So government organisations by their own nature are not going to be safe to fail. So that creates almost by its nature that what sits around it this sort of behaviour. So it's hard, you know, because we can't change the mindset of politicians and, you know, the taxpayer sort of mindset overnight. You know, and that's the thing that makes government somewhat different than perhaps commercial organisations where a board of directors and the management can say, well, this is what the culture of the organisation is and this is what we want to be. They still have the stakeholders, they still have shareholder groups and all the other people, but there's different pressures in government perhaps. So, it's not easy things, but I think what we're seeing in other places where they're really adopting the agile mindset, we try and move away from think big to think small and acting quickly. So, that's what I talk, to me, agility is like, not thinking big. You may have a bigger vision about, or you may have to have a bigger vision about what you're trying to achieve, and it might take a while to do it, but then do it in small chunks quickly. And that's not in the DNA of a lot of organizations. So, we've got to break that down. And I think when that's done, because there are big organizations doing it now, so maybe they're not all in the government, but I know some government organizations organizations that are. It's possible. Big banks that have huge amount of scrutiny and financial regulations and massive fines if they get it wrong are able to do things in an agile way. So, if they can do that, so can any organization.

Yeah, it's just not about startups anymore, right?

Not at all. No, it is about a mindset. It's about let's, if we really want to become a fast-moving organization, we need You need to look at it holistically, treat it that way, and then figure what are the impediments to stop that. And it becomes an organizational business-wide, whole of business sort of focus, not just a little piece that's stuck in delivery and agile.

Yeah, or I think one of the things you said, right, you're not doing a digital transformation project that happens to be implementing agile, you might implement agile culture and an agile mindset. I like the agile mindset, actually, that's quite a nice term. So you're going to implement an agile mindset, which is a culture change, which will take time, and you may use your digital transformation program or change as the first cab off the rank to start that journey. So if you get approached by CEO, right, so CEO of an organization gets It's the new job, right? They rock up and they look at it and they go, I come from an agile mindset background, it's worked for me before, this organization can't, you know, it doesn't collaborate, it doesn't communicate, it doesn't change, it can't iterate. And they approach you and say, right, we want to make this change, you know, here's my lead team, you know, rather than get rid of them and bring in all the people I know, you know, which is an approach, right? Because actually, as much as I've never liked that behavior, if you think about it, bring the people with the mindset and then it will naturally cascade through the organization over time. But say they're not going to do that and they say, cool, here's the, you know, maybe because of your marketing background, right? Here's the Chief Marketing Officer. What would you say to them first? You know, when you're working with them and you're explaining the concepts, I'm assuming first giving them a bit of a framework of the the words, the terminology, and giving them a safe place to look dumb and ask those things in a safe way. What would you say next to them? What do you tend to— every customer's different, of course, but what would you say is the first thing to do, try?

Well, I think the first thing is to define are they happy with the way things are? Because again, we know from any sort of change through that If people don't believe there's a need to change, then they're not willing to do it. So, we've got to sort of start with the sort of beliefs and we've got to start with the facts, you know, from a business perspective first. So, you know, what is it about the current, you know, our current organization or the current way we're doing things that we're not happy with? You know, is it speed to market? It takes too long from an idea to an outcome. So what is that like, and be quite specific about some of this stuff. So let's find out how long does it take, so start gathering some information to build some facts around the current state. So I think that's part of it as well, is that we've got to start from a business base. At the end of the day, these are business people and they're making business decisions, so start from that. Not start with agile or anything else. They don't care about that. They want to really understand about how do I grow my business faster. How do I improve the efficiency? Or whatever the problem is, but let's focus on those problems and look at what we're trying to actually achieve as the first step. Then once we've sort of got clarity on what we're trying to do and where we're currently at, we can start looking at, let's try some different approaches. We would always start with— suggest we start small because there's two ways of looking at it. People say go big, you know, go big, go hard sort of thing. And, or you sort of start small and then sort of expand out. So, I think whenever people say go big, go hard, there's a huge risk involved in that because we don't really know, there's a lot of unknown unknowns in there. So, we would always suggest that we want to start small just to sort of figure out what works and what doesn't in our organization. And then use that as a way of— so incubate that sort of, so make it quite, you know, set up for success. But it's like a lab. We're doing that with the purpose of experimenting to see what works and what doesn't in our organization and what are the barriers and, you know, the good things that happen and the bad things as well. And embrace those from the point of view that that's realistic and real. but we then have a sort of backlog of items that we know we're going to have to start addressing if we scale it up. And if we haven't addressed some of them, then we might slow down. But we should move at the speed of, you know, that's realistic. I think the key part then is, so, have a business focus, start, you know, small or in a small area, test and learn from that. And we've also got a lot of communication. Communication on the why, not the how. A lot of people talk about agile as the how, you know, learn Scrum, we're going to do that. No, that's not important. That really doesn't matter. It's why are we doing this first. The need for change is the first thing we've got to get. Then the how has got to be context-based. So again, a lot of mistakes I see is that people start with Scrum. You know, Scrum, Some people think Scrum equals Agile. Well, it isn't. You know, it's one popular flavor of Agile that's widely adopted, but it's also very— has a whole bunch of premises that are quite difficult culturally for people to adopt. So, it's sometimes going to be the hardest thing you can do. So, that's good if you want to test that, but not necessarily if you want to get success. So, we should go in with a mindset of what's the right set of practices that support whatever we're trying to do. So if there's another set of agile practices, whether they're formally within the software or not, we would look to adopt those. So it could be Kanban or something like that.

Definitely. And so, you know, what I coach teams on is create your own agile BI way, right? Take valuable practice, which is the word I like to use now, so take patterns, right? One of the teams I'm working with right now, we're just experimenting with peer programming from XP, right, to change some things about the team and the way they're behaving together. Yes, there's a little bit around the quality of the code, but actually that's not the reason we're experimenting with it. It's to solve another problem. You know, often taking some lean or some Kanban approaches, or using more of a flow-based Kanban approach but adopting some of the Scrum ceremonies or release train or those kinds of things.

Scrum Ban, you know, again, it's context-based. So let's look at what we're trying to do and figure out the approach that's most likely to succeed. Sometimes we might start with one pattern, you know, one set of things first. If it doesn't work, we adapt. But I think where a lot of organizations get stale is that they don't, they just stay on their training wheels, you know, which whatever it was and don't move forward. That's not agile. Agile is Inspecting and adapting using terminology and figuring out better ways of working, which means that we're going to keep borrowing new ideas because Agile in its 15, 17 years now has come up with lots of new ways of doing stuff.

And every organization innovates on things that work better for them. I suppose when I look at that, so that's that, use the patterns that make sense to you right now and adopt and and change them over time. The bit that I'm missing, and I think it's kind of made me realize this, is I'm always focused on the how. I've intrinsically, because I've been hired to coach, there is a why, but I've never really articulated that, right? And so one of the things I've learned over time is that, you know, because normally it's an agile delivery team who first or second in the organization to start the journey. We actually need to start creating collateral that explains to the organization what we're doing, right? You know, a pitch deck, whatever you want to call it, but a way of describing this is the way we're working, this is the processes, approaches we're taking. And so—

The whys, to keep focus on the why.

Yeah, the thing I've kind of just realized is we never have a slide at the beginning of why.

No.

Why are we doing this?

Change?

We've got a vision workshop and we've got the—

Yeah, but that's for our delivery cycle. So we do a vision workshop of—

that's the vision for the project or the product, but not the vision for the team in the first place.

So, okay, so coming into the workshop with that statement already defined?

Well, no, no, just about the whole process. So normally, as I said, you know, there'll be an Agile umbrella. There'll be somebody who's willing to spend the money for me to come in and coach the team, and we've had a conversation on why they want this change to happen. But what we never do is we never write that down. We never articulate amongst the team or even definitely outside the team why are we adopting a completely new way of working. Is it because we want it to be faster, safer, cheaper, more fun? You know, if you see faster, safer, cheaper, you know you're in trouble, right? Because you know that yes, you might get that eventually, but for the first year you're going to get an anti-pattern for those three. You know, it's not safer for the team. At the beginning, we're learning how to work and new ways of working. It's definitely not faster, and maybe it's cheaper because you're fixing the cost.

Yeah, you should get, if you're doing it well, the cost, you know, there's sort of good cost curves that show you this as well. So, you know, the start point, it's not going to be cheaper, but where you get the big savings, or should get the big savings, savings is further down the track when the cost of rework or the cost of work that shouldn't have been done. That's where a lot of cost, hidden cost, comes into a lot of traditional waterfall projects is all the defects that come in and we fix them at the end, or the huge waste that's come in from features that people said they needed, they didn't really need.

Well, the de-scoping of the critical hard things that actually would have taken too long to deliver.

That's the hard value, but some of that stuff's hard to actually, you know, it's not easy to actually put a dollar and cents thing in. But I actually say that actually the real value of Agile is actually in speed to value. It's about, you know, if we're thinking in small, you know, the MVP type things, but, you know, real MVP, it's about how quickly can I deliver something, you know, to meet a customer need. That is the speed of agile, is having that mindset that constantly works in that way. The real value is in that, the cost of delay, minimizing some of that by actually getting and learning. Because we might stop it as well when we realize that actually that wasn't a problem that customers really cared about.

Actually, the cost of delay is a term that I kind of picked up on a podcast a little while ago. I kind of like that again. It's the cost of doing nothing. Exactly. So if we take 6 months, you know, there's a cost of doing that, but if we deliver something really early in 4 weeks, 3 weeks, you know, then there's 5 months and 1 week of using it, right? And so the cost of delay for that small piece of functionality or a small piece of value should be able to be quantified hard.

It's harder, but that's the stuff that we need to get, you know, when we're starting to look at business cases, starting to look at that, that's the value of Agile is is actually being able to quantify some of that stuff and make business decisions about, again, get good at not focusing on what we add, but what we don't add as well. Lean thinking should apply to software too. If we think about, that's exactly what Apple's done in there, is that they've really thought hard about removing stuff, not adding stuff. Otherwise, we end up with those hideous remote controls that came about from the old VCRs.

I'm looking around for one.

Because someone said it, we add another button. We as software developers do the same. The actual essence of a lot of agile thinking is less is best. That creates, the simpler it can be, the better, the faster.

Or the art of saying no. The number of times I'll start with a team and they're trying to deliver 3 products.

'And I'm like, you've only got capacity to deliver one.' Well, but then by Lean thinking, Kanban thinking, the work in progress, sort of getting more disciplined about not taking on too much, you know, again, that's all part of this as well. So that's why this is a big topic, it's a big area, there's a lot of aspects to it. To actually get agility requires focus on a lot of this stuff. But it's not, you shouldn't therefore, it's because it's hard or it's complex, completes shouldn't start. You should, but I think where I come back to is let's start from a business perspective to try and understand what we're trying to do. So, what is it about the current setup that's not working and treat it as that. So, we've got the clear why and then figure out, you know, tackle the biggest problems first and then figure out what's the appropriate practices. So, with the right mindset, we know why we're going to change, we know that we've You're going to have to change. Get some good advice about change as well, because this is a massive change thing. You can't avoid it. So, you need to get good at, when I say managing change, that sounds almost like you're being manipulative, but actually introducing change and getting people comfortable with it and becoming that as part of the organizational DNA.

Wrapping pastoral care around change.

And communication.

Yeah, communication.

Communication is the one thing you can't You know, if you do, it sort of costs you at the end.

And it can't be— it's got to be more of an agile approach to communication. It can't be once a month we're going to send out a newsletter.

No.

It's like it's got to be multiple channels, just in time, right, you know, different ways for me to consume it that fits my communication collaboration style and my availability.

A lot of it's just, you know, it's like, you know, for forums, so just giving people the opportunity of having interaction.

The demos are the biggest comms we try to do.

Yeah, come along and have a look. Exactly, but it's just interaction, you know, if you want to have people embrace stuff, at least give them the opportunity of understanding it, voice their concerns so you know in advance what they are, and then you've got a strategy for dealing with those.

And then come back to If there's not an agile mindset at the top table, then your chance of having business agility is a lot harder. However, you still can have agile capability, agile delivery, and agile automation and operations, which has value, right? It just means you won't reach the true potential of that organization.

Yeah, and I think I've seen a really— I saw a really interesting presentation from a guy who used to head up the head of agility at Barclays, so they're a big organization, you know, 350-year-old organization, 120,000 employees, so massive big organization. They're actually quite an impressive case study in agility. They've done a lot of smart things across the business to help them become an agile business. But he sort of presented their PMO, again, you sort of talked about that as a negative thing, but their PMO's journey from the traditional controlling, you know, budgets and, you know, policing of things to a guardian of value. That's really one of the things that they sort of— and so they help the organization understand how do you value things and how do you build cases that help people understand that, because I don't think we're very good at it. And then how do you measure it? So we start having— building this language of value in the organization. Organization. And part of that shift is moving away from big, thinking big, to thinking small. So, you'll get funded like a VC does, you know, in small stages to, you know, prove an idea, a lightweight business case, prove it, and then, you know, once you've delivered proof, you get more funding. And so, it keeps going in that sort of iterative model, not in a big bang.

It also means that when you ask for the next round of funding, you know more. You can answer more detailed questions because you've done some work. So I'm not against— so I just don't like the word PMO, Project Management Office, because it comes with a whole lot of project management behavior. If it was called the Agile Coaching Office or the Change Coaching Office or the Delivery Coaching Office, if it was called coaching office, because for me, having a group of people whose job or whose role it is to coach different parts of the organization and how to do do this well, with lessons learned, is, apart from putting me out of a job, it's valuable, right? As soon as you say PMO, it comes with a whole lot of baggage, right?

Sure, and some of those are changing. For example, they do change their title over time and realize that A, projects, we don't really want to be doing many projects, so that sort of model, you know, there's the whole no-project sort of philosophy, and that's more constant, you know, so it's more product-based or service-based and more continual sort of, you know, sort of changes to those rather than the, you know, one project, the team gets disbanded and we lose all the knowledge and off we go. So that sort of notion of project mentality has started to change to more continual sort of consistent persistent teams that work on something over time. But they may start as a project, so we're still going to have some element of that. That's okay, but not as a business construct in the same way that we see it now. Some of those organizations are now renaming themselves. There's different terminology, but I've seen like Value Delivery Office. That's quite a nice term that's about value delivery. Their focus is on helping the orders organization deliver value, which is ultimately something you can't really say shouldn't be what we're about. So, that's happening. We're working with clients that that's exactly what they're doing. They're transforming themselves from that to the to-be. But these things take time. I mean, that's one thing that I would also put is that if I look at the sort of lifespan of a lot of these organizations. You know, for a big organization to become an agile organization is a multi-year, and that requires discipline and it requires support from the board and from the, you know, a CEO that's got a really good agile mindset, and then sort of working it through the organization. And that takes multi-years. It doesn't, it isn't going to be one of those that happens It definitely is a multi-year thing. How many years is a function of the type of organization. As I say, I think government are going to be more challenged in some ways because of the political and other things. The speed of it is largely going to be governed by the ability to change the mindset of the organization and the people within it.

But it also comes back to what you said before, why are we making this change, therefore what does success look like? So it's never going to stop, right, if actually they become an agile business, they're going to iterate, they're going to change, they're going to consistently look at how they determine and add value, but there's a point where you can go, we've made the tipping point, right, for the why, the things we wanted to change, we've changed them enough that we can call that meeting our success or acceptance criteria. Just looking at time, I mean, I'd love to deep dive on OKRs because it's one that I'm starting to research at the moment that I don't have a lot of experience on, but I keep hearing it. So that might be another session. But just before we close out, so if somebody wanted to get hold of you, SoftwareEd, find out what you guys do, kind of approach you because they have come in with an Agile mindset and they need to make a change and they've agreed that it's not an overnight thing? What's the best way for people to get hold of you?

I mean, they can contact me at Softair, so andyc@softair.com. Happy to have a chat. I mean, I see part of my role as sort of an evangelist with this somewhat. Again, I'm just trying to help organizations and individuals embrace these ideas, but hopefully in a way that makes sense as well. I'm not trying to shove agile down their throat. Throats, you know, say you need to do Scrum, we'll start with the first principles first. But I'm always happy to talk to people about how, you know, I can share some ideas on things that I've seen work. I work with a lot of different organizations around the world, and I'm happy to share my insights about what I've seen working and not to anyone.

And I think that's one of the things when we talked a while ago that I found really cool was that that you basically, majority of your work is remote. You're coaching business stakeholders remotely on how to make this change, which is awesome. That actually, based here in sunny Wellington, you know, you can go and global domination is the goal. So look, that's great. I have actually figured out how to put stuff on the podcast when I publish it now, so I'll add links to the details to how to get hold of you. Hey look, thanks for that. That's, um, as always, we probably could talk for another hour or two and we might get you back again.

Um, but happy to talk about cars, that's a very topical—

OKRs are topical for me at the moment, so, uh, and, uh, yeah, once Blair's heard about them, I'm assuming it's going to be topical for him.

I'll ask about them shortly.

Yeah, I can put you some good stuff. There's a I'll send you a really nice short little guide on them that I can—

Well, we might wait. We might get you back for another podcast on OKRs and spend a good 30 minutes talking about those and do it that way, because like I said, they seem to be a good valuable pattern.

I think that's part of it. This is part of the answer. It's like everything, there's no answer. There's a series of things you can do, and the OKRs fit in helping people to align to the purpose and give you a line line of sight on how is what I'm doing aligned to what the business is about. And that helps me feel good about what I'm doing.

That's cool. All right. So we might catch it, wrap it up there. So we'll catch you all later for the next one.

Okay, cool.

Thank you.

Thank you. Thanks, Dale Kennedy.

Cheers.

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