 Hi, my name's Jeff Watson. Welcome to another episode of In Conversation With. Now, this episode I've called Dutch people are the most difficult, said a Dutchman, not me. And in this episode, a good friend of mine, Niels Verdonk, came over to London from Agile 42 in the Netherlands to help co-teach a CSM class with me. Now, at the end of day one, we sat down for a completely unscripted conversation and we started talking about the differences between UK classes and classes in other countries. Which led to us talking about the differences in culture within countries and across countries and across companies within countries and ultimately how different cultures align differently to the Agile values and principles. After that, the conversation morphed into how you might be able to apply scrumming non-software environments such as jet engine design and build and creation of bed linen. Anyway, I hope you enjoy In Conversation With Niels Verdonk. The Dutch are the most difficult, said a Dutchman, not me. How you doing, mate? Very good, Jeff. Good. Thanks for doing this. Yeah, so I'm going to squeak a little bit. We need a bit, that's the chair, that's not our joints. The fields of it, we've finished the day's training. Yeah, rusty. So Niels came over to help me out and cover me and supervise me and we're both fans of pair training as well. So when we get the opportunity, we try to. And then we've just finished day one. Day one of the CSM in London. How do you feel about that? Yeah, it's pretty good. It's nice to see a different type of training format from a trainer and it's always good to have some inspiration. Would you say that this audience was any different to a typical Dutch audience? So in this class, typically, we had a good representation of both the ends of the spectrum. So quite some really experienced guys there, like four, five, six years. And also some people that has, like, what's Chrome is an acronym, I don't know. We didn't have a lot of people in the middle. So I'm always a bit concerned when I have people that have like four, five years of experience with Chrome because they might be bored easily with the basic stuff but we still have to cover the basics. We have to make sure that everybody is on the same level that comes to the basics of Chrome. The experience you guys behave. That's it. And then you can bring them in right. So they've got a lot of experience to share as well. So just because we have experience doesn't mean that it's the only experience. That's part of it. So we've got people who have been doing this for a long time, sitting with people who haven't, and yet they can, when we give them some questions to answer, often a lot of these questions don't have a right answer so they can explore different perspectives and things themselves. They almost become auxiliary trainers, especially the experienced people. Yeah. So we had a conversation at Coffee Machine with one of them and I don't know who was saying it was, but the best way to learn is to teach others. So it's an opportunity for them to teach and to try to summarize their understanding of Chrome in a short, concise passage will also help them to improve their understanding of Chrome. Yeah. And that's something we need to do. We need to be able to explain to people. Let's do another one. So my daughter has just finished some of her exams, school exams, and she has a sort of revision process, you know, where she goes through it. She reminds herself, highlights things, then goes through them again, and actually sort of writes out the things that she's highlighted because writing it helps her just remember things. And then she'll say, can I tell you something? Yeah, tell me something. She tells me about this chemical procedure or whatever, and just by telling you, you helped me understand it a little bit more. So you learn things in a different way than you when you're telling other people. So you have to also appreciate what level they at and then explain it in sometimes layman's terms because otherwise you might blow them out of their minds. I'm interested in the sort of cultural, if there are any cultural differences. So I used to teach in different countries quite a bit, but I don't really do much anymore. And you do. You teach in Germany and Belgium and different places. So would you say there's any difference from country to country in terms of class attendees and culture and things? Yeah, I think those people are the most difficult. You can say that because you're deaf. Yes. So I think in the Netherlands, I think people are quite vocal and maybe we'll be asking endless amounts of questions about insignificant things. So we have to slow them down a little bit. I did a training course in Croatia where there were hardly any questions. And I was like, okay, this can't be right. And it turned out that a lot of people in the class or 26 was a large group who were sort of mandatory going to this class and signed up by the raised art department. So through agile, you're going to do the product order class. You're going to do the schromads class. So prison is in a trend. So they were probably not as engaged. Whereas if you have a public class like this, people that's individually signed up for this, maybe even paid out of their own money go much more engaged in the class. Yeah, I think it's probably not dead. So would you change your facilitation style if you were going to run a class in Germany, for example, compared to if you were running one in Germany? Yeah, but of course, if you were going to run a class in Germany, it would be a bit different. If you were going to run a class in Germany, it would be much better. Yeah, so a lot of people think Germany is a very big place and culture in Germany is also quite widespread. I'm speaking in the area of Usudorf and I have a lot of people who are very vocal, very spoken, and sometimes I'm made a bit more traditional area of Germany and you don't sense a lot of how to do the class which you have to add, build in a couple of more feedback loops and check the temperature of the room. Because that's something I'm going to question today which we get quite often with how do you deal with sort of geographically distributed teams and you've got a mix of cultures there and adapting your facilitation style to encourage participation from different people in different cultures. That's quite a challenge for people like that. Yeah, so I believe that the Eastern European cultures are quite compatible with Scrum. Because they don't go back, they are outspoken and they don't have a problem with stepping in somebody else's toes. This is good of getting the message across and making things transparent. I also have some experience with some teams in India or Mexico, China where people are a bit more used to, you know, the boss is always right and you don't go against the opinion of the boss or they're even in the room, right? So I once had a team where I was coaching the Scrum master attending a couple of Scrum meetings and I had a conversation later. So we didn't hear this person, that person at all and the next time I was trying to draw them out I really asked them a question on the person and asked them to contribute but they still were very reluctant to speak up and sometimes when I asked them a question somebody else started to answer and then later I figured out well, that person is the other person's boss so he's not going to, or she's not going to say anything in the presence of their boss and when you ask the question to the subordinates I know that's a good term but the boss will answer on their behalf and that's probably very cultural. South Africa also has a really called a paternalistic culture so more respect for the senior or seniority in organizations. Is that going to hinder an organization's ability to be agile, right? Yeah, so it's going to be harder to create that I think what we would call it these days psychological safety in an environment where people can speak freely without being afraid of sipping on somebody's toes or rubbing somebody in the wrong way. I'm a firm believer that all of these behaviors that we see are positive in intent. So that manager who's answering on behalf of their employee, they're doing that for a good reason perhaps to protect them, perhaps to... I don't know, but how do we then help them understand that actually there's another way of doing it that's more helpful? How do we do that? Yeah, well first of all I think assuming positive intent I think is probably a very good standpoint to start off as a coach, no judging and it starts with making them aware of in what way that limits them their ability to be an agile team and it's probably going to be more difficult if it's very strong value in their culture either organization or culture or the culture of a country and once they actually buy into how that limits their ability as an agile team maybe they're able to overcome it and initially it's probably going to be unnatural for them to do that but hopefully by doing it more often it becomes more natural to do that and they want to feel awkward sharing There's a little bit of that conscious competence model to begin with at the moment that manager isn't aware of their incompetence it's not much worth to use but they're not aware of that and then as a coach we can help them become aware of that hopefully without making them feel defensive or judged if there's something in it for them if they can see some value and some benefit and there's a possibility if they believe it's possible to change then they can start experimenting with that change and to begin with they will be consciously incompetent because they won't be very good at this new behavior and they'll have to baffle through that and repeat it with help and support and learn until they become unconsciously competent in their new behavior there's a difference between behavior and culture so I've yet to find a culture that hasn't had something or hasn't been able to find something in the agile values and principles that fits with their culture yet I haven't found a culture that doesn't find some aspect of agile challenging and so to adopt that way of working which if they agree is appropriate and valuable to them they're going to have to look at the bits of it that they do get value from that do match up with their culture and attach to those cultural alignment pieces well then letting go of the behaviors that undermine those cultural things giving value yep yeah so I think my experience is that the cultural differences from countries around the world I think are probably closer to each other than the cultural differences from some companies within a certain country interesting so in Germany you might have a very big difference in cultures I'm working with the start of Berlin developers are coming in N30 and working until very late and have a very dynamic open culture and then you might also have a very traditional enterprise type of organization where things are much more hierarchical yeah more German if you will so that scale I think it's wider for me then just to say well the culture of Germany is much different than the culture of India because I've also worked with teams in India that have a very open culture and were able to collaborate quite well and discuss uncomfortable topics quite openly so yeah I think it's culture is something that is related to the country but it's also related to the company how long would you say in your experience it takes to change the culture of the company in some cultures it will take longer than others in an organization where people are used to to to hold on to knowledge because it's their job security it's much harder to create a shared learning environment and I don't think you can put a time on that a culture organization where we split a group of or a large group of developers into two we thought equal groups with a good mix of personalities and skill sets one group was hitting it off, had a very nice dynamic in a team had psychological safety open knowledge sharing another group was going nowhere and could you have predicted that from a property not it was also very difficult to pinpoint so I think sometimes chance or luck is also involved, it's not something that we can all predict but then we'll have to dig in and figure out what is what holding that team back not needed to ask I mean it's a rather fair question because if I was to ask myself I'd probably answer something along the lines of I don't think there's an end state so if you don't have an end state then you can't really have a duration it's kind of a continual evolution based on continual inspection and adaptation but there is a shift and that kind of tipping point if you like where you have confidence that in any given situation or in a given situation anybody within the organization would act in a similar way based on values that's the kind of thing where you're all talking years rather than months so that was a perhaps an unfair question for me to ask we started the course today with do you have any questions that you want us to cover do you do that regularly do you do that kind of thing? usually people sign up maybe their manager is paying for the course and they're sort of expecting you better come back with now sometimes come with a preloaded set of questions so I think it's important to collect them so I typically do that also to collect a question list do you have the same ones every time? yeah we didn't have one about estimation on it which is normally so yeah the interest in the retrospective is obviously something that comes up often but how to convince senior management of the which is also one that's quite quite common I quite like it when people are coming from a different context so today we have people who are building airplane engines and we have people who are trying to apply this in other non-software environments and I like that that makes it different to me because I know we're going to get different conversations I don't have the answers for them necessarily because I have no idea about jet engine but I know there's going to be something interesting whereas if everybody turns up with the same questions they should be the teams keeping things interesting in retrospectives convincing senior management what about project manager these kinds of things that happen every time and everybody's going to get it so can you apply scrums of building a jet engine okay cool that kind of thing yeah so I actually get a fair amount of people that are not working in a software environment I get a lot of questions from email hey thinking of a 10-year-old class but I don't come from software it still doesn't make sense for me to join to explain to them that half my coaching engagements are with non-software companies or at least not only software companies and the people that are getting in the classroom are I'm not saying half of the people but by the large number of people actually not working in a specific software environment was your favorite non-software environment that you've been coaching teams in well I like product development broad perspective of product development I mean there's in many cases some software involved but I'm also doing scope coaching for a product that has zero lines of coding like bed linen, flight switches insurance projects marketing teams so it's a lot of fun it's a little more challenging so how can you make bed linen more agile? well by focusing on the value you deliver for the customer and I think you can do anything with agile as long as you figure out how can we deliver value to the customer iterative and incrementally and validate what we deliver to the customer so in the example of the light switches there's a hardware cycle that's quite long because you have to make plastic molds and send them off to China and then wait until they actually ship the samples via a ship in five weeks there's a lot of delay in feedback so you can have to challenge yourself and find a way to shorten the feedback loops also in electronics so you can have these dynamic circuit boards where you can just stick some wires in the circuit boards and some people with resistors and transistors and blah blah blah it's going to have a product wire sticking out everywhere at least you have a shorter feedback loop and you don't have to do the design of the circuit board completely upfront remember when in the old days of some development the DBAs always said no no no you can only design the data model once you have to do it right before it's time and those were usually the most difficult ones to convince of an agile approach and you also have those in the circuit board so if you have a way to dynamically design your circuit boards iteratively incrementally emergent if you will, then your CRLs can add a next level of agility to your projects otherwise you're only resorting to doing more design upfront so you're a big fan of using agile and also the software world yeah, yeah you've seen, it was a while ago I think but I remember seeing something on Twitter from Ron Jeffries who seemed to be quite angry about people using scrum and agile and also the software world said don't do that because we started and sorted the software world yet, that's what it's for do you see that? I didn't see that in the specific tweet but I know some people that are mad about the term agile being abused in all kinds of different things and yeah, it sometimes annoys me a little bit as well you've seen an article for a former project manager that was exposed to agile in the last three months and approached something that linked in his perspective on agile and it just agile is a Spotify or agile is safer they missed the entire history of the agile manifesto and how it involves and I guess guys like Ron Jeffries and Jen Hendrickson and all those guys are the old generation that was actually at the birthplace of agile and a little bit more protective of it you can easily apply it to any type of product development and what product in the age of Internet of Things is software only no, it's a project so software is an Alexa or whatever kind of Internet of Things connected device there's hardware and software parts to it and they should be developed hand in hand it's not like oh, we've finished with hardware a guy who puts some software in it please that's not making sense no, it's not done software is not done, is it no you just started quite a few people's home persistence off there they make videos and they'll say hey Alexa order me some more wine because people are watching it they're device people are having a wine order for them you just ordered 1000 bottles of wine Alexa sorry that's probably our key to go thanks for chatting me good to see you again