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

And I'm Andy Cooper.

Hey 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 three 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 data ops 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 thing called business agility, which is enabling the organization to operate in a way that makes those delivery and data ops types of teams and approaches successful. For me, the easiest way I always explain it is with anti patterns. So 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 life cycle, or an organization where there's a large PMO with project managers, project managers and the Agile team somehow integrates with their fixed view of a roadmap for a while. So we hadn't caught up for a long, long time. So when we did, and as we talked through 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 I have 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 a lot of people 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 or known as Computer Associates big company. I was running quite a large marketing team, so not in it, an IT user. And one of the things that we did or we owned was the web, which obviously 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 process, 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 when 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 did. That's the reality of users. So agile seemed to me make sense. After leaving CA about eight years ago, I went to Soft Ed, otherwise known as software education. So by its nature we teach about, teach people about software. So Agile has been around now for about 18 years. So 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. And 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 thought this would be a good opportunity of again putting theory into practice. So as a 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 as a sort of user and.

As a delivery.

And the technical side of it as well, which is often undervalued. I see a lot of what I call fake Agile, which is sort of the veneer of Agile, but in a lot of cases it's just 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 put 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. So it 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 a business user and marketing in other roles. So, so look at it from that perspective as well. 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 see some of the benefits that you see some of the fast moving organizations, the Netflixes and the Amazons and locally the Zeros 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 this has got to be a whole business thing and the people that will influence that are our 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 and organizations now wanting to understand what this small agile thing is, what it means to them or is it still kind of in a very much an early adoptive phase where an 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. You know, they might just be the farmer watching the animals. What are you finding?

I think, you know, it's very, you know, different companies at different stages. So some have bought into it in a big way. We've seen some local examples like Spark has been.

Heavily guided by McKinsey who have a very clear operating agile operating model that they're trying to implement. So that's a C level, board level.

Sort of interaction and so they've got a very deep set of, you know, 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 you know, 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 tents. You know, they're using this butterfly type, you know, 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, yeah, Vodafone is another one, Vodafone.

Is another one, Westpac is another one 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. Commbank I work with in Asia as well. A lot of these organizations are now sort of going through this. So I think you could say it's somewhat industry based. Like the banks are probably.

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. And was the whole idea of.com before it became.bomb, that if you didn't change and adapt, you wouldn't survive. A lot of those organizations actually survived more than the the.com is. And so if I think about business agility, you know, 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 trained people in specific roles and then as we needed to scale, we brought in managers and people at a high level, made decisions and we got the hierarchy of decision makers. And the point they were making on that podcast was for those organizations to change is incredibly disruptive. So 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 one of companies I love from a brand point of view in New Zealand's Power Shop, 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. 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. For me, 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 organisation. 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 wouldn't say that any of those organisations find it easy.

But I think the other side of that is that 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 five levels of permissions from, from that manager and fill out 10 forms to do something. We can actually, we've got a problem, we've got people here who can actually fix it. So at the grassroots level, they may have been skeptical at the start of it because I think agile sometimes can be pushed 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 having the group of people together that can, you know, react quickly to a customer need and deliver value quickly, then they think, well, about time. So I think.

You know, that there is always going to be, you know, when people roll this stuff out, concern about change. And I think that's partly because we're not very good at doing it and we're not very good at receiving it, you know, as people. So 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 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, 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, 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. For example, what is an agile mindset or growth mindset using the Carol Dweck 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 changes 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, and get a smart leader working with really good people below that. So he's got a very good HR group that really is 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 somewhat punitive. In some organizations they've sort of had the forced ranking which has led to people being fired or promoted and then sort of forced in some bell curve. No matter how good your team was, you're forced into that sort of mode. And they were an annual painful event.

So a lot of organisations now are moving completely away from that and moving to a much more dynamic sort of approach. It's about having clear goals at a corporate level. The OKR 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 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, that you mentioned that I've never actually heard myself before, which is what I kind of picked up on is 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 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 wastage.

Absolutely.

And why do we do an annual review every year? Just because.

Well, exactly. I think we talk about innovation a lot, 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 some really good research has been coming out recently which has shown that for average knowledge worker, which is a lot of us are, we probably only spend a maximum of 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.

By clearly understanding where my value is to the organization and how our organization creates value. Then I try and figure out like in the agile sense of prioritisation, what's my own backlog, 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 part of the issue.

So have you seen organizations.

Bring out agility in the business in other ways? And what, 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. The short answer is no. It's not that it succeeds to a point, but it's sort of like then the antibodies of the rest of the organization swarm around this agile thing.

So 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 so that, 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. And this is part of what I see happening time and time again. We're sort of like these anti patterns that will come in and swarm around and one of the common things I keep hearing from my customers is this is all right, well but you need to talk to my manager, we 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 and doesn't want to change, then that remains the bottleneck. Manager doesn't want to change some value.

We've seen stand ups pop up around the organization and they think, you know, because we've been doing agile for three 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 yeah, doing the same stuff.

And what I say to people is stand ups have value, right? 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 two hours and having somebody talk at you for two hours, not actually ask the team talk to themselves. So stand ups have value, but stand ups are not agile.

As long as you're not under the, 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 the majority of the organisations I work with, I get bought 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. And, and often I get, yeah, yeah, we're doing transformation or we're going agile. And 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, right? We get a proxy product owner or an absent product owner because HR can't, the HR processes, they can't come and work with your team full time for three 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, we'll 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 Elio 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 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 you're obviously lucky enough to go in at the right organisations at the right level and help them on that journey rather than download that delivery phase?

Yeah, but it's still, you know, 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 and 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.

It requires a lot of discussion and a lot of thought to do it well, because it's all very well to saying we're going to move to cross functional teams, but that's going to disrupt a whole lot of people's lives.

People who have built their careers around being functional managers and what's their role going to be 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. And we get this concept that's sort of pejoratively known as the frozen middle, where a lot of middle managers, which as Shane and I talked about, 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 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 support 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 as part of this and provided the opportunity to grow to help them learn what this means, because this is quite a big shift in what they've done.

We 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, if you think about the whole goal of the team is deliver value fast. If I'm a manager, what am I trying to do? Make that team do that or help them do that? 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 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, 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 go, you've got a team lead, you've got a manager, right? So 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 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 articulated 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, there to make them successful with their personal, their work life and that's. And they need that safety because especially in a scrum, you know, when you, 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.

And so you need unrelenting in a way.

It is unrelenting.

That's the thing. I mean it's not easy. You know, every two 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 deliver delivery cycle that is going to look after, 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 and 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 organisation and the teams kind of get better. From your point of view, have you seen any other ways of articulating. I love that frozen middle. That's a great term on stealing, that one. 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. We just need to help people morph what they do 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 good pastoral care. Have you seen any other type of roles off your 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 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 product owners and scrum masters. So.

And they're 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, you know, 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, 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.

But it's not about, you know, the difference there. It's not like, well, they're my team member and, you know, you can't have them, you know, which is tend 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 the reality. Some organizations are not big enough to have a product owner for every team. You may have to have that. So 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, totally best practice.

And, and so those.

You're using the words I hate.

Well, I saw 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 lore, you know, thinking that comes with that sometimes. And it's, you know, we're trying to create, you know, again, we think, well, what drives that. What drives that is that humans hate being criticized or punished or, you know, 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 wise in their eyes. And we have politicians that will change their minds and also 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 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 organizations where a board of directors and management can say, well, this is what the culture of the organization is and this is what we want to be. They still have the stakeholders, they, they still have shareholder groups and all the other people. But there's different pressures in government perhaps, so there's not easy things. But I think what we're seeing in places where they really are adopting the agile mindset, we try and move away from think big to think small.

And acting quickly. So that's what I took. To me, agility is.

Not thinking big. You may have a bigger vision about or, you know, 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 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 that now, so maybe they're not in the government, but I know some government organization organizations that are, it's possible big banks that have huge amount of scrutiny and Financial regulations and massive fines that get it wrong are able to do things in an agile way. So if they can do that, so can any organization.

Yes. It's just not about startups anymore.

Not at all. No. It is about a mindset. It's about let's if we really want to become fast moving organization, we 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 ranks to start that journey. So if you get approached by CEO, right? So CEO of an organization gets the, the new job, they rock up and they look at it and they go, I come from an agile mindset background that's worked for me before. This organization can't, it doesn't collaborate, it doesn't communicate, it doesn't change, it can't iterate. And they approach you and says right, we want to make this change. Here's my lead team.

Rather than get rid of them and bring in all the people I know, which is an approach 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 on achieving 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 is different, of course. But what would you say is the first thing to do? Try?

Well, I think the first thing is to find are 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 from a business perspective first. So what is it about the current organization or the current way we're doing things that we're not happy with?

Is it speed to market? It takes too long from an idea to an outcome. So what is that? And be quite specific about some of this stuff. So let's find out how long does it take, 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 business people, 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 or 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. Some people say go big, go big, go hard sort of thing.

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 incubate that sort of. So make it quite 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 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 that's realistic. I think the key part then is.

So have a business focus, start small or in a small area, test and learn from that.

And we've also got a lot of communication on the why not the how. A lot of people talk about Agile is the how learn Scrum we're going to do. No, that's not important. And 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, some people think Scrum Eco is our job. Well, it isn't. It's one popular flavor of our job 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 sometimes can 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 principles, 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.

And so what I coach teams on is create your own agile bi way, 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 to solve another problem. 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 releases train or those kind of things.

Scrumban, 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, don't move forward. That's not agile. Agile is, you know, 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 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 because normally it's an agile delivery team who are fairly 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. A pitch deck, whatever you want to call it. But a way of describing this is.

The way we're working.

This is the approaches we're taking.

The why is 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. Why are we doing this change?

We go 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 project, but not the vision for the team in the first place.

Okay, so coming into the workshop with that statement already?

Well, no, no, just about the whole process. So normally, as I said, 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. Yeah, 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.

And that's where a lot of cost, hidden cost comes into a lot of traditional waterfall projects is 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 descoping of the critical hard things that would have taken too long to.

That's the hard value. But some of that stuff's hard to actually. It's not easy to actually put a dollar and cents thing in. But I actually say that the real value of Agile is actually in speed to value. It's about if we're thinking in small MVP type things, but real mvp, it's about how quickly can I deliver something to meet a customer need. And that is the speed of agile is having that mindset that constantly works in that way. And so 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 and realize that actually that wasn't a problem that customers really cared about.

That cost of delay is a term that I kind of picked up on a podcast a little while ago and I kind of like that again. Right, is that it's the cost of doing nothing.

Exactly.

So if we take six months, there's a cost of doing that. But if we deliver something really good in four weeks, three weeks, then there's five months and one week of using it. And so the cost of delay for that small piece of functionality or that small piece of value should be able to be quantified hard.

It's harder. But that's the stuff that we need to get when we're starting to look at business cases, starting to look at that 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. So lean thinking should apply to software too. If we think about that's exactly what Apple's done, is that they've really thought hard about removing stuff, not adding stuff. Otherwise we end up with those hideous remote control that came about from the old VCR I'm looking around for.

Because someone said it, we Added another button. Well, 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 artists say no the number of times I'll start with a team and they're trying to deliver three products and I'm like, you've only got capacity to deliver one well.

But Baleen thinking, you know, combine 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. Shouldn't say 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're going to have, 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 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.

Communication is one thing can't really skimp on, 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, you know, multiple channels just in time. Right. You know, different ways for me to consume. It fits my communication collaboration style and my, my valuability.

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

Biggest comms we try to do come.

Along and have a look. Exactly. But it's just interaction. 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.

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 Barclay. So they're big organization, 350-year-old organization, 120,000 employees. So massive big organization. And they're actually quite an impressive case study in agility and 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 budgets and policing of things.

To a guardian or 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 building this language of value in the 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 in small stages to prove an idea, a lightweight business case. Prove it and then 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 going to get. So I just don't like the word pmo. Project management office, right, 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, 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 this well with lessons learned apart from putting me out of the job, it's valuable, right? As soon as you say pmo, it comes with a whole lot of baggage.

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, there's the whole no project sort of philosophy and that's more constant so it's more product based or service based and more continual sort of changes to those rather than the 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 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. So some of those organizations are now renaming themselves. There's different terminology but I've seen value delivery office so that's quite a nice term that's about value delivery. So their focus is on helping the 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, for a big organization to become an agile organization is a multi year and that requires discipline and requires support from the board and from 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 isn't going to be one of those that have overnight things. It definitely is a multi year thing. How many years is a function of, you know, the taboo organization. As I say, I think government are going to be more challenged in some ways because of the political and other things.

And you know, the, you know, the speed of it is largely going to be governed by the, you know, the ability to change the mindset of the organization and the people within it.

But 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 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 for the why the things we wanted to change. We've changed them enough that we can call that meeting our successful 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 software ed, 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@soft andycfd.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 say you need to do scrum. Start with the first principle first. But I'm always happy to talk to people about how.

I can share some ideas on things that I've seen work. I've worked 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.

I think that's one of the things when we talked a while ago that I found really cool was that basically the majority of your work is remote. You're coaching business stakeholders remotely on how to make this change, which is awesome actually based here in sunny Wellington. 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 to the details to how to get hold to you. But hey, look, thanks for that. Let's as always, we probably could have talked for another hour or two and you're back again.

But happy talk about cars. That's very topical.

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

I'll ask about them shortly.

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 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 that. This is part of the answer. 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 light, you know, line of sight of how is what I'm doing aligned to what the business is about and, you know, 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 catch you all later for. For the next one.

Okay.

Thank you.

Thank you. Thanks, Ken.

Cheer.

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.