Heath:

Welcome to the Business Transformation Podcast. I’m your host,Heath Gascoigne. This is a show where I cut through all the hype and noise and get to the facts of what actually is business transformation and what is required, how to and how not to do it. I’ll be talking to industry experts and professionals to share their stories, strategies, and insights to help you start, turnaround, or grow your business transformation. By the end of this podcast, we have some practical tips to use to make your business transformation a success. Whether you’re just at the start of your journey or midway through, I hope you enjoy.

Heath: Hello, welcome to the Transformation Podcast. I’m your host, Heath Gascoigne, and this is the show for business transformators who are part business strategists, part business designers, part collaborators, and part negotiators. Business transformators have moved past just business design and includes oversight of implementation of those business designs and business transformations and includes stakeholder management, coordination, and negotiation. If you work in strategy development and implementation and you work to ensure that it is aligned to the business design and technology, then you’re probably a business transformator. This is the show where we speak to industry experts and professionals to share their stories, strategies, and insights to help you start, turn around, and grow your business transformation.

Welcome to the Business Transformation Podcast and in this episode, we’re talking to one of those experts. We are speaking to Peter Lie. Peter Lie is the current Director Consulting/Head of Business Agility and Consulting Practice in Germany for CGI. He is an agile coach at the Expert Agile Club, an agile trainer at Trendig Technology Services in Germany, who sets trends and designs digital transformation through innovative engineering knowledge and events, and a SAFe Agile organization coach and trainer for Media Group Germany, and previously held many senior Agile coach roles and positions, now spending over 10 plus years including senior consulting roles. Peter, it’s a pleasure to have you on the show. Thank you for your time. How are you?

Peter: Thank you. It’s good to be here and that was a very nice summary. I wasn’t even aware I have done that all. But it’s good to hear from you.

Heath: Well, that’s a summary. There’s a lot there, I could have gone on. So, yeah, there is a lot of history, a lot of experience you’ve got there, Peter. So, what we’re gonna do, we’re gonna keep it short, or keep it focused, rather, on our topic for interest of time, because we could talk about a lot of things, and for the interest of the users, the listeners, we’ll keep it to three things, the agile manifesto, I think there’s a conversation near around about it was developed some time ago and have we shifted away from it? Are we still agile? Does it need updating? Does it need review? Or has there been manifesto 2.0? So second is the agile culture. That’s a big thing. I’m a big advocate of culture, I think, and in this world, what we are now, the work from home culture, which I just saw a big announcement from a big finance company to say that, although they made an announcement some time ago, a few months ago, that they’re all working from home, it’s now they’ve given a drop dead date that everyone needs to be back in the office. So this culture, I think, is becoming more people are more aware of it. That’s like a competitive advantage if you do it well. And the third part, the psychological safety. Now, why I wanna about safety is because in culture and behavior, the people act and behave a certain way and when they feel they cannot, due to safety concerns of whether it’s, you know, in architecture terms, in terms of patterns and certain patterns have a certain type of behavior because it has a certain result, when you have the opposite being anti-patterns, which we’ll talk about in more detail later, some things aren’t discussed or some things aren’t done but they are reported as done and that has other knock-on effects, all to do with culture. Okay. So, to get us started, now, let’s refer to what we’ve faced, everything goes to get us to this point in terms of agile is the holy grail of agile, the Agile Manifesto. So, tell us about that manifesto, Peter. It was developed, what? 20 years ago? And now we are 2022, which is now when we’re in the new century, this was developed at the end of last century. Are we still true to the manifesto?

Peter: That’s a very good question. The manifesto, indeed, last year, it was 20 years old. It was celebrated globally with a lot of events. And if you’re still looking at the manifesto, like the four values and principles, I think it’s still valid, no doubt.

Heath: Yeah.

Peter: What I’m also thinking of, I think that’s a very popular discussion within the agile community is do we need to fix value? We need to expand with what we have learned in last 20 years. And let’s say you haven’t been asking me yet but I would definitely laugh, and that’s, of course, related to the topic we are discussing tonight, mindset over culture. That would be value I would love to add.

Heath: Yeah, mindset over culture.

Peter: Yeah. The main reason is we have a set of values we all understand but what we are forgetting is we have our own interpretation, which is related to culture. So this is the connection. This is where we have to add some stuff

Heath: I teach, as I wrote in the book and teach the students around about they get caught up in doing things intervally, which is let’s say correct by agile terms, but it’s more first the mindset of doing things intervally. And so first you have the mindset and then you behave the way that your mindset will direct you. But, yeah, the mindset is a big thing. Yeah, there’s a conversation about, they say is agile about scrums or Kanban board or is it a framework? First and foremost, I think it is a mindset, a mindset change from the way things are done.

Peter: That’s right. What I see in daily life with colleagues but also with customers is we have a pretty good understanding of what is agile. We have a pretty good expectation from each other what we want to see. But when I’m talking to guys who grew up with, let’s say, SAFe, this is just an example, they have a different mindset. It’s slightly different how they see agility and how it should be implemented within a company. When I’m talking to other guys who are related to Nexus, Scrum@Scale, their approach is also different. So, it is interesting and it’s not about good or wrong but it’s more about okay, how can we bring these parties together so we have a better understanding of what does it mean for us in general?

Heath: Yes. Yeah, that’s like the term business transformation means different things to different people so does agile. It’s getting that common language and agreed terminology — yeah, yeah.

Peter: Yeah. I think that’s a very good flashback, yeah, gone from where we are now back to this business architecture, what’s happening exactly there and how can you use it. Now, I’ve read your book —

Heath: Oh, thank you.

Peter: — stuff and you’re also mentioning culture in your book but it’s not yet in a, let’s say, in a very granular.

Heath: Yeah.

Peter: That would be nice for the next —

Heath: Well, you’re gonna let the cat out of the bag if I tell you that part.

Peter: That’s right. But if you’re talking about culture, so I have read some other books —

Heath: Can you recommend some that you might have read recently around that?

Peter: So there’s some Erin Meyer, she has written The Culture Map, which is —

Heath: Erin Meyer, The Culture Map.

Peter: She’s an American. He’s a professor at INSEAD and she lives in France. Now, her study is not related to agile. I would love to give you a couple of examples —

Heath: Yeah, sure, thank you.

Peter: — very much related to what we do. So in teams, we are always talking about communication and she is mentioning we have this low versus high context. A low context, what does it mean? Good communication is precise and simple and clear. Messages are expressed and understood at face value. High context is good communication is sophisticated, nuanced, and layered and messages are both spoken and read between the lines. This is very different. But if you look at low context, for example, the US, Netherlands, Australia, so we have a good understanding, Germany as well, and it’s also part of the low context so we understand each other quite easily. If we’re going to the high context, you’re talking about China, Japan, Korea, Indonesia, and understanding each other is much, much more difficult. Have you some experience with low versus high context?

Heath: Oh, yes, very much. Yeah, so, I wouldn’t want to say separate the globe to make the comparison but let’s say in England, UK, well, there will be typically I think, you said, yeah, low context, you know, a spade’s a spade, you’re very clear, very concise. It’s like for the four styles of communication. Arrow, you know, it’s said and received in the same way that it’s said, or, you know, the circuit was the three types of communication, the circuit, where it’s almost you say it and it’s received and reiterated back to you to confirm, and then the dance is where it is almost the other person complete your sentence for you because you’re so sync of what you say, they can understand you clearly and completely, there’s no ambiguity, there’s no misunderstanding. Now, I think that is — and it’s the Anglo Saxon cultures, that would be pretty understandable and common practice. Maybe in the Asian, where you have different versions of dialect or the semantics of the languages, so let’s say, the minute changes mean big changes to the meaning. And so the complex, for example, I have, you know, when you’re dealing with offshore resources in India or in Asia and then when you say something, it can be conceived in so many different ways. And where that results to is like playing golf where you make a subtle change to the face of the club and you take the same swing but now it’s misinterpreted and it goes out miles away from where you want it to, intended to, just by that subtle little change. Yes. So, you know, I’ve experienced that. Yeah, I can — yeah, so the application of understanding the context in an agile environment is first understand the context you’re in and have appreciation of it, and that you may need to maybe adapt your style of communication to that context, otherwise, you will probably get the wrong result.

Peter: Absolutely. Absolutely. And your goal, for example, is pretty much a query. It’s exactly what is happening, just a little touch of different behavior and you may not be as successful as wanted.

Heath: Yeah, that’s the subtle little change and that was all it took.

Peter: Yeah. The funny thing is Erin Meyer, she has a matrix in her book and it’s called the Anglo Dutch Translation Guide —

Heath: Oh, really?

Peter: — you are in UK so maybe you are already used to how the British people are using the language. So, I’ll just give you an example. If the British, when they are saying, “With all due respect,” —

Heath: Yes. Yeah, yeah.

Peter: — the Dutch people, we think, “Oh, he’s listening to me.” It’s meant, “I think you’re wrong.”

Heath: Yes. That is right. Yeah, that is right. Yeah. Yeah.

Peter: And another one, which is fantastic because we’re using this so much when the British are saying, “Very interesting,” the Dutch people, they think, “Oh, wow. He’s impressed.”

Heath: Yeah.

Peter: Meantime, what you’re trying to tell me is, “I don’t like it.”

Heath: Yeah. Yes. That is exactly it.

Peter: It’s a fantastic tool but you have to be very, very careful.

Heath: Yeah. Politically correct in its application. Yeah, yeah.

Peter: Absolutely, yeah —

Heath: Okay. So, Erin Meyer, everyone, so the listeners out there, The Culture Map. Okay, that was the Anglo Dutch Translation Guide. It’s not that — she is Dutch, is she? No?

Peter: No, she’s American.

Heath: And she spent some time in Germany, was it? Or France?

Peter: France.

Heath: Was it Dutch because Dutch is — I don’t know, is it because their culture is so different that they interpret things in a certain way or maybe they have a good-natured culture and they don’t think people could be either rude or condescending so they always think the best of everyone?

Peter: I’m not sure. But one thing is for sure. Compared to the British people, you know, the Brits, they have a very sophisticated way of expressing themselves. Use with their language, and we don’t. So if I’m giving feedback, I always hear from colleagues, “Oh, that’s very direct.”

Heath: Yeah, yeah.

Peter: “I know. Sorry.”

Heath: But, you know, there is — I think that goes to the style of communication as well, speaks to that, there’s the direct or arrow approach. But, yeah, there is always the pro and con or two sides to every situation or coin. In the arrow approach where the assumption is that the message is received in the same way, manner, and tone that is sent. And so there’s maybe a bias or perception from the sender that, “Oh, so I’ve said it and they received, they’ve now heard it and understand it the way I said it.” But that is the, let’s say, maybe the gap, that, no, actually, it wasn’t received the way you said it and, therefore, it was misinterpreted and then they took it in their own understanding and they did something else with it and you didn’t get the result you wanted.

Peter: Exactly. You know, also within Erin Meyer’s book, she has a couple more of these topics, I won’t go through all of them, but I have another example which is also very much related to what we’re doing with agility and that’s about evaluation.

Heath: Evaluation?

Peter: So, here, she’s talking about direct negative feedback on one side of the X, or indirect negative feedback. And with direct negative feedback, she’s saying negative feedback to a colleague is provided frankly, bluntly, honestly. So think of the Dutch, indirect negative feedback to a colleague is provided softly, subtly, diplomatically. That’s, of course, main difference. And if you look at the Xs again, it is saying Germany, Netherlands —

Heath: Oh, the plotted countries, she’s plotted countries, okay.

Peter: Yeah. All on the direct negative, but also Denmark and France and even a little bit towards the Middle East, Italy, Australia, Spain so that’s good for you. If you go to indirect negative feedback, you’re talking about Japan, Thailand, Indonesia. Now, I’m not surprised. My father’s from Indonesia so I can imagine totally the way how they’re providing feedback. And, for me, growing in the Netherlands is like guessing what a guy’s talking about. How do I need to understand this?

Heath: Okay, so this is really around, and as I said in the intro to the podcast, is business transformators have moved past just design, because this is, you know, there is, I’ll say, standing on the shoulders of giants, that business — my book framework is around business architecture but it’s more than just design and you can’t get a design, you know, the target operating model design built and implemented just by having technical people create it. It needs to be managed and implemented by people. And so you need to negotiate with people. And part of that negotiation and coordination is all encapsulated around stakeholder management, and stakeholders around people. Now, how I see that being important there about the direct feedback is this is all part of the stakeholder management, understanding of stakeholders, the communication, like these four causes of transformation, well documented, well researched, you know, a lot of surveys out there that go out every year. Gallup does one, McKinsey does one, Gartner does one, almost every industry body does one, and they they’re still reporting the same thing. The four main causes: lack of business user involvement, lack of senior leadership support, changing requirements, and incomplete requirements. And all of those are to do with people. It’s a psychological problem, not a technical problem, not a process problem, not a technology problem. It’s all to do with people. And that part there you’re talking about is all about people.

Peter: Absolutely true and that’s why this makes it so interesting, the cause part. So, how do I experience the working collaboration with people in my mind but also taking the Agile Manifesto again, as that’s our starting point, and on paper, we all agree this is good, we all understand what they’re talking about, but how are we going to execute this in daily life? And talking about this business architecture, it’s so important to get through all hierarchies the commitments and the feedback because that’s all we want —

Heath: Oh, yes, yes.

Peter: — we can adapt and inspect and adapt. But this is still kind of, let’s say, failure within Agile transformations, which I’m seeing where they are implementing a model and hoping the model is going to prescribe your cultural change, which is not going to happen.

Heath: Oh, yeah, that’s the key part there. Actually, we have on the podcast soon to come out about transforming the culture. Not only are you transforming the business but, in some cases, you’re also transforming the culture. And so how do you measure culture? That’s a pretty tricky thing to do the way we do things around here, and so we’re actually that was Vikas from Gallup, that was his episode we covered there about transforming the culture. Yeah, because that culture is hard to define but it’s summarized as this is the way we do things around here. Nothing is written — well, it’s more it’s the unwritten rules.

Peter: That’s right. Absolutely. It’s also how they define culture in in several Wikipedia. It’s the way how we do things here, so meaning you will not find the written handbook telling you how we are doing the things here —

Heath: Yeah. They’ll have probably a standard operating procedures book, some processes that are documented, but as you said earlier about the context, sophisticated context, that the gray, reading between the lines, and so although the policies and procedures are written, is the way they do things that is in between the lines.

Peter: Absolutely. Now, do you remember Yoda? Master Yoda?

Heath: Yes, yes.

Peter: I love Master Yoda.

Heath: Yeah, yeah, he’s cool.

Peter: And I’m using Yoda as well in my trainings but also as a poster, his slogans are really cool, and one of his most famous slogans is “Unlearn what you have learned.”

Heath: Yeah.

Peter: So, meaning, when I’m coming to a new company, we have a new company culture, we have a new way of working, and, of course, you know, 50, 60 percent of what we’re doing is quite similar to what I’m doing now but the way how we move intercultural is different and what I have learned, let’s say, now, when I move along, I have to forget and try to learn the new culture, and this is exactly where people are not willing to —

Heath: Yeah, unwilling, yeah.

Peter: — and being open, being transparent to absorb all the new stuff.

Heath: Yeah, I think that’s why we didn’t get to our third point, which I won’t get on to that about safety, about — yeah, about behaving in a certain way because that’s the way we’ve always done it around here. Despite the fact that, in most cases, when they call in consultants or they stand up a project to transform the business, they’re transforming the business because there’s a problem and a problem that’s been created and — this is like the current client I’m helping out right now, they told me that they’ve got this one big project process and then it’s morphed into so many and they want me to crush it together and then digitalize it and I said, “Are you sure that’s what you wanna do?” and they said yes, so I said, “But what you’re actually doing is you are, with these projects, doing two things: creating or enhancing existing capabilities, which will, if you do a good job, is gonna make money for the business and it’s gonna save the business, make money for the business, or it’s gonna save the business and cost money every single year. But if you do a really good job, not only will they make money, but you will be able to reuse those capabilities and do it quicker, cheaper, faster, less risk, more predictability, which you have a big thing as you’re making your number one KPI about predictability, and then move the ship,” and they said, “That’s what we wanna do.” I said, “But that’s not what you asked. You are wanting something completely different,” but part of that is changing the way they work. And this comes to culture shift. To your point about safety, people are too scared now to — and I think, generally, people are scared when they had certain ways of working, got a certain result, and now they are asked to do new ways of working but it needs to be within a new paradigm, a new safety maybe regime that’s created so that they feel secure that they can behave in this new way, otherwise, partly the reason of project transformation failure is because of people, business user involvement, change leadership and changing and incomplete requirements, is that the people struggle with the change.

Peter: Yeah, absolutely. What I see is — so, luckily, I’d say we are working in smaller teams. The smaller teams are of course part of a larger team but there is a drop down to scrum team level, so to speak, where people are involved. And if you’re lucky and you have this open, transparent communication and you have the safety, so this is an assumption, then people of all layers will be involved and if you’re talking about business transformation or business architecture, where we do we want to go and grow and let’s take, for instance, the business model canvas, value proposition canvas, where we can work together and think of what we are doing now, how does it need to look in a couple of months or one year so what change we have to go through. Then, I think you have reached a very good starting point of safety or maybe for most companies, that’s already an ending point, like, “Whoa, if we can get here, it will be fantastic,” and exchanging the information with different layers of people in the hierarchy would be really good. Everybody is smart. Everybody has an idea. Of course, together, we can come up with even better ideas. But this safety, that’s a big question mark.

Heath: Yeah. I think that ties into what you talked about the context, like I talked about in the book and also in other articles I’ve published about the three layers in organization. The three L’s: layers, language, and levels. So, the different layers being strategy, that’s one layer, operations is second, and implementation and projects is the third. And every one of those layers has a different language. At strategy level, they’ll do macro and financial and the big picture market competitiveness. That’s what they’re interested in. Operations have a different language. They’re talking about a turnover, sales, days off, you know, what their churn rate is, and then down at project and their language, they’re talking in terms of process mapping and Kanban boards and points and story points and developers and their code. And the level of detail is also different. And so big picture up the top in strategy, medium level in operations, and then very detailed with code, you know, very, very detailed down the algorithms, etc. So, understanding that context is part of it, and that’s, you know, I think probably technology consultants get the wrong end of the stick but they come in and they talk another language that only they understand. They haven’t, let’s say, assimilated to the business, have understood the language, they speak in another language and what happens is the business will go, “I don’t understand what they’re saying but if we just not our heads a little bit, they’ll finish talking soon and then, soon enough, they’ll leave and then we can get back to the way things were before.”

Peter: I think the difference in language, that’s a Roman example of engagement. You’re not engaged. So like we have two or at least two groups of people, and it might be much more, I wouldn’t be surprised if it is not only technology but it’s also business, people don’t really understand the language and they are trying to convince, they are trying to collaborate, of course, information. On the other hand, just taking more time to being engaged and understanding that would really help. So we don’t have to go different or a difficult language.

Heath: Yeah, yeah, common language. Yeah, I have — one of the first activities that I have in my approach is that after the statement of work and then agreeing to the vision, which generally that in itself gets everyone on the same page, everyone talking, not so much talking the same language but heading in the right direction. But then the glossary, there’s making sure that you’ve got your project glossary. Now, I’ve worked on pretty major UK government program and this is I think where the glossary goes wrong is that a lot of people will decide that we’re gonna put every single term that was ever invented in this business, not just this transformation, but the entire business, even if there’s parts from other projects that are now defunct and closed and finished. I had over 700 terms on the glossary that I had to maintain and I had to fight, what’s the term? Hand and fist to get them out of the glossary so only if it’s used, only if these terms are used and, most importantly, if it’s a contentious term, then it needs to be in this glossary so that we get that common language. Case means the same thing in the operations as it does in implementation as it does in strategy. And that one particular project, the case managers would manage the pieces of work but they’re called cases, and the guys in the project will say, “That’s called service delivery.”

Peter: Yeah.

Heath: And so they renamed what the business did and the business said, “They’re not listening to us.”

Peter: Yeah. You know, I started laughing when you were talking about glossary. Also wiki, yeah? That’s another phenomenon where people start investing a lot of time in writing their wiki, does it cover everything, but that’s so classic approach. I think Google is the new wiki.

Heath: Yeah.

Peter: You know, you can Google, and it’s not about the wiki. It’s about showing understanding. We understand each other. That’s it. And, yeah, maybe they have to call you a couple of times just to make sure we have a good understanding but it’s more accurate than the wiki, more accurate than the glossary.

Heath: Yeah, the key part there definitely the understanding. Now, when you talked about that early part, back onto — we drifted away from the original manifesto about the four values, and should there be a fifth? So the four values, for the listeners who aren’t as familiar to the values is Peter here now infinite centuries of experience in senior Agile Coach and Trainer for most of Europe. So, value number one is what do we say? Individual interests over processes and tools? Is that the first one?

Peter: That’s correct. individuals and interactions. Yeah.

Heath: And then working software. That’s interesting. Working software over comprehensive documentation. We’ll come back to that in a second. And so I’ll list them all out. So number three, value number three is customer collaboration are contracts. And number four, responding to change over following a plan. Okay —

Peter: That’s right.

Heath: So, the question is, have we moved away from the manifesto, and is the manifesto still up to date? Just before we start there, I think a criticism of like — they mentioned here software. So now Agile is used not in only software projects, and as in like business transformation, and so I’d say, here, this is a six-step agile framework. Now, the criticism I have of TOGAF, or those standing on the shoulders of giants, there’s a lot of good things I like about TOGAF but there are some things that I don’t like about TOGAF like they don’t acknowledge really business architecture but they talk about this concept of enterprise architecture. Now, enterprise architecture is really two main domains: business architecture and technology architecture. And it is up domains and technology architecture. Now, the people that wrote the TOGAF, says on the website, they are systems standards company so they’re focused on systems. Keyword there, systems. And so if we say here about I understand individual interests over processes and tools, okay? I think that’s still valid. It’s not so much about the process nor tools, it’s about individual interests, stakeholders.

Peter: Yeah. It’s individuals and interactions. So it’s easier —

Heath: Individuals and interactions, yep. Yeah.

Peter: That’s easier to come to you unless discussed instead of following process, sending you an email, because that feels like, “Okay, job done,” but at the end, nothing, no results.

Heath: Yes.

Peter: Together, together, our interaction is most important.

Heath: Yeah. Okay. I think that’s still valid today, yeah, individuals and interactions. So your point is, I think there may be — on projects when resources get requested, they want to see some technical qualifications or training but one this would speak to and if we look at the causes of project failure, is people skills is around it’s not so much have you got the technical skills. Yes, you need some technical skills, but it is managing that interaction with individuals is the biggest part.

Peter: Absolutely right. Spot on. You know, having a nerd in a team is not going to help the team.

Heath: Yeah. Yeah. You’ve gotta have — everyone’s gotta be on the same page, good vibe, good culture. Okay. And so the working software over comprehensive documentation. So, I’m — yeah. What’s your thoughts on that? I have a particular view on that.

Peter: So when it started in 2001, it was all software related. So, was it 17 guys who came together, they were all with a software background. Nowadays, I would say a working solution, maybe solution is a little bit too much, because we are doing it bit by bit, of course, but showing what you’re doing is more important than just having the PowerPoints.

Heath: Yeah.

Peter: And that’s exactly what we’re dealing with in the review, show me the —

Heath: Show and tell, yeah.

Peter: — and that’s it.

Heath: Yeah, demonstrating. Yeah, I think that value is still current and needs to stay.

Peter: Valid.

Heath: Yes, yes, absolutely. In terms of like non-technology or non-software projects, and, say, in this case here of myself and colleagues, maybe even yourself with designing and developing, building and implementing, the design of target operating model and handing that design to developers, technical architects to oversee the management of different components of that architecture, then there’s a non-digital, non-technology implementation. And I work in the same mindset of get these blueprints out to the business at quick intervals, quick iterations, so that — because I believe that the longer you work on it, the less value you add to it, because they don’t have the answer. The answer is actually in the business user’s head, it’s your job to get it out of there. So, how you get it out of there is the two ways, you have process and structure. So not so much working software over documentation but working blueprints, working artifacts that they can actually use, that are usable, not interesting but useless, which is the criticism that consultants get. They create these reams and reams and reams of PowerPoint presentations and they print them off and put them in a room and the room is called a war room and then it looks very impressive but is actually useless. But I’m a big advocate of the working software or the working documentation or blueprints over excessive documentation.

Peter: Yeah. Oh, I hate. I do remember a long time ago, together with my manager at the time, we spent hours on project progress reporting.

Heath: Oh, yeah, yeah.

Peter: It felt like every week, why am I doing this? And that’s exactly this value number two where I’m thinking, “Oh, my God.” Yeah,

Heath: Yeah. You got to be working on the — so I can lean, you wanna focus on eliminating the waste elements of a process and only working on doing the add value elements of the process. Yeah, like the backend, yeah. Admin work, if you can eliminate it or reduce it, better. Okay, number three, customer collaboration over contracts.

Peter: I think, yeah, still valid. Now, contract negotiation is a little bit far away in time and, hopefully, it will stay that way. Now, of course, in the beginning, if we are going to do a project together or whatever, yes, we need a contract there. Fair enough. But then, we start working together and we will have problems, which is also fine, you know? We know what’s going to happen. So as long as we talk, so as long as we collaborate, as long as we have the positive vibe and the positive interaction, I’m not worried about the contract negotiation.

Heath: Okay, yeah.

Peter: You were talking about personal skills? This is exactly what I truly hope people are going to bring next to the technical skills or whatever skill, you know, have some empathy, be polite, be respectful. And we have to do it together. It’s like a football team. You have to work on it.

Heath: Oh, yeah, yeah. Actually, it’s funny you say football team. We’re just arranging an off-site, week-long workshop and the host of where we’re hosting it actually recommended, we said we’re gonna do some sort of team activity and they, funnily enough, although I’m from New Zealand, recommended that we do the — they had themselves brought into the hotel a haka group, a New Zealand Hakka group and so around that haka is, funnily enough, a good friend of mine, I’ll give him a plug here, he’s hakaworks.com. That’s Karl, so Karl and his team have been doing it for many years now, I think almost 20 years, and this is exactly what they do. They teach the haka to corporates who come in there through a team building collaboration about this shared purpose, shared goal, and like everyone is in this together and everyone’s contribution is valued and we couldn’t do this collectively without you. If there is — and the whole thing with the haka, it’s a war dance, you are challenging the opposition to a war and they do it before going to war, that if the way they form themselves and the way they’re structured and they line up, if they proceed not in sync, they create a gap, and by creating a gap, it creates a weakness and puts the others at risk. So they mutually have the same respect for each other. So, that’s like the lesson there, I think maybe this project here if they end up doing it, will be amazing for them. Yeah.

Peter: It sounds very cool. I’m jealous. I think haka is fantastic team building.

Heath: Oh, yeah. You know, the All Blacks have a long winning streak. I think that they might be the most successful sports team in the world for having the longest winning streak, or not winning streak but the number of wins as a team. And it’s great cultural experience, I think, for both New Zealanders but also for the opposition and people watching, they get to see this. But what it’s actually doing is from the team’s perspective, it is making them more cohesive just before the whistle blows off and so now you’re trying to stop like this machine that is just, you know, this is one, it’s like playing — they have 15 people on the team but it’s actually one person. They play and behave like one person. They can think of what — they anticipate the next move of their teammates because they know them so well and they have each other’s — their whole mantra is about leaving that jersey in a better position than they found it when they got it, when they inherited it, so they talk about they have a legacy to look after but a legacy to leave. And so for the corporate environment, there’s a legacy that we have and we want to leave and we’re in this together, we have a shared purpose. Yeah, so real powerful stuff. And if you can take that from that culture and apply it from a sports team to corporate…

Peter: Now, I know I’m a little bit diverging here, but is it — what you mentioned is like swarming —

Heath: Swarming —

Peter: Swarming, one team, knowing where we’re going to —

Heath: Yeah, yeah.

Peter: Yeah. Bu, okay, forget it.

Heath: So they — it’s very calculated. From a sports perspective, it’s very much a competitive advantage. Okay, so the fourth one, responding to change over following a plan.

Peter: That’s right. Let’s start with the answer: still valid. And the reason is, you know, even today, if you are asking a customer, “What do you want?” he or she doesn’t know. It’s the same like building a house. So, Heath, how does your house needs to look like, not only on the outside, because that’s pretty easy, but on the inside? We don’t have a fixed plan. And this is also exactly where we come in as a third party, as external consultants, where we hopefully bring the skills to help the customer. And we are not too much focused on what we want but we are helping. So, yeah. For me, the four values, they’re still valid.

Heath: Yep. Okay. Yeah, I agree with that one. I think — and I think this ties in with the mindset part, is that a traditional project management, they would have a plan, a Gantt chart, a timeline, a roadmap, and it’s clear activities and milestones, it will get you to your outcome that you want at a certain period of time, you know, the typical project manager’s dilemma, time, quality, and cost care, you can have only two, which two would you like. Now, from an agile mindset was that, to the value there about responding to change as opposed to following the plan. Now, this is what I tell in the book and the students and even clients is that as we start going through this transformation and by sharing these blueprints and updates of the design, the target operating model, the client will get to understand the problem better themselves. And understanding, like you just said there, you’re building a house and we know what the outside looks like but we got no idea what the inside looks like. And as you start building it, they get to see a bit of a clearer picture and they go, “Actually, now I can see what we need in here,” and their priorities change. And as their priorities change, their needs change. And then so, quickly, all the change, design changes, and so that there would be responding to change over following the plan.

Peter: That’s right. Absolutely right. Yeah. And then there’s this fifth value —

Heath: Yeah, the fifth one.

Peter: Mindset over culture. What do you think, Heath? Would that be — would that help us? Would it be —

Heath: Well, that’s almost —

Peter: — value.

Heath: Well, I’m a big advocate of the mindset, you know, especially if you’ve come from, and you talked about it earlier, guys that have come from SAFe, SAFe have a certain perspective on life, a certain way of they see things versus Scrum have another and every other derivative or permutation of agile. Kanban has another view. So that there is, if you’ve come from a waterfall background where it’s clear gated, approvals need to be made and locked and loaded, that the requirements are very clear and cannot change and after that gate, and that we proceed and until up until the next gate and then everything’s locked and loaded and, again — now, if there’s any changes in there or any changes from here, they need to come back, they go, no. So, well, actually, as you just said earlier, building a house, they don’t know until, hey, you’ve got the framework there and then, “Oh, now I can get a bit of a picture. I can see and I’d like to change my mind.” So I think, first and foremost, the mindset is very important, yes, but culture, the culture, maybe I don’t know if it’s mindset over culture but the two need to be aligned so that the culture supports the mindset.

Peter: Yeah. The moment I, you know, I came up with this fifth value, so to speak, it was also like, “Oh, that’s a difficult one. That’s not easy,” but I think we do agree at four values, they’re still valid. But in the meantime, we have learned so much more about agility, how to define — people has also learned much, much more about Scrum, Kanban, and not only, you know, shallow but really granular, in depth. And maybe we don’t have to mention mindset or culture but it’s part of our working. So —

Heath: Yeah.

Peter: — I think in trainings, in coaching, in helping people growing, growing towards agility, will definitely help them to get there. Well, not ASAP, but make the move step by step for itself.

Heath: Yeah, I think what you’re saying is, well, maybe I’ll take the words out of your mouth, is it’s about being explicit about culture. It’s otherwise implied. And I think, you know, it’s like saying, okay, if there’s no problem with transformation, business transformation, and we’re reporting 70 percent failure rate and there’s nothing wrong with organizations doing the transformation themselves or just changing their business model, changing their culture, there’s no problem, but there is a problem. And they’re reporting 70 percent failure rate so something’s not working. So what’s not working? Maybe the — well, we said the four causes of failure, all to do with people, and what about people? Psychological. And tied into the risk, your culture. And if you’ve not — if you say, yeah, the problem is culture and we don’t write it down and there’s nothing on the walls but it’s just the way we do things around here, it’s like saying let’s staple the jelly to the wall, so you’ve gotta lock this down and it’s like I tell the client, I said if we’re gonna to improve these, if we are going to improve these processes, we first need to understand them. And to understand them, we need to document them. Now, we can do it either one or two ways. We can do it light touch or deep dive, depending how much time we’ve got and what the appetite is to do it, whether there’s a clear understanding, it’s very easy to understand these processes or not at all, but the one thing is for sure, if you don’t measure it, you cannot improve it.

Peter: Correct.

Heath: It’s like the culture. If you can’t define it, then how can you improve it? How can you change it? You can’t.

Peter: Yeah. No, that’s right. And, again, it’s like measurement is very important so even if it is not the numbers, you still have to try to measure where are we now and, yeah, where are we going to and are we there yet, yes or no. Yeah. Wow, what a topic, yeah?

Heath: Yeah, yeah. I love it. I love it. All right. So actually, that was number two was Agile culture. I think we have talked about that. So what about agile culture? Is there an Agile Business Consortium?

Peter: Yeah. You know, they have some interesting stuff. You know, when I was preparing and reading and so on, of course, when you’re using Google, there’s so much to find but if we’re talking about agile culture and the question is what is it and do we have a definition? Well, the guys from this Agile Business Consortium, they do have, they call agile culture is about creating an environment that is underpinned by values, there we go, behaviors and practices, which enables organizations, teams, and individuals to be more adaptive, flexible, innovative, and resilient when dealing with complexity, uncertainty, and change. If you read this definition a couple of times, you know, it’s good. Yes, it’s good. It’s very much what we’re doing today. And reading this out loud makes me understand better what we are trying to define by culture, agile culture. What do you think?

Heath: There’s a lot in there. There’s a lot in there.

Peter: Yeah.

Heath: Yeah, yeah. Okay, so agile culture. I think agile culture is a culture that supports being agile. And so what would that mean? Is probably going back to the values and one probably I like about most of the values is about change over following the plan. Be prepared. Bonding to change as opposed to following the plan. And so you have a general direction. It’s the path that you take to get to the outcome that may suddenly change, but you have the ability to and you will be able to change if and when needed. I think that is — if I was to summarize agile culture, I’ll say, yeah, it is a culture that has the ability to accept change over following a plan. Yeah, in summary.

Peter: Definitely. No, definitely agree. So when you’re taking the little bits apart, you can relate it to failure number four, responding to change. It is indeed in the agile culture.

Heath: Okay, so I’ll just say it back for the listeners so that they could hear it again. So agile culture is about creating an environment that is underpinned by values, behaviors, and practices which enables organizations, teams, and individuals to be more adaptive, flexible, innovative, and resilient when dealing with complexity, uncertainty, and change. Well, I think that’s a very comprehensive definition there. Yeah. So, basically, culture that supports the ability to change.

Peter: Yeah.

Heath: Cool. Yeah, I think like with — in the three L’s, you know, if that direction, for that to hold and stick in organization, it has to come from the top.

Peter: Yeah.

Heath: It has to be endorsed from the top and followed through, filter through down through the organization. Otherwise, it would never, one, take hold and no one will believe it.

Peter: True. And I think if you look at this agile culture, we’re now responding to change, which is good, and the Agile Business Consortium, they have written about DNA, they gave some examples and so on, but we don’t have to go through all the DNA stuff. I think now we know agile culture and we also know what we’re doing in reality, you know? We are coming to a point where you also see these anti-patterns.

Heath: Yes, the patterns and anti-patterns,

Peter: That’s right, and I think anti-patterns is very exciting. For an experienced coach, it’s very exciting because it’s like what is ongoing here? Where have I seen these before? How can I name it? And there are some really good white papers out there with a lot of anti-patterns you can find —

Heath: Okay.

Peter: — so what I do remember from —

Heath: Just for context there, for the listeners, because in architecture terms, patterns, particularly technology architecture, they like to summarize or they say they like to summarize, but they use patterns to summarize the way systems interaction, interoperability so there’s a method or technique described or decompose complex ideas or systems down into quite simple things. So, a pattern is the way of describing ways things naturally or typically work. So an anti-pattern then would be, in your definition?

Peter: If you say anti-pattern, you know, this is going against the pattern to be more effective, to be more fluent, to have the flow. So what you’re seeing is a reverse behavior or a reverse way of working, meaning it’s not going as mentioned.

Heath: Okay, so is it like, say, it’s counterintuitive or it is…?

Peter: That’s one. It’s ineffective and it’s like not desired.

Heath: Okay.

Peter: And if we take — so we take the culture, we take the anti-pattern, and then the third ingredient, what we discussed, was the psychological safety.

Heath: Yep, safety.

Peter: So these three ingredients, they’re coming together and if you’re talking about a performing team, you know, they know what they do and they have this safety in the team, they know exactly what they can do and they are working with patterns only and not anti-patterns.

Heath: Okay, yeah.

Peter: Now, if you take someone out of the team or someone who is not into agile, he or she —

Heath: Joins the team.

Peter: Yeah, is going to disturb the flow in the team by finding new elements which are not wanted.

Heath: Yep.

Peter: Yeah.

Heath: Okay. Yeah, so that really anti-pattern in that context is a disruption.

Peter: Yeah.

Heath: A disruption to the norm.

Peter: Yeah.

Heath: It breaks the pattern.

Peter: Yeah.

Heath: Yeah, okay.

Peter: That’s easier said but that’s exactly what it is. You know, like, example, like you stand, take your 45 minutes and the manager is part of the daily and he or she is talking. That’s disruption. That’s not effective. That’s not what you want.

Heath: Okay, so, yeah, and in that context, it is anti-pattern has been a disruption that ruins the pattern.

Peter: Absolutely.

Heath: Yeah. So for the viewers and I’m sure all the viewers know about the stand up or scrums, why it was called the stand-up is because it’s supposed to be literally standing up and keep to three bullet points, you know, what you did yesterday, what you’re gonna do today, and what’s gonna stop you, and so, yeah, so to have a long stand-up is — that’s not a stand-up, it’s a meeting now, and so you’ve defeated the purpose of a stand-up and you’re not probably gonna get the same outcome. The purpose of the stand-up is to get the result, the result being achieve the information about, from the scrum master’s perspective, is that they will hear what’s gonna block them and unblock it for them.

Peter: Correct, yeah.

Heath: Yeah, okay. So, because you’re talking about safety again, so is the anti-patterns, so what is with the anti-patterns in safety in scrum — in agile, sorry. Psychological safety, rather, sorry.

Peter: Yeah. So, Heath, we are working in a team, right? And if I’m not feeling safe in a team for whatever reason, it could be me and a teammate, we don’t go along very well, then I’m not really transparent. I’m not open, meaning I’m not willing to share my thoughts

Heath: And to that point, in Scrum, the three pillars of Scrum, one of those pillars is transparency.

Peter: Yeah, exactly.

Heath: Okay.

Peter: And not being transparent, so not giving my honest opinion to help the team is disruptive. That’s an anti-pattern. So just a simple example, with a retrospective, if you as a scrum master or coach are asking me, you know, is there anything wrong in the team now or is there anything you want to give feedback to the team and I don’t feel safe, I won’t do it.

Heath: Yeah, you won’t give feedback.

Peter: Yeah.

Heath: You won’t give constructive feedback.

Peter: That’s right.

Heath: How the team could learn.

Peter: I’d rather be silent, you know, and then hopefully retrospective will be over in two hours and that’s it.

Heath: Yeah.

Peter: That’s wrong. That’s not the way how we should work.

Heath: Okay. So the lesson there is around safety is that you must create a safe environment where people can feel that it is safe to discuss, talk, air, raise issues and concerns without the threat of being either ostracized or ridiculed, criticized, because the outcome is it’s for the betterment of the team.

Peter: Yeah.

Heath: Okay, and so, agile at the moment, the psychological safety is, in that context there at agile environments, probably particularly around, well, in a couple of probably ceremonies, if we talk in correct terms in Scrum, anyway, in the stand-up, is that people like to air all their pains, but, no, that’s not the purpose of the stand-up, so if you have pains, that’s another meeting, not that meeting or maybe just on the side of the scrum master. And with the retrospective, the lessons learned that you’re raising, what worked, what didn’t work, and then you should not feel either obligated or threatened to not reveal things or issues that would derail or maybe upset some people, it’s in the best interests. So who can help with controlling that safety so that people would feel — who’s responsible for that?

Peter: Let’s say, there’s more than one people involved here. So, first, it’s the team itself, the developers, you know? People like you and me. We have to make sure we are trusted and we can trust each other in the team. But if I’m, let’s say, bullying a little bit, because I’m more senior, I have more knowledge, this is not going to help the juniors to speak free. Now, the scrum master or the agile coach can help here as well so he or she can channel this kind of behavior and try to get rid of it with the team together to get a better understanding why we shouldn’t do it. And then, of course, within the organization itself, so on a smaller level within the business unit or within the IT department, you have to be sure this is not going to happen in other teams as well. It should not be like frequent behavior which is seen, making sure it’s eliminated all over the teams. So, it’s more than just one person. And —

Heath: Okay.

Peter: — it’s very difficult.

Heath: So there needs to be some — maybe empowering from, let’s say, for those in the transformation division in charge of all their change resources, change people, that direction would need to come from them to say about what certain maybe supporting behavior, positive behavior looks like and to encourage the feedback, if that’s the term, without the threat of being criticized because it’s a learning, I think going to really the culture, is that a high performing team is a learning team. A high performing organization would also then be a learning organization. Learn to take feedback, learn to take the lessons and then do something with them positive.

Peter: That’s right. Absolutely right. And I think that’s the right approach as well. So it doesn’t make sense to punish people. Punishment is a little bit outdated. It’s the wrong way, wrong approach. But teaching people how it should be or must be is much, much better.

Heath: Yeah. And I know that it’s encouraged in some circles but maybe in some others it isn’t, maybe because there’s a commercial, contractual motivation to not say certain things and hope that it doesn’t upset the applecart. Okay. In terms of safety, there needs to be a culture that supports the safety and how that, let’s say, becomes visible, that there is an issue with people not speaking their mind, with not contributing, with not giving the honest feedback, then the mitigation there is for two levels, you talk of the project level, maybe program or portfolio level, even division level, I think itself it’s ownership. Ownership from the project level, like if it’s teams, it’s self-directing. People should take their own ownership, but mostly will be the scrum master or project manager. And then at department level, it is at maybe the head of division.

Peter: Yeah.

Heath: All right.

Peter: I think we got a plan, Heath.

Heath: I think — you did let the cat out of the bag for the next book but you could. Yeah, so there’s a big thing around culture, like I’m a big fan of culture. I think it is, with this working from home environment now that we find ourselves in, but also Google here in the UK, Google, yeah, Google just spent a billion dollars on a new building which is gonna — the billion dollars is not for customers, billion dollars for staff to get back in the office. And so I talked about this on previous podcasts about I think the silent victim in this working from home environment is the culture. The culture is getting killed and there’s no spokesperson for culture but you see these big companies, big companies who have access to a lot of data that others may not have, for example, Google, they have already made the big call, spent a billion dollars on a new building to get their staff in the building. What does the building represent? It represents bringing everyone back into the same environment that builds and maintains that strong culture.

Peter: Yeah. I think that’s an excellent idea. Bring back the people together, maintain or growing the culture again, because we lost two years, right?

Heath: Yes, yes.

Peter: And it’s time to get connected again.

Heath: Oh, yeah. Yeah, I actually — I talked about this before on a previous podcast about a program director that I worked alongside in Australia and I asked the question in a poll about is this work from home here to stay and he replied, he said, “Yep, we’re only gonna get together — we’re 100 percent working from home, only gonna get together for a meal,” and I said, “Wait a minute, you’re only gonna come together to share a meal together, why can’t you just share a meal while you’re sitting in front of your PCs on Zoom?” And he’s like, “No, no, no, no, no, we need to be together.” I said, “Do you not see the difference between you being together in a working environment, collaborating, creativity sessions, creative sessions, and, you know, the cohesiveness that you have as a team happens in a room but you’ll only now only do that for a meal.” I said, you know, “Can you not see that the value is also in bringing everyone together to work together, not just sitting together to eat a meal?”

Peter: Exactly. What luxury do they have? Only for meal coming together, but, no, I think they missed the point.

Heath: Yes. I’m gonna check back in maybe a year’s time and say, “How did you go with that?” you know? And whether they decided, and I’ll say, “Well, how’s the business going?” you know? “Have you had a high turnover?” you know? People love working from home but it would be up to a point where, you know, there’s the blurred lines of, you know, home and work is there’s no difference anymore. You’re always on your work, life is home life, home life — Yeah. Okay, so let’s recap there, Peter, we might have just gone a little bit over time. So we discussed the three — the Agile Manifesto, is it still currently changing? The Agile culture, what is it? Can we define it? And then the psychological safety, which is really where we talked about patterns and anti-patterns. So, and in terms of the manifesto, we talked about the four values and you said and referred to, is it professor, doctor? Erin —

Peter: Erin Meyer.

Heath: Meyer, yeah, Culture Map, that —

Peter: Yeah.

Heath: — it’s a must read, that one, so the Anglo Dutch Translation Guide or the matrix sounds very interesting. The way that maybe not just the Dutch but the different cultures and obviously that’s really country cultures as opposed to corporate cultures, right? But that translates into corporate culture. What is — “Yeah, that’s interesting.” “Oh, he’s impressed.” “No, he doesn’t like it,” which is completely the other way around. What did we talk about there? Evaluation, about direct and indirect feedback, and then different cultures have a different probably perspective or preference, maybe bias to what they like. We brought in Yoda there, “Unlearn what you have learned.” I think that’s a good lesson for us all. And that also becomes, you know, perception bias, where, you know, I know what I know and that’s what I know and, therefore, I will do — so how well is that working for you? And so, you know, so sometimes, every now and then, we might just step back. Then we went through the four values. Key part around the values was really showing understanding, people skills. I talked about when resources come into projects, they really look for what qualifications do they have, what training have they done, but it’s real technical, and the key part there is not just the technical, it’s the cultural.

Peter: Yeah, correct.

Heath: Yeah. Okay. And then we had the fifth value, the mindset over culture, which is a fantastic one. I think you should make a proposal to maybe the Business Agile Consortium and make a case for that. I think, definitely, I’m on board for both of them. I think they need to be aligned. I’m not sure if one is over the other but, you know, that’s ongoing. What we said earlier, culture is implicit and if you want to change it, you need to measure it and so if you don’t have it explicitly stated somewhere, then good luck to you, you’re never gonna do it. The Agile Business Consortium have a fairly comprehensive definition of what they say is agile business, agile culture. And then the last thing we talked about, the anti-patterns and safety and that they’re certain, they’re almost counterintuitive or they are disruptive that they, you know, the technical person or someone that joins a team that interrupts the flow, you need to address that, who’s gonna address it at two levels, scrum master at the project level and then if you wanna make this a behavior across the division or organization, it’s gotta come from the top. And the main part there being we want two things: we want to be trusted, to trust and to be able to be trusted. And how do you do that? Coaching. Coaching by, way to go, Peter.

Peter: Fantastic. Now, that’s a good summary.

Heath: Thank you very much.

Peter: And, yeah, these were good topics as well.

Heath: Yeah, no, I enjoyed it. Thank you very much, Peter. That was great. So we have not spoken that much, have we? But the way that I think we’re aligned on agile and culture, I find it very interesting. I think there’s a lot of practitioners out there — we live in an environment now, so digital transformation or business transformation, which is never digital, and the focus is on technology, or digital technology, and less so much about people element. But what are we seeing a lot of? This thing keeps coming up. Culture —

Peter: Yeah.

Heath: People.

Peter: Yeah.

Heath: I think we need to keep this conversation going.

Peter: Yeah. Sounds like we got a plan.

Heath: Yeah, yeah —

Peter: — fantastic being on your show and I’m looking forward to the podcast when it’s —

Heath: Yeah, yeah, so I’ll keep you posted of when it’s gonna come out. Hopefully, it’s not too long. We don’t have a backlog or too big of a backlog right now, in agile terms. So I’ll let you know when it comes live and you’re welcome to share it around. I’ll put the show notes with a note to go into the description under the video, if it’s on the podcast on Spotify or Google or Apple. They’ll see references there to your LinkedIn, to your current company that you’re at, and also the references to Erin Meyer’s books — book, books, so any references there. And also the Business Consortium, we’ll put links in there, so any of the books that we’ll discuss, we’ll put in the show notes.

Peter: Perfect. Perfect. Yeah.

Heath: Okay, Peter. Thank you very much —

Peter: It’s very good.

Heath: Yeah, thank you very much for your time. We’ll be in touch for round 2 where now I’m gonna share with you the third book. Okay, Peter, thank you very much, mate. Okay. Have a good night. Bye.