Agility and Communications: Arie van Benekum

YC: All right. Well, welcome Ari here to the Hardcore Soft Skills Podcast. How are you?

AV: Yeah, I'm good. You know, back home, which is nice. Right. So I'm feeling okay.

YC: Wonderful. I really appreciate your time because, it's great and it's such great to have you because, in the podcast I address a little bit about agility and in each episode I know we focus on particular soft skills. This topic is something I’m very passionate about and you, who are one of the creators of the Agile Manifesto, it's very such an honor to have you here in terms of understanding, because you are the expert in terms of agility. In terms of that, you were one of the, uh, people signing the Agile Manifesto. Could you tell us a little bit about that? How did that came about?

AV: Yeah, that's an interesting one. And it's also about, you know, uh, hardcore soft skills. I, I assume <laugh> Um, uh, you know, I started working differently in 1994. I came out of a waterfall, very waterfall project in a Dutch governmental agency. And, uh, it didn't work. And on top of that, um, after seven months, full-time work with 30 people, the project was just canceled. And my, uh, personal belief is that you shouldn't waste public money, right? It should be, you can do it into healthcare or education, defense industry, if you like elderly care. But you, you need to make sure that the money, the public money that you spent is, well invested. Um, and I thought it has to be done differently. Uh, the way that what the full project worked. I was a technical designer, you know, somewhere in the middle of that whole process didn't work. So I, I started experimenting and, uh I started working with things like rapid application development in the beginning with, as soon I started to experiment more because I wanted to get better results.
And I became also very active in the community, the DSDM community and the DSDM community was a community with an intellectual property that was based on rapid application development experiences. So I felt very connected. I could see the problems that they had, the solution that they had, I could feel very connected to it. I got very involved in the D S D M consortium today, it's called the Agile Business Consortium. At the time it was the DSDM Consortium. And what I did as, uh, a part of it, I, I started to work in the community to do things for the community, traveled a lot to the UK where headquarters was, and it was, uh, February, uh, 2001. And I got a phone call and it was “Ari, there is going to be a conference in, in Salt Lake City, and we are asked to send a representative on behalf of D S D M. Uh, would you like to go?” I said, yeah. 
So I went, and now we coming to the hardcore soft skills <laugh>. One of the things that I liked so much about that weekend is that we had 17 people in the room and one of the first things that we did, okay, so the first evening is like dinner, wines. Uh, and the next morning at 730 we started, and what we did was after introduction is everybody is working in this room, is working in a different way than the waterfall for obvious reasons. Right? But what are your obvious reasons and what is your focus? So my focus was the value drive that was the most important one for me. How can I deliver value? Uh, but other people had more focus on quality or had more focus on efficiency. So we had those different things going around the room.
And what I liked is, and John Kern, he had a beautiful, uh, also not of the Edge, Agile Manifesto, beautiful expression for it. He said, when we entered that room, we left our egos at the door. And, uh, we started by explaining, okay, so you were differently. How do you work differently then? And we listened to understand. And I think that is, for me, the most important one. And what, what I see today is that a lot of people have to work on that skill to listen, to understand instead of listening to criticize people. 
So that's, that's how I got there. And, and you know, you, have all those people working in a different way other than the waterfall, but everybody in their own way, we had 13 different ways of working represented in that session. And then you start to find, okay, where do we connect? Let me, let me do this, hold on, because that's my doorbell, right? Let me do this. And the first thing that we started is, okay, what is it that you tried to achieve? And this is where the word agile comes from. And then we started working on the, the values. I don't know if you saw the manifest, but then you have the four values, right? But that was by mail. We finalized the, the, uh, the 12 principles of the Agile manifesto.

Yeah. And that was a funny, it was very funny response because, you know, you of course you have tribes in Agile and you know, people like that more, that more, I have always been an agnostic, right? From the very early years, from way before 1994 already. But I was, uh, like two years ago, we had a lot of, uh, online covid online sessions regarding 20 years of the manifesto. And Alistair Coburn said, Ari, after writing the manifesto is, Alistair is also one of the authors of the manifesto, Okay. And said, after writing the manifesto, I got hold of the DSDM and I saw the nine principles of DSDM, and we should just put a dose on the, on, on the website <laugh>, that would've been enough. Mm-hmm. Um, but I, I am an agnostic and I use, you know, by listening to understand and seeing what it brings, I use principles from test driven, development from adaptive, from DSDM, from Lean <inaudible>, uh, scrum, uh, I use practices from there, you know, to make agility really work.

YC: Yeah. That's interesting. In terms of the, I like the fact that you were agnostic, cause a lot of the times when it comes to the implementation of an organization that says we're ging be agile, they kind of focus on which framework are we going to follow.
And I wanna hear what you mentioned earlier about experiments, because you were mentioning that before you came about into Salt Lake City you have tried different things. Tell us a little bit about those experiments. What di you discovered that worked and what didn't work as you were trying to figure this way of working out. 

AV: So  let me start with two, two very important things. The first one is if you, you know, if you look at the traditional ways of working, there are three essential problems. One is we misunderstand because of the remote and written communication information gets lost, gets distorted. You know, that's number one. Um, number two, there is a lot of inefficiency in there, right? So you have, I mean, a development team does something and then afterwards the QA team comes in, and then afterwards the legal team comes in, and then afterwards and you have tollgates and, and waiting time and, you know, documents get juggled up and down. So I thought, and that was my first experiment, and in hindsight I thought, was this maybe a lucky shot or was it common sense? I don't even know. But, uh, already in, 1995, I started bringing all stakeholders together in what I call the heartbeat.
Heartbeat is a session that you do twice a week, takes half an hour, 45 minutes. Just look at what have you done since the last heartbeat? Do you have any feedback? And in that session, we have the developers, we have the business, but the other stakeholders who are not taking advantage of the solution that have a say in going life, the legal department, the security department, the architect, the department, the whatever department you have, I got them in those sessions as well. So everybody could on the spot, directly give feedback. By the end of the sprint, you're ready. There's nobody who has, I mean, upfront, you have to identify what stakeholders, obviously. Uh, but that was the number one. You know, all stakeholder sessions are crucial. If you want to cut out a delay, very important.
 But if you have those, and now the second one, if you have those people together, everybody has their own language. You know, we have the business language, the security language, the architecture language, the development language, the, you know, we have to find a common language. And I remember in the project for the Navy, I thought, how am I going to do this? So we have this session coming up, this heartbeat session, and I thought, how am I going to do this? I said, what? But this is about processes for providing submarines with stock and stuff. And okay, so we go through the process. So I took the process as it was, put it in, um, in the, in the session on the wall flip charts. And, uh, we had the, you know, we had the people, the, the marines from, from the submarines in the room mm-hmm.
And we got completely lost. Hmm. No, I started talking about the data. That was the one. Mm-hmm. I started talking about the data that was flowing around, and I still see those guys looking at me. And, and, you know, after half an hour, I stopped the session. I said stop, stop, stop. I have to do this again. And then I went into the process and I just asked them, because I had the data so long ago, I had the data written on flip charts, but they didn't get it. I mean, I was it thinking, you know, I have entities and attributes, and it's like, and they were like, uh, and then (I said) “Tell me what you do and what would help you in this situation.”  And then they would make, for example, a drawing on a flip chart. Like, you can call it a prototype, right? Very early prototype. And then I would ask security and architect guys, does this work for you? Or what are the criteria to meet? If we have criteria to meet, let's write 'em separately on flip chart. 
 So after every session, all of a sudden everybody understood what the business was doing and why they needed it, and everybody could contribute with feedback. And there would be feedback from also from developers that would say, okay, if you do it like this, it's very difficult to make very complicated. Can we do it like this? Would that help? Would that also be beneficial? Oh yeah, that, so, you know, that kind of logic came out. And so that was, for me, I think the most important one, uh, in all my learnings. And one of the biggest fails, because I remember that I, I always thought that people on the shop are very, very tiny people.
<laugh>.
There was this massive guy with a, with a blue knitwear roll neck and a red beard and glasses. And he came up from behind this table and I thought, I think you're not happy now. <laugh>. So that was, that was a big learning. Um, and maybe another learning, uh, but that's more generic about agile. You know, when I started doing this, for me it was like common sense, right? This is, I always say agile is structured common sense, but you have to understand that structured common sense is on this level. And then the level below, you need the organization to facilitate that kind of work. For example, all stakeholders in a session. That means that the stakeholders need to be empowered to say yes or no on behalf of the one, the department or whatever that they represent.

And that's difficult. That's very difficult. Uh, because people have been brought up, have been educated, have been raised, you know, you get new as a junior into the company, there are the seniors, they will tell you what is, if you have a brilliant idea, they will cut it down because, you know, this is not how we do it here. Um, and that transformation, what is, for me, common sense is, um, is a difficult one still today. I was talking tomorrow about it. I had another call, um, and I, literally got triggered into diving in, what, what is the big problem here? I was at, uh, an organization struggling with projects all the life. I did three projects, happy client in time, on budget, right? Very successful. And then the, CIO came to me and he said, Ari, um, I know you're doing well, uh, with your projects, but we're not going to work like this because it's so complicated.
And I thought I put people at the table together and make drawings, and, you know, diverts converts. It's not, it's not complicated. No, this is not complicated. But the level below that's complicated. You know, that surface of doing agile, you know, you see, we do sprints. Yeah. And then we do a sprint for design, and we do a sprint for development, and we do a sprint for test, and we do, you know, okay, so people copy the words, but that, that deep level, you know, where you really understand what it is, that's a difficult one. And I also think that's why agile transformations are, uh, not easy. Let me put it my own thing. Yeah. Big learning was that one. Yeah. What is, what is common sense to me is not common sense to somebody else, right?

YC: Yes. Yes. I, that's certainly one of the challenges, and I've seen in terms of, I've been working in military organizations, is the whole empowerment to be able to make decisions as well. How do we address that? How, when it comes to, uh, people feeling empowered to make decisions or at the bottom level or at the, the mid level, what are some of the ways that that can be addressed to help, uh, an organization become successful or a team become successful?

AV: Well, you know, if I use a sports metaphor, you have to agree on the rules of the game before you start the game, right? Mm-hmm. <affirmative>, um, and this is why this is one of the practices that I use from D S D M, the Agile project management framework is the foundations and foundations is focusing on, okay, what is the value? What kind of requirements do you need to achieve that value? But also it is about getting identified all the stakeholders and how to collaborate. Um, I have to admit that maybe the easiest organization to do agile is the military. Because I remember, I remember the project from the Navy, so his rank was Captain on sea, which is, means basically you're the boss of a boat, right? That's, that's basically, and in the preparation in that foundation, I said to him, listen, you know, I want the people to talk, to explain, and it's not about what you think, but it's about what they need.
And they are the ones to know. They know the best, what they need to do their job in a proper way. He said, yeah, okay. So in the workshop, that heartbeat and in the foundations, you have longer heartbeats to identify, prioritize, and estimate your requirements. Uh, I said, I want people to speak freely. So  really want to set that scene before we go in. I said, can we do this? He said, yes, Ari, I can do that. So we get into people in uniform, and we get into that room and cast it up. He said, ladies and gentlemen, I want you to say this is, you know, for the solution that we need on board when we're out in the ocean and today in this workshop, we are all equal. And I go back, yes, sir, yes, sir. <laugh>
I mean, it was brilliant. What you see, uh, especially in commercial organizations is that people have been, uh, creating a path for their own career, and they are afraid to lose their position. So they wanna keep their position so they will continuously overrule people mm-hmm. <affirmative>, uh, and not acknowledge them in the authority that they have. And I always say to managers, when I do an HR delivery, listen, you don't understand their business. You understand your business. But what they do, what they need under their fingertips is up to them, not to you. And I want you to understand this. So if they say, this is the requirement, and of course, in the heartbeat, you have interview techniques that identify the priority and the value. But if they say, this is what it is, that's what it is, don't overrule them. Right? You have to set that scene. That is a very important one. And in the military, it was great,

Yeah. And I always say, you know, if you look at the metaphor of a self organizing team, and people might correct me on it, but what I feel, if you look at the special forces teams, right? Everybody, they don't have the same profile. They have a lot of things that they share, but they all also have their specialism, right? And they train and they go in and they agreed on their how to, our collaboration, how do we work? But things happen. And then as a team, you finish the job. And when things happen, uh, and somebody can't do it, somebody else will step in and do it. And that's, for me, the very agile, as long as you keep your eyes on that end goal, that value that you want to create, that's where you go. So

YC: That's great. And, uh, great that you mentioned in terms of emphasizing the delivery value aspect and also, you've addressed the approach from the top level when it comes to adult transformation in an organization, will you see that the most effective ones start as a top level approach? Like the leadership mentioning, ‘Hey, we're gonna do this, and everybody kind of, um, adopting that? Or do you think grassroots efforts, um, would work?’ 

AV: Yeah, honestly, let's look at the practical side. What is we see in organizations? And I mean, we are now 22 and a half years after writing the manifest, right? So things have happened, um, in most organizations, in the teams, you see that people, you know, they go to conferences, they hear from colleagues or from competitors even, and they start to experiment with little bits and pieces of agile. What I have seen in the, in the, you know, since the manifesto, when I do agile transformations, in the beginning, I got approached by project managers, and then later on I got approached by the CIO. And these days you get approached by either the complete board or people from the responsible for the business on the board, because they can see there is a need, we need to change something, right?

If you go into a corporate transformation, uh, or an organizational transformation, let me put it like this, you can't do without the top level. It's very simple. Um, you know, in the terms, the two things, one, people don't like change. Nobody, 95% of the people or more don't like change mm-hmm. So they are very reluctant. So they need a role model, you know, to create some sort of safety that they can start doing it. And who is the best in being the role model for that kind of thing, the top of the organization. So the, that the top starts working in an agile way, they are more easy to adopt. That's number one. And the second one very important is, uh, the fact that you need change in the organization. You know, who makes the decision? How do we document, how do we deliver, how do we collaborate, uh, you know, all these kind of things.
And especially when it comes to formal changes, that's what people in the teams can't create. I mean, that, that requires an authority to make that happen. And then there is one more thing. Uh, number three is sustaining that change. You know, the, what people forget is what, what managers think very often is, you know, I sent somebody to a two day training, and now they are the expert, and miracles will happen, <laugh>. Um, and what I always say to managers when I'm running my leadership program is, you have to understand that people are going to do things that they've never done before. And the two things that happen if you, if you, uh, start doing things that you've never done before, number one, if you have a problem, you don't have the solution yet. You only have old solutions in the back of your mind, but not the new solutions, right? So you need to make sure that you allow people to innovate forward, okay, we have a problem. How do we solve this? Of course, you have coaches, very important, right? So you, you get the, but don't innovate backward, and that's what most organizations do. And then, yeah, the, the, the second one, and it's hidden is really, uh, and I had even this week, I bumped into myself again. You know, I'm actually looking at the new kitchen at the moment. It was finished last Tuesday.But I started work, uh, living here almost 23 years ago.
(21:12):
And I had my trash bin behind one door, and it was 2014, 2015, I don't know. And I moved the trash bin from behind one door to another door. And last summer I was here, you know, cooking, and my son comes in and he sits at the bar where I'm sitting right now. We having a drink while I'm talking and cooking, I want to throw something away, and I open the old door. It's behind, it's behind the new door for seven years. Uh, and even, even yesterday, I wanted to throw, and I was on a call, I wanted to throw something, and I opened the old door again.
Now, the point is, uh, and I like to make the metaphor with, uh, my girlfriend is from South Africa, right? So the drive on the left side of the road, I'm from the Netherlands, we drive on the right side of the road, uh, andI can learn, you know, the rules, because the rules are different. The signs are different, not all, but quite a few. You need to understand the habits are, um, and when I, when I go into that kind of training, driver lessons or whatever, you know, I, and somebody's next to me telling me, and like, okay, you know, I go, and when I'm alone in the street of Johannesburg, I'm okay because I can really consciously think about the rules and do whatever I need to do. Big problem, however, is that, um, I'm never alone in Johannesburg traffic, and it's always somebody else who does something I don't expect. And this moment is the moment where my reflexes come in, and my reflexes are based on driving on the right side of the road. I always say, you don't wanna sit next to me in Johannesburg Drive
<laugh>. And that, that the, the sustaining the chains by innovating forward and understanding that we have those reflexes that will also, uh, catalyze, innovating backward, right? We have to be aware of it. Uh, transformation is not easily done. Yeah. And that's something that, you know, when we wrote the manifesto, we never thought about it, but it's, this is a difficult thing. Yeah.

YC: Yeah, that's great points. 

AV: In terms of allowing people to, to truly innovate. Like when they come in, when we talk about transformations system, the, the whole, actions that guide it. Yeah. And I wanna tell you that, you know, I see so many people say, oh, I'm an agile coach and when I zoom in, they have just certificates for one or two frameworks, right? So they don't understand the agile that they just do understand one, uh, one framework or maybe two. Uh, but to make that deep change, that paradigm change in an organization requires psychology, trying, understanding the human brain. How do I approach this change? What do people need? How can I make them take that next step? Because you take it by baby steps, right? So, um, I think agile transformations are highly underestimated, highly underestimated estimate.  So, yeah. Um, for me, common sense mm-hmm. <affirmative>, but, uh, not easy to bring into on the corporate level to an organization for obvious reasons. Yeah,

YC: Yeah, absolutely. One thing, um, wanna talk a little bit about soft skills, um, because you mentioned, uh, listening as an important aspect of it. What other skills should we, as individuals, um, should cultivate or practice in order to make, agility effective in an organization or in a team?

AV: Yeah, so the listening to learn is the number one. Finding a common language is very important. Um, it's, it's about, um, accepting people in their own behavior and accepting people with their strengths and their weaknesses. Sothis morning, I had a conversation and the one that I was talking to said to me, Ari, you know, my developers, especially after Covid working remote, they don't like to talk to other people. They just wanna sit behind the screen. They said, yeah, but that's the old school profile. The profiles have changed. Communication has become more important, but it doesn't mean that everybody has to be a communication expert. So this is where, for me, where the product owner role comes in, you know, in that all stakeholder session, the product owner will, will facilitate the communication, and we'll make sure that everybody gets a turn. So the, the skill of facilitation for product owners is, uh, is a key success factor. Um, and I think it's with everything, you have to understand that not everybody has to be good at everything, but then we have to be open and spend the bucket. This is what I, what I'm not good at. Okay. So in the team can do this, right. And allow people to do that. That's very important. 

YC: Thank you so much for sharing your expertise and, and your time here and for all the information and advice that you have given. If there's one more thing, um, in terms of a first step, like, let's say we are in, in an organization that wants to be agile, or even us as individuals that we wanna be agile, what would be a first step that you would recommend, uh, that you, that we should do?

AV: Um, the most important thing is that you do, the call I had this morning was about, oh, um, just give you an example. Okay. Um, yeah, you, you know, we have this quality problem. Okay. So, you know, implement practices from test driven development and extreme programming, and you will be there, do test driven development. No, that doesn't work for us. Excuse me. No, that doesn't work for us. Did you do it? Uh, no. Did you try it? No. And this is the number one, don't be afraid. Accept that learning means making mistakes. And, uh, that's on the people. You know, you need to, that, that when things go wrong, it's doesn't mean that you don't get a salary raise or anything like this. Um, and the top has to understand that people are in a learning curve and they, they need to be allowed to be in a learning curve. 
You don't like making mistakes, but we make mistakes and you should learn from it. And that, that is the number one, start doing it. Start doing it. And, and  it's such a habit of people. You don't wanna know how many times I heard in the past, where are we, you know, almost 30 years that I do this, oh, this is a great idea, but it doesn't work for us. Mm-hmm. And then did you do it? No. Okay. Come on, get serious <laugh>, how do we cook? We cook a recipe by doing it for the first time. Yeah. And when it goes wrong, we say, okay, what went wrong? How can I improve this one? Yeah. Right. I mean, this, it's so simple, but that's obviously in the psychology of men and women, everybody, uh, is a, is a difficult one. And you have to create that safe environment where people can do this. And it's from both ways, because we always talk about, oh, you know, the management, of course the management. Yeah. But what do you think about people in the teams? You know, sometimes they almost kill each other, right? So we have to allow people to experiment. It requires strong people in the role of scrum master or agile delivery manager, or agile coach, or whatever role they have, you know, helping the team forward.
It's, it's a, it's not an easy job.  You have to be persistent, right? It's not that, oh, you know, we want to lose weight. Um, so, uh, we have a diet for breakfast and lunch, but you know, for dinner we can have anything we like. And in the evening we can eat candy and cake and, and no, no. You have to be disciplined. You have to do, this is how we do it. This is where the collaboration agreement comes in again. And don't be afraid to stick because you're in a learning process. Accept it.

YC: That's great advice. Thank you so much again, Arie.  And what's the best way for people to contact you or if they wanna know more about your work?

AV: Um, well, they can go to my website. But it needs heavily updated, I'm working on it at the moment. Um, LinkedIn is the easiest way. And um, uh, when you are connected to me on LinkedIn and in the direct message, you ask me a question, Hey Ari, how do you do this? Nine out of 10, within a couple of hours, you have an answer. And I have the tendency, when the answer is too long, I just say, okay, send me a, send me a Zoom link and we have a short call or a WhatsApp call or whatever. 

YC: Great. Thank you so much.
AV: My pleasure. All my pleasure. I wish you success with next episodes, and I hope to get some feedback from your audience.

YC: Absolutely. Thank you very much.