Exploring the Transformation from 'Doing' to 'Being' Agile with David Adeoye Abodunrin

Meet our special guest on The Agile Within, David Adeoye Abodunrin, a highly respected Agile Transformation Coach all the way from London. Brace yourself to traverse the intriguing journey from merely 'doing' Agile to truly 'being' Agile, as we shine a light on the transformation it entails. With David's engaging real-life anecdotes, we decode the concept of Agile as a profound identity shift, akin to a carpenter embodying the essence of his craft. We'll scrutinize how a simple act like rising from a chair can offer a fascinating spectrum of insights into Agile, and the potential ripple effect on team productivity.

Venturing on, we draw from our rich reservoir of experiences to provide a glimpse into the facets of coaching in Agile transformations. I, your host, reveal some poignant observations from my own journey, emphasizing the significance of suspending judgment and embracing creativity in uncharted terrains. We also delve into the dynamics of effective coaching techniques, underlining the power of trust and fostering leadership within team members. So tune in for a conversation brimming with insights on fostering an open learning environment, the profound effect of suspending judgment, and the potential of coaching as an alternative to traditional teaching methods. Join us, as we navigate the captivating world of Agile with David.

Transcript

Speaker 1: 0:21

Welcome to the podcast that challenges you from the inside. Welcome, be More and Discover the Agile Within. And now here's your host, greg Miller.

Speaker 2: 0:35

So it's another great day here at the Agile Within with Mark and Greg. It's fall here in the Eastern part of the United States where Mark and I live. I live in Ohio, mark lives in South Carolina, and the leaves are falling out. Here I'm getting ready to take a trip to Virginia it's called the Blue Ridge Mountains On Thursday with my wife. We got what's called a yurt and we're going to do some hiking in the mountains there. Enjoy some of the leaves. Mark, you got anything going on.

Speaker 3: 1:09

Not a lot for me. I'm jealous, though, because my wife grew up in Asheville, north Carolina, so that's a little further south of the Blue Ridge Mountains.

Speaker 2: 1:18

We want to go there sometime. Yeah, yeah, definitely, yeah. So all right, today we have our guest. His name is David, a day o'yay a bodhring. He is an Agile Transformation Coach. Welcome to the show, david.

Speaker 4: 1:39

Yes, thank you for having me, greg, thank you Mark, thank you both, and I'm also feeling jealous of you too. That's a cool plan you have right there.

Speaker 2: 1:51

Thank you. Where are you physically at at the moment?

Speaker 4: 1:55

I'm in London.

Speaker 2: 1:56

Ah, in London as we speak. Nice. What's it like over there right now?

Speaker 4: 2:02

Well, we are in autumn. There is a lot of rain, it's wet, dampy, generally nice. The weather is beginning to go colder, but we're fine, we're good. Sometimes it's warm, other times very cold, but we're moving towards the colder time of the year. What work and what work, work, work, that's what. That's what's going on for me right now.

Speaker 2: 2:34

Do you get a lot of snow in London, like when it turns winter?

Speaker 4: 2:38

Yes, very heavy snow Really In December, in January, at times in November. You got the flicks coming there about November-ish. By December it gets heavy In January. Heavy February, semi-heavy flicks here and there, a lot of rain, a lot of rains. Then it begins to tip down. On March, april, the sun begins to come out and then the on-send goes so mad.

Speaker 2: 3:08

We don't get as much. I don't think we get as much snow as you do. I know in my area it doesn't snow as much as it used to, which is kind of disappointing.

Speaker 4: 3:16

I like a little bit of snow.

Speaker 2: 3:17

I don't like to ice so much. Driving on ice. This is a good time as it gets colder. Stay in, listen to podcasts like the Agile Within, for example. David is going to talk right down our wheelhouse today. This is all about being versus doing Agile. I'm sure a lot of folks out there have heard of that. If you've been around Agile for a while, you may have heard it. If not, you're going to learn about it. The difference between just being Agile or actually in doing Agile. There's a difference there. We're going to talk about that, david. We were having a great discussion before we started here. Let's go down that hole again. I asked you what does it mean to become an Agile Within? Let's start with that.

Speaker 4: 4:16

Yeah, becoming Agile Within starts from who you are. If I say, oh, good afternoon Greg, good afternoon Mark, and we begin to talk, every single thing I'm going to say will derive its life from identity. You see, being Agile is first of all an identity conversation before a functional conversation. A carpenter must be a carpenter. For the carpenter to do good carpentry work If the carpenter hasn't assimilated the identity of a carpenter and that involves the state of being a carpenter that's the way a carpenter comes into the room and looks at the wood. That's the way a carpenter comes into the room and when he wants to sit down on the chair, there's a posture here where he or she sits down on the chair, the carpenter has a being. The carpenter is already a carpenter from within.

Speaker 4: 5:35

If anybody sits on a piece of furniture, we typically sit a certain way. If a carpenter sits on a piece of furniture, they sit with understanding of the structure and the wood. They take care, they stand up in a certain way. It was on a carpenter, for example. I learned that don't stand up suddenly from chairs. You're weakening the wedges of the chair.

Speaker 4: 5:57

Now, for me, I always wondered why this guy would always sit, stand up very calmly from a chair. I mean I want to go out for lunch. You take off like a rocket man. You take off like a rocket from your seat and then you move, you twitch 30 seconds, twitch on the chair. There's some vibration. The guy says no, you hold the seat in front of you firmly or something, and stand gradually, he told me. He said this chair, my chair, will live longer than your chair.

Speaker 4: 6:24

Now, that's love, humanizing of a piece of furniture. That's because he's been assimilated. So his name was Philip, so Philip had become Philip the carpenter. So there's Philip the individual, there's Philip the carpenter, and shows in his lifestyle, in his being, his breathing. The moment you want to stand up from the chair, you will notice him holding his breath. Because of that conversation I paid attention to how he got off and how he sat into chairs. He will hold his breath. And I asked him. He said because some vibrations are cold, you will vibrate too much and then the vibrations go to the edge, to the joints of the chair and affects the glue and the holding material. He said but when you hold your breath, you give the wood and the chair the opportunity to receive you gracefully. That's a lot of carefulness about sitting down and standing up. I was never conscious of standing up and sitting down on chairs that much.

Speaker 4: 7:27

So that is being. We all stand up and we all sit down. That is doing, but we don't know how much things were damaging when we aren't in the being. So the consciousness of agile must become assimilated within so that your identity merges with the agile way of life. When that happens to an individual or an organization, and in between those two extremes, a team, the organization, will achieve agile within. If there's no agile within, there can be no agile without. It doesn't matter the amount of budgets, money, trainers, coaches, release trains, sprints all the ceremonies we do will be. So here is the painful part we don't know that we're not doing it right. We just like getting off the chair. We just keep getting up and sitting down, not knowing that we're with me at the edges and just down the line. It's the denominator in us having to reorder some new set of furniture. So we don't know how much we're damaging agile by not being agile and attempting to do agile.

Speaker 4: 8:49

It's a move and assimilation of identity internally so that you are zoomed the agile posture on the inside. When you do that, execution will be easier. Teams are going to perform better. There is what you call single point of focus or behavior. Difficult to achieve, but once organizations get it, it becomes a big minefield of prosperity and productivity excellence. So that is what agile within is for me. So moving from that state of just doing agile to being agile is the identity, accuracy and precision to situate and posture an individual or a team or an organization so that they see fits in between agility and that person or that team or that organization. That is when you've achieved agility within.

Speaker 2: 9:52

Yeah so what does that's being agile. So what does doing agile to you? If I'm just doing agile, what does that look like? If I'm a new Agilist or what does? How can I identify if someone's just doing agile?

Speaker 4: 10:09

Everything else except what I just described. When you're doing agile is doing agile. That's the first definition, because he has a different look, different look, look alike. It looks and feels differently for each occasion and each individual and each organization, but the pain is there. If you see someone that has mastered swinging the axe to cut and someone who is a new person trying to learn as a woodcutter, One of the ways is that if you gather 1000 woodcutters, they would all tell you that the experiences about pain when you are swinging as a young woodcutter, there is pain, there is unnecessary expenditure of effort, there is a little knee of wood cutting man hours, yet not so much wood is being gotten to the chopped, to the finished states. When you've mastered wood cutting, you would notice that the effort is commensurate or you are able to do it faster with less pain. So every organization and team and individual will experience some speed, some fluidity, some more joy when you are more being than doing. Let me also quickly say this being and doing are not isolated states. In practicality, my experience as an agile transformation coach, as an agile coach, I found that people are a combination of being and doing. So, as you master one area, that master introduces you to impediments and lack of capabilities in some other areas. So you grow one area, then you find a need to grow another area. You find your incompetence is introduced to you again, you increase it and then you. So everybody starts from trying to do and then being takes over from there as they begin to assimilate what we're talking about based on the subject. But clearly when people are just doing, there will be a lot of dissatisfaction. People will want to join the process, For example, things like trusting the team to be autonomous. If you are still in the mind frame as an individual or as a team or as an organization, if you're seeing the mind frame of doing, you will not be comfortable with it. In fact, I had the beautiful experience of coming from the waterfall methodology. I am PMP certified so I have also helped many PMPs to certify many organizations to actually implement waterfall for a space of not less than about 12, 13 years before I came and I embraced agile much more fully and agile in there about my 12th, 13th year or so, Making that mental switch, for example, of leaving people to do their work Like you're seeing that a technical team as a waterfall project manager, that a technical team can self organize, that a technical team can come up with their schedule themselves, that they would regulate A waterfall project manager can never understand that.

Speaker 4: 13:40

It's difficult to assimilate. So when I saw that in the agile books, I was like, really the team will come up with the man, hours, the value map and they would self regulate. It was crazy for me. But as I began to assimilate better and become one with the body of knowledge and please notice my choice of words I became one more with team management techniques within the value chain and the release trains and all of that, I found out that really and truly a technical team is actually supposed to self regulate. But that shift that a technical team ought a DevOps team, for example, ought to self regulate and they don't need the project manager coming with a schedule. That when you're doing scheduling what you should do is to actually aggregate team intelligence and let everyone be in the room and determine and give you whole information about how long the item the just just fear out of my mind now.

Speaker 4: 14:53

The pop the user user story user story is flowing into the box where it's in progress is all done.

Speaker 2: 15:10

On one board. Yeah, the board.

Speaker 4: 15:11

Yeah, the board, yes, so, so, so, so. So the thinking that let them give you whole information to come into the board and you don't have to impose external Dependencies and external shadow dependencies by activity sequencing on them. No, let the team self-organize and think and create in iterations what they can do or what they should do, and that typically a team will form and gradually, gradually get into steady speed as you go along. Now it took me a while about three to four years actually to agree, so right now I don't even bother, I allow the team to do the magic and I now know what buttons to fiddle with and the team always performs. No time have I had issues with the team self-regulating.

Speaker 4: 16:03

But I can't believe 13 years ago, 14 years ago, if you asked me as a PM that what do you think? I think the team should go and decide, the technical board should go and decide. I'm going to want to behead you. You really mean you're going to do that with your money. It's going to take 10 years and nothing would happen.

Speaker 4: 16:23

Although the same problem happens in Agile and other way, where you go from sprint to sprint and deliverables or features get moved to the next sprint and the next sprint and the next sprint, and then that also happens in Agile, but it is not as bad as it looks. If, as a PM, if I use my PM thinking, I would never allow that to happen. But now as a transformation coach, I've helped many teams transcend that madness permit my use of the word madness. So that's an example of how being versus doing occurs in the same individual or in the same team or organization. The two of them are there together, but what we're saying is that we should move more towards being and, when there's an area of challenge, move the team into being Agile in that area and then you have more results.

Speaker 2: 17:14

So good, okay, we've got definition of being and doing. Now what I'm thinking now is how, if I'm, like you talked, waterfall PMP coming out of that doing, or if I just and I'm coming to Agile, I'm just doing following, like you said, following the process maybe how do you start to make that transition from doing into being?

Speaker 4: 17:40

Okay, the first thing for me as an Agile coach is that I suspend all my biases when I come onto a team or if I get a new assignment and there's a challenge with how employment is done and how coaches are engaged and how team members are engaged. The learning Real quick.

Speaker 3: 18:04

What does that mean and what does that look like? Suspending biases yes.

Speaker 4: 18:09

It means? It means as an Agile coach, you have your own world views, your own perspectives, your own styles, your own adaptations and your own growth. And when you come onto a new team, allow time for yourself to assimilate, while you are conscious of the idea that you would look like a rookie or like someone that has no value to contribute for some time. Now, that's a challenge at the tricky part for many coaches and many, many Agilists. When you enter into an organization or a team, the general feeling according to HR balances that you must start performing. So you are shooting ideas, shooting charts, showing possibilities. In every meeting you want to talk. In every meeting you want to say something that will make them know that you're really smart, right. The problem with that is that if you are coming at a level of influence like a Scrum Master or Agile Coach, you probably will break some things and you would get some things right. But I have found that that you should suspend judgment and assimilate what is going on first. Assimilate the team dynamics, assimilate the power dynamics of the organization, assimilate and I didn't use the word understand, assimilate, immerse and understand what's going on and suspend all your own biases. I'll give you practical examples for me. When I was, you see, I had the blessing again of starting my career in the core technology space. I started as an electronics computer engineer with all the engineering artifacts for the first 14 years of my life all my project management work, my technical work as a developer all of that was in the techies. And then I got this opportunity to lead value transformation with the largest marketing communications group in West Africa at the time, and I was the director of project and program management for the entire enterprise and we had about 12 subsidiaries, all of them very big companies doing billions of Nigeria and Naira. At the time the exchanges were still fantastic, we had global clients and my job was to ensure that the organization was able to pinpoint and understand the value architecture of the advertising dollars being spent. So concepts like return on advertising dollars, return on advertising dollars how effective are the campaigns? At what point do we notice the delta In between the time the money is spent, the idea is deployed in the market and when do we begin to have results? Because clients were asking for that. So I was now going to use my project program and the element of understanding to deliver value in a non-techic, creative environment. So this challenge played on me because I'm very techie. I was very techie at the time so I had to now learn how to use creativity.

Speaker 4: 21:19

Now there were many biases I had as an engineer and someone who had risen to the ranks as a project manager within the tech industry. One of them, for example, is that productivity isn't motion and hardcore movement of the chart. In all the technical fields there must be a certain number of code or a feature working by a certain date, and by the next date we do another review and then we release another one. But in the creative industry you can have a creative seat for two days not saying a word, not touching a computer, only smoking and drinking, and the guy is working. And the guy is really working very hard. As an engineer I didn't understand that. It took me almost two years to settle into the idea. But I began to see some subtle differences when I allowed myself to rein my bias in. I mean, these guys came up with ideas that you know that spin me off my seats. I will. I want to. Just you know when ideas knock you over doing an ideation presentation, you're like, what did you say?

Speaker 4: 22:35

And when you pack them with more work and they are working for money to even work, you're working, working, working, working. Working. Brief after brief, brief after brief, brief after brief, the productivity of the ideas, the strength of the ideas in the market was dived. The responses were weaker, but when they were given more time to ponder on issues and turn it around, they came up with tele-ideas. Although don't leave them in that intermittent period. Let them present to you in intervals so that you have co-creation going on. Transparency and that's where I began to get more interested in agile, actually during that experience, because now agile fits well with less co-create, less transparent. Let's do it together over a longer period of time, rather than leaving people to work for several hours and weeks and then you come and do a review at some point when, in the future, something as deviated from where it should be, so short bursts of creativity came into Limelight as a new way of working for me, rather than allowing people to work the hardcore technology thinking where I was coming from. So that's an example. So smell your biases and observe and assimilate well. Then begin to place your agile thinking and agile understanding beside what's going on.

Speaker 4: 24:05

Next thing interview. Ask questions on why they're doing what they're doing. Don't assume because you've seen it is wrong. No, no, no. Ask questions. They probably have insight and they say history behind it. Ask questions and go to coaching mode. That's where I start. Ask questions, go to coaching mode. Don't go mentoring, training or teaching until you have coached.

Speaker 2: 24:28

That's what I was going to say. When you mean by assimilate, you mean, yeah, just observe and ask questions, right when you're part of a new team.

Speaker 4: 24:36

Yes, start as a coach Observe, ask questions, observe, ask questions, feedback, observe, ask questions, feedback. As you begin to feedback, you're beginning to enter into mentoring mode and after a while, the training needs to emerge, the facilitation needs will emerge and the training needs will emerge. So that's where I approach my work as a transformation coach I will observe, ask questions, then keep asking questions, then provide feedback, questions, feedback, questions, feedback, questions, feedback. From there I begin to facilitate and then mentor and train. Training is what I do. Last, but many coaches and many school masters starts from training. No, you will create more problems. I don't even know you've created more problems.

Speaker 2: 25:28

How so.

Speaker 4: 25:30

When you train at first, what you do is that you're coming with all of your own biases and worldviews and you're not allowing the system to also give you the space within it.

Speaker 4: 25:46

You see, what happens to the brain when you train people in psychology is that they match what they know with what you are saying. That is introducing some biases already and some dissonance and resistance. What happens to recipients of a training is that they match what they used to know or what they are doing versus what you are telling them to do or what you're coming in, even if it was best in practice, best in class, even if it was best practice or what I like to call best in practice or best in class. Remember that is the understanding you have. There is also the culture, intelligence and the evolution of the team and the people you're working with. You will meet all those resistances and biases and it will be too deep and too tough, but when you allow them to speak and give you information and then you ask questions, you will have bypassed some resistances in their filters and you are using coaching first. What coaching does is it opens people up to possibilities. It opens teams and individuals up to what they didn't think about. It will also give you the opportunity to be reverse-mentored, because there are also things that you don't know or blind spots that you are coming to the room with. It is a beautiful nexus of the minds. What you want to achieve as an agile transformation coach or as an agileist, is a meeting of minds in the shortest possible time.

Speaker 4: 27:21

Training and teaching has the problem that it doesn't go through all the time into into, because people will operate with you trying to assimilate what you are saying. That's where memory works. When you're in a class, you are placing what they are teaching you beside what you've known before. But coaching allows you to see quickly new ways, new neuro pathways, new ideologies, new strategies, new ways of doing stuff that will give you less pain. And and when you're in the trenches with someone, their biases are killed, when you are observing feedback. Coaching observing feedback suggests us when you're doing that kind of thing, you are breaking their biases.

Speaker 4: 28:05

What you say in a classroom for several hours you can do in a 30 minutes meeting. I'm like, wow, I've done that with sprints. I've seen people struggle, organizations and they struggle through sprints. And while I'm observing the, the struggle, I enter into facilitation mode, I go into coaching mode but never training mode. Yet I do that for about almost one hour 30 minutes in the last 30 minutes and then I bring, I bring up a tool, that what do you guys think about this tool? Can we use this tool? And they say, yeah, this is brilliant, this is brilliant. Then they become champions of it Instead of having a whole day training. Okay, this is how to use the Kanban board. These are to use the, the myro, the myro scheme. These are to use. It is the way it works. No, no, no.

Speaker 4: 28:49

After I've struggled, I've seen the person taking meeting notes struggle. I've seen her typing. I've seen what did you say? Pause. Can you say that again? I'll just show them the myro board and everybody just sticks it on. And next meeting, all the meeting notes are meeting notes are done in 15 minutes after the meeting. The myro board descent, everybody sees it and just like that, I didn't need to do a myro training, that's all Right.

Speaker 3: 29:11

Yeah, yeah, sorry, sorry to jump in on you. One of the things that I see a lot of confusion on is I see people say that they're coaching, but they're actually teaching. Absolutely true, very true. Can you give us an overview, just really quick, just give us some examples of what is effective coaching versus what is effective teaching and you talk through this, but maybe what's appropriate when, when, both when each one, are appropriate. Yes, yes, yes.

Speaker 4: 29:49

Coaching is useful when you aren't a subject matter expert but you have the ability for insights. You see, in coaching you want to leverage on the intelligence of the individual or the team to create results. They are technical subject matter experts. You are sounding bored to help everybody see things. You're more of a. You're more of a reflecting mirror, and the ability to be a reflecting mirror is a difficult one. You've got to reining all your technicalities I'm a strong technical mind in, for example, transmission engineering and DevOps, but it takes me a lot of effort.

Speaker 4: 30:42

At times I got to remind myself I'm not the engineer, I am not the subject matter expert. Shut up yes, don't worry, that's fine, don't worry, that's fine and then ask questions, ask questions. Coaching is useful when you want the team to come up with billions from themselves. However, teaching and training in quotes is when you are a subject matter expert and you want to impact that understanding onto a team. The only problem with training and teaching is that typically on the assimilator side, on the student side or the person being taught, that person will have to match what you are saying with what you, with what they know. The problem with that is that they love resistance. It's a lot of resistance, but if you go through coaching, the person is on the driver's seat and you're just a guide.

Speaker 2: 31:42

Right. Because, like in, teaching, sorry, in teaching. I'm just thinking like they're comparing to what you're saying, to what they know, and a lot of it's going to be in Agile. I've never heard this before. I don't like it Exactly. I don't know what you're talking about and they just resist because it's changed.

Speaker 4: 31:58

It won't work. Thank you, it won't work. We've done it before. All their biases come to the phone Teaching and training. But with coaching, they are the ones speaking and they are the ones saying wait a minute, this is more brilliant way. They are the ones discovering Wait a minute, this is more brilliant. When you're in coaching mode, you hear the person say I see, I get it now. Oh, so you're saying that I've been doing this wrong. Oh, really, I've been stupid. Oh my bonkers. Oh, wow, that's how coaching, that's it, you know, in the coaching zone. But with the teaching zone, they're like excuse me, but wait, what about this? What if this happens? In fact, the brain begins to produce artifacts of imagery of how what you're saying will not work. That's the problem with teaching and training. Got, it.

Speaker 2: 32:45

That's great, I have to say. I've never heard of not teaching first and that's just got me thinking coaching first rather than teaching. I've been leading with teaching first. When I get a new team I think it's probably your experience has been. Probably what I have is to go in teaching because they don't know anything right and you got to teach it, and then you get resistance and you wonder why do I have resistance right?

Speaker 4: 33:13

So I like that If you're not careful, greg, if you're not careful, sorry. Can I call you Greg? I'm sorry.

Speaker 2: 33:19

Yeah absolutely.

Speaker 4: 33:21

If you're not careful, the change the agile energy can bring you from teaching or training, from that class, from the second day of that class, you may lose a lot of people if you're not careful. Right, what is resistance? But if you start from, hey, hello, guys, tell me what you do. How do you do your sprint? How do you organize work today? How are the teams organized? Oh, you're the chief of this. Oh, yeah, and people, when they're in the driver's seat, they are talking and excited and talking and talking, taking it in, all right, all right. Then ask a lot of questions.

Speaker 4: 33:50

But time you do this, you're building trust, you're building rapport, you're building relationship. They can't. I mean, it's difficult to say no to someone that's listened to you for about two days explaining to him how the factory works, and then you go as a first timer. Can I, can I suggest, can I ask why you're not doing? That's too deep and too sharp. I'm giving a deep example of being intrusive. Can I ask you why you're not doing this or why that is not working? That's too strong.

Speaker 4: 34:17

But let's say the person is more disposed to explain to you why and the thinking behind it, and then you will get to the real, real, real ignorance. You see, people's ignorance have a construct. Many teachers and trainers, beyond the training objectives, never touch the ignorance map or the ignorance architecture of a person, a team or organization, because HR briefs you and then they say, oh, want to become Ajat, so. But the ignorance is shaped a certain way. There's a texture internally of how that ignorance feels when you get a hold of it through coaching. The real training and development need will appear to you in a maximum of a few hours, rather than if you enter the room with all your artifacts and all your tools and everything.

Speaker 3: 35:11

So just a quick plug to piggyback on what you said, David. I'm not sure if either one of you have either read the book or gone through a course of training from the back of the room, but it provides a very different approach than what we normally think of as teaching or training people. And you actually learn through training from back of the room. You actually learn to teach others by through coaching. So you're helping the members learn from themselves more so than learning from an instructor. So that's just a real flip in the room.

Speaker 2: 35:51

That's really interesting. You're flipping the room. It's the back of the room like I envision. I've never gone through the class, but I've heard a lot of good things about it, so I guess I think about like servant leader. Right, you're in the back, the teacher usually teaching from the back of the room where the class is in the front right.

Speaker 4: 36:08

Yeah, and the people are far more empowered. They don't want the class to end. That's my experience. They never want the class to end. They never want interaction to end. But when you come in with a lot of training by 3 o'clock, training's supposed to end at 5.

Speaker 2: 36:22

Once they do lunch.

Speaker 4: 36:23

They get tired.

Speaker 2: 36:24

Yeah, oh gosh, yeah, yeah, oh, I'm with you. 3 o'clock is the. Yeah, they want to take a break, they want to go home.

Speaker 4: 36:32

They're looking for coffee.

Speaker 2: 36:33

Delicately. Yeah, I'm with you on that. Great. So we're almost out of time, we're wrapping up here. But you talked about trust and I know trust is huge in Agile team. So you said so. Do you think trust comes from like initially like doing this, like coaching them, allowing them to lead? Do you think that helps build trust initially?

Speaker 4: 37:04

Absolutely does, absolutely does. I like to jokingly call myself an expert on trust, as if they're an expert on trust. Right, absolutely, because I've observed trust as a behavior, from a behavioral analytics perspective and I've got some interesting perspective. I can do trust, I can facilitate trust for the whole day, for the whole week, for the whole month. It's a reservoir, it's a body, it's a reservoir, it's a container that is full to a certain level.

Speaker 4: 37:41

So there's, whatever you have trust, there is some mistrust or untrust or unitrust. Now, those are three statements that come from you know there's a difference between meaning and words. So lack of trust, lack of trust, is distrust, that's one. There can be untrust, which looks like not trustworthy. That's a deeper level of harm, so that people can't even trust what someone says.

Speaker 4: 38:09

As a pattern, the psychological response of the team to the individual or the organization or the other parties trust brand is so antithesis they expect you to do negative or something. Totally onto, what does the second dimension inside the container, or second element inside that container, the third thing inside that container apart from the trust? So inside the trust reservoir, the third thing inside that container apart from trust is two components A and B. One is their experiences and two is their expectation. The two things constitute their belief system about what they feel, about what they feel about what they feel that would happen. That is the way I classify the trust reservoir. So making the reservoir move towards all those negative three elements and having more trust within the reservoir is what I call Agile Trust Engineering, which I help individual teams and organizations to also achieve.

Speaker 2: 39:21

That's great, yeah, so thank you, david. Yeah, I could talk about this forever. I'm sure Mark could too. This is really in my sweet spot and but unfortunately we're about out of time. It went by so quickly and we thank you so much for joining us. So, david, once again, this has been David. I'm going to butcher it. I hope I don't. A day or a day, awesome, go on.

Speaker 3: 39:49

I got it. Adelaide transformation coach nailed it.

Speaker 2: 39:54

I did, David. How can folks get ahold of you if they want to reach you?

Speaker 4: 39:59

Yes, please, I'm on LinkedIn. Just drop me a line on LinkedIn. Whatever you want me to handle for you, I'm a global. I love to interact on the agile front. I do a couple of things like cybersecurity, because I work on how to make organizations when cybersecurity work the agile way. Not easy, but we try, we try and make it work. I do a couple of other things, but please just hit me on LinkedIn with the message and I'm there. I'm basically based. I work out of both London and Manchester, the United Kingdom, and I do some work, also pro bono, in Africa to just give back. So whenever, if I don't respond to the message on time, you see that I'm in transit or there's some work or some projects, that's. That's quite exhaustive, so I'm exhausting, so so so just give me some time, I will respond.

Speaker 2: 40:50

Yeah, okay, I can also, if I can get. If I get emails, I can send it, absolutely.

Speaker 4: 40:57

So yeah, if you want to get ahold of.

Speaker 2: 41:00

Yeah, go ahead.

Speaker 4: 41:01

Yes, let me put it on the chart, my Gmail address. You're dealking at gmailcom. Dealking at gmailcom be for Daniel, if, for example, for orange and plus King, that's deal. King, I do mail to you. Okay, I am G, d, e, o, k and Delta, echo, oscar, knowledge in no go. That's dealking at emailcom.

Speaker 2: 41:26

I'll put that in the notes too. That's David's email. You can get ahold of them. We have an email to the agile within it's, greg Miller, at the agile withincom. You can get ahold of us there. We're also on LinkedIn. We are on Twitter, which is now X Instagram. Get ahold of us there. Email us, tell us what you think about the show with David. Send us show ideas. If you want to be on the show. That'd be great too. Like David, maybe we'll talk to you sometime. So with that, we've been talking with David about our favorite subject becoming the agile within right being versus doing agile. So thank you for listening everybody. We'll talk to you next time.

Speaker 4: 42:06

Thank you.