Podcast Ep24 – Yves Hanoulle – How Solving Your Own Problems Can Lead To Great Collaborations

This is the twentyfourth in a series of podcasts where Judy interviews people who have a track record of successful collaboration.
This series is for anyone interested in the nuts and bolts of real-life collaboration, especially collaboration among creative, intelligent, free-thinking individuals who are geographically dispersed. The interviews go well beyond the obvious, as metaphor master Judy Rees explores the hidden thinking that inspires collaboration that works.

>
Judy: Hello and welcome to the collaboration dynamics podcast! With me today is Yves Hanoulle. Hello, Yves!

Yves: Hello!

Judy: Great to have you here. I’m very excited to have you on board, because you have been recommended by a couple of my students who I know have worked with you in the past. Would you like to introduce yourself and say the kind of things that you’ve done in terms of collaboration?

Yves: My name is Yves Hanoulle. These days I call myself creative collaboration agent. This is the name that I like to differentiate myself with. I do a lot of Agile coaching these days, but next to that I also do a lot of community things.

I’ve created a few books and articles that I’ve done in a collaborative way, basically over the internet. People all do it from their own home or from wherever they want to do it. I like doing that. I like bringing communities together and creating things. Usually, it starts with me having some kind of problem that I try to look for a solution, and then I realise, “there might be other people who have the same problem.” So I share whatever I have and I ask more people if they want to join in and help solve the problem and help everybody else at the same time. That’s how I got started a few projects in the last years.

Judy: So interesting! Before I ask you about that let me ask you the question that I ask everyone who comes on the Collaboration Dynamics Podcast. When you are collaborating at your best you are like what?

Yves: I think, at some points I might be even tired. What I’ve realised is that when I’m tired, there is less filters and there’s less things, and I feel that I react much more from my gut feeling. Then it can go in both directions: then it can be either really good or really bad.

It’s not that I should say I will always not sleep and then I’m always at my best. That’s not it. But what I’ve noticed in some moments that I was really good at interactions, that limit of boundary that was not there, and I ask for help a lot more, and then a lot more happens. That’s how I feel of some of my good moments.

Judy: So, there’s that limit of boundary that’s not there. And then you ask for help a lot more. Say more about that. How does that work?

Yves: One of the things I’ve learned along the way is that most people don’t ask enough for help. I’m not going to go into details now, but at about 19-20 I learned really asking for help. Before that, I wasn’t really good at asking for help, but then something happened that really made me ask for help because basically I had no choice. But at that time I did it when I was in trouble and I needed people to help me.

But what I’ve learned in the last 20 years, since then, is that actually asking for help when I think everything is okay, and when I think I have everything under control is actually even more powerful. And that’s something I didn’t do before. I thought I needed to be smart and to be able to do everything on my own. Because somehow I learned or I picked along the way that asking for help is a sign of weakness and I shouldn’t do it too much.

What I learned in the last 20 years, it’s actually more of the opposite. The people who get most done, ask for help a lot more. Still, I notice that even if I do know that, I might not always do that enough. When I’m tired, I think slower so I might not know everything I need to know, and I might be much quicker asking for help. There’s also less boundaries in the sense that, “I should not ask this or that person. What will he think?” I will just blurt out and ask for help.

Sometimes people sought me out and said, “Sorry, I’m not going to help.” In most other cases they really want to help, because that’s what people are. People want to help out. When I ask multiple people for help, I am always surprised about the ideas that people have that I didn’t have. So even if I would be fully awake and would use whole of my brain, that would still not give the same results as asking so many other people for help.

Judy: Even though you’ve learned all of that, even though you’ve had all that experience of asking for help, it’s not when you’re most awake that you ask for the most help. It’s actually when you’re tired.

Yves: Yeah. I see of course, a lot of the collaboration I do it’s when I’m at home in the evening, when I am, of course, more tired from a day of work. So, it’s just also in timing. But I think that even after everything I’ve learned, well, the first 20 years are really teaching people a lot, and there is some kind of muscle memory that we don’t do that enough. And even with everything I know it’s still sometimes, “I should ask” or “will I do this?” and I just have a lot less than in the evening.

Judy: To pick up that theme of that less boundaries, less filters – when it’s like that, you are like what?

Yves: That’s an interesting question. I’m tempted to say I’m much more like a child, but I don’t think that’s the truth, but I cannot come up with something better. Yeah, it’s the best thing I can come up with right now. I’m much more looking open to the world on what’s happening around me and open for opportunities and for help that I can get.

Judy: So, a bit like a child. Not really like a child but open to the world, open to the opportunities like that. And is there anything else about how you are when you are like that?

Yves: You mean, when I’m much more open?

Judy: Yeah, when you’re open like that.

Yves: I think, in a way I’m more relaxed. I am a person who likes to be busy, to do stuff. When I’m tired, I might not have full adrenaline rushing and because of that I might be much more relaxed, which helps as well.

Judy: When you are like that, when you haven’t got so much adrenaline, you are open to the world, open for opportunities, a bit like a child, less boundaries and more willing to ask for help. And – you mentioned earlier that the kind of collaborations you’ve been involved in have started when you’ve had a problem of your own you wanted to solve?

Yves: Yes.

Judy: Say a bit more about that. How do those two fit together?

Yves: Let’s give an example. I think it might help here. One of the earliest collaboration things I did in about 2007, I just switched my whole e-mail system to Google, Google domain. I had a calendar and I had the options in Google to create extra calendars, so I said, “I have one for my wife, one for my child, I have one for myself, I have one for a big client or something like that.” And then I realised, that I go to a lot of conferences to talk or just to visit. It might be interesting to have a calendar for all the interesting conferences.

When I created that, I added about 10 conferences that I knew that existed. I thought, that I usually go there with a lot of other friends, so why don’t I share this with friends? Google asked me, “Do you want to share it in a read-only format or do you want to give people full read-and-write access?” And it was like, “But these are friends, let’s give them full read-and-write access, so they can actually add other stuff to it.”

Over the years, now I think there are 70 to 80 people that I shared this with and that are actually filling in these calendars. Now we’ve split them up into three different types of calendars. And I actually don’t add any events to these calendars anymore. Most of my time comes into administration: adding people or when I receive an e-mail that somebody deleted something from the calendar, I politely ask, “Are you sure that this is conference doesn’t exist anymore or is it just because you thought you were in your own calendar and you removed it?”

Or, as it recently happened, when somebody added an appointment to the hairdresser to that public calendar. I am not busy anymore with adding stuff by myself, just with the administration part, but, yes, it’s maintained by pretty much over 70, even nearly 80 people right now, who are adding stuff to it.

Judy: In terms of the usefulness of that, how has that ended up being used?

Yves: I know that a few conferences are using it also to look at when other conferences are happening. For organising their own, they look what’s in there. The main calendar, Agile conferences calendar, has a public URL, so I have no idea how many people are using it, but it keeps getting published and I keep adding other people that tell me that they have used it before. The data is actually used in a kind of ‘folk project’, where they show the same conferences but with a location map and stuff like that. It’s not 10 000 people, but I still think there are hundreds of people that are using this one. In that sense it’s a nice project.

Judy: Very interesting. An example of something I also wanted to ask you about specifically is a collaboration that is not a face-to-face collaboration, but a virtual collaboration.

Yves: It’s a really interesting case because we never have meetings, we never do anything. The work is actually completely independent, because you think, “There’s a nice conference. I’ve noticed it’s not on the calendar.” You can just add it manually and we don’t need to have any interaction there.

At some point I did create a mailing list just to have some conversations, because some people are asking me, “can I add this?” or “can I add that?” I wasn’t always sure so at some point I said, “Instead of just me taking all these decisions – again, I’m a bottle neck, and maybe it’s not just about me – why don’t I create a mailing list so that people can have some of those conversations?” But it’s really very limited – I think, it’s one e-mail every week, probably not even. There’s very limited traffic on that mailing list, but it’s there for when we have some kind of discussions. We can have some discussion.

But as I said, there is no meeting. In that sense it is not really a project, because all of the tasks are completely independent. But people are doing it and it’s scalable that way. People from all over the world can do it. That makes it also interesting. It’s not just about “I’m from Europe.” People thought, “Oh, this is just a European thing.” “No, there are actually a lot of Americans helping out.” It’s really a global thing. There are Asian conferences there as well, and Eastern Europe conferences are in there, too. So it’s actually used all over the world.

It taught me a lot of things about remote collaboration because it made me realise that in some of the other projects that I’m doing there are also no meeting. Actually as an Agile coach, I don’t do this like e-mail, because I know it’s not the best communication tool, but for most of these projects, e-mail is actually the tool that we use to communicate. And what it made me realise, is that in Agile, when they say co-location is best and we want people blah-blah-blah. And I agree – when we put people together, things go a lot easier. But that’s really because we have much bigger trust and because it’s the biggest way of communicating if we’re sitting next to each other, we can look each other in the eye, it helps in a lot of things.

And yes, when people are in another country, it’s hard, I know this. When I’m one week in another country even communication with my wife is harder because yes, we are separated and it is not always easy.

And still, when you have enough trust it can work in a different way. You just need to find ways on how things work. One of the things that can help is if the jobs or the tasks are completely independent, then there is not much need to communicate.

But of course, when this person added the hairdresser thing into the event – yes, there is some communication, I need to ask, “Why did you add it? Are you sure?” in a polite way and not to make them feel too much embarrassed. It was actually a really funny situation because, of course, this person removed it immediately. Then 10 minutes later somebody added it again, which was a joke, I assumed. It was the exact same data, so it was not somebody else who added his or her hairdressing, it was exact same thing – I found that really funny.

That led to a very nice conversation with the three of us in e-mail. It almost shows that you can have these kinds of jokes in a virtual team, which always helps to create more trust. It was interesting because one of them, the person who added it – I don’t remember the exact name – but I’m pretty sure that I’ve never met that person. So it’s funny ways how we can have a little bit of fun with each other without so much damage. Even without knowing each other we dare to do that kind of fun stuff.

Judy: There are so many people who would say that that’s impossible. I mean the people who created Agile originally said “you have to have co-location, you can’t do it remotely”. And yet, we know you can do it remotely. What’s the trick? What makes it work?

Yves: There are multiple things. One – when Agile was created in 2001-2002 when they created the Manifesto, and all the Agile methodologies that were created in the 90’s, we didn’t have all these tools. We did have the start of the internet, but that’s really the start. A lot of tools make it easier. That’s one.

Next to that, I agree that the best way to work in an Agile way is to be co-located. But I look at that from a different point of view because Agile should never be a goal. Agile is just a tool to help you. Sometimes distributed is the only way to have it. I’ve worked with a Belgian-Russian team and the reason why we worked with these people from Russia is, first of all, we didn’t find more people in Belgium but more of it, they were some of the smartest people I’ve ever worked with.

This was really not about outsourcing for money or saving money. This was really outsourcing to find the brains. For me, this is doing it for the right reasons.

And then, the opposite becomes true. If you want to do it distributed, for me Agile is the best way to do it. Because a lot of the tools and a lot of the things that we do both to mind-set but also a lot of the practices are there to help us communicate better, are there to create much more room for the team.

So, one of the things that we had, we had built servers on both sides – both in Russia and in Belgium. What I’ve noticed about developers is that they might not always like to discuss, and they might not always like most people, they don’t like feedback. If someone tells is it’s wrong, we don’t like it. But if a computer tells you that something is wrong, we accept it more. Especially, developers. Mostly because they know that if a test tells that it’s no longer working, if we’ve written the test ourselves, basically we are dealing with ourselves.

It’s a previous version of us who told us, “You need to check this.” Then six months later I forgot about it, and now I’m just reminded of something that I knew six months ago. That helps. If you now have two sites, it could be that when something is wrong, I could have written the test or it could be someone else, a colleague of mine has written the test, in most cases it’s the same thing. It’s a computer telling me, “You forgot something.” It makes it easier.

Now, if I have to test something – if I receive a new version of some software that’s coming from another country, from another place, Russia or Romania or another country, I need to test and do some stuff, but if actually my computer is already checking for me, all of these things that I knew before, it actually helps the communication. The Belgian-Russian team, at some point we had 16, and I think, now this team has 20 or 25 thousand tests. It doesn’t tell me that nothing is wrong. It just tells me that 20 thousand things that worked yesterday are still working today, or not. And that helps the communication. It can help us focus on what we need to do.

On the other hand, another thing that I did especially with that Russian team, actually it was very interesting. I talked on Skype. Skype was, I think, two years old or something like that, so that was a new technology. We used it. We used it a lot. With one of my colleagues in Russia, in the beginning, I talked either over chat or just talking for 6 to 8 hours in a day.

That is expensive in a sense that I was not programming, that person was not programming at that time. We did invest in that because it was helping to create one team. So that helped us to make sure that there was enough trust, that we understood each other. Actually if you think about that, talking for six straight hours, that was more than I was talking at that time with my partner. Six hours of talking – not a lot of people do that in a one-on-one situations. Sometimes it was with multiple people in the same chat room. And it was from 6 to 8 hours. Of course, this was not the full project, not all the time, but there were a few weeks when that happened like this, because we needed to create a connection and we needed to create trust.

Judy: And when what you are talking about is important enough, people are willing… For younger people who are completely used to being able to use Skype all the time for video calls with people, the idea that we use just a text chat and yet build really close relationships with people seems absurd. I know because I was doing the similar thing at a similar time. Of course, you could build those relationships.

Yves: And the fun part was, I think, that Skype at that time offered already video, but it didn’t work out that well. Especially when we connected with three or four people, the network wasn’t good enough. Funny part was it was possible to chat with more than three or four people on the video chat, it’s just that the connection wasn’t good.

These days you have to pay to Skype if we want to talk with more than three people on the video screen, but at that time, it was still free. But we skilled down. We didn’t even always talk by voice. That is also partially because of the language. Some of the people from Russia didn’t feel at ease talking so much in English and they preferred chatting.

It was some confusion with us, because there was at least one  person in Russia, with whom in the first six months we never even talked, because he felt that he couldn’t talk, but he chatted pretty okay in English. At some point we even joked that he might not even exist, that he was just an extra resource, an extra person that they invented in Russia. But in the end, he came to Belgium, so I know he exists.

True, his English was not as good as the English of the other people from Russia, but his English was more than enough. He just didn’t feel as comfortable doing that.

Again, chat helped in multiple ways. It helped to get confidence to say something. It goes a little bit slower. And at the same time you do have a trace from it, which can also be interesting, especially if you have a discussion for about half an hour, at some point we agree on something. Then – okay, what did we agree on? We sometimes need to look back at our log to realise what we had discussed. That helped as well.

Judy: Just to backtrack a little bit you were saying that when you have a distributed team, Agile really helps.

Yves: Yes.

Judy: What is it about Agile that helps in that situation?

Yves: Feedback. For me, it’s mostly feedback. Feedback is a crucial part of a lot of the things in Agile. Yes, we would like to respond to change, we like to have feedback in multiple ways and that’s really what is making it work, because we work in very small chunks and we send it to each other. We see if it’s working or if it’s not working. We want changing requirements because we realise there is no customer that actually knows what he wants. Even myself, I might not know what I want and if they send me something, I know that that’s not it. Now I know better what I really want.

Judy: So it’s a small iteration, small experiments. Each piece of feedback is presumably less frightening.

Yves: Yes. That’s how it works. It’s also easier in smaller projects and in smaller teams. I’m now helping a pretty large corporation. They came from a complete waterfall mindset, they don’t like feedback and everything that has been put in place in the last, let’s say, 10 years is all to reduce bad things, and they want to be the first time right, and stuff like that. Now we start with Agile, and we start with getting much quicker feedback and they really need to adjust to that, because they are not used to it.

It reminds me of the first guitar players in the 50’s and the 60’s, that started to use feedback on their electric guitars. The first time that there was a recording done by Beatles and the Rolling Stones when they recorded guitars with feedback, the record company sent them back. They said, “It’s wrong. Here is feedback on it.” But that was because they didn’t understand what they really wanted.

So even their people in the industry didn’t know. Well, they did know feedback, but they thought it was something bad. And now we have this innovative guitarists that try to use it to make nice sounds with it. And they didn’t understand it. It’s a little bit the same for me in corporations – we need to learn to work with feedback.

First of all, we need to give feedback in a nicer way, but we also need to learn that when we do something, we are not right from the first time. We need to learn that yes, we are not right from the first time and we will adjust. A lot of companies are not ready for that. They still think, “Oh, we are not right from the first time! Who did wrong? What is wrong?” No, we know this by design that we will be wrong the first time. That’s why we don’t want to spend ages trying to figure out what is exactly right, because we know we won’t be able to do that.

If 80% of the things are already right without too much thinking – I’m not going to say no thinking – without too much thinking, we’ve gained a lot of time. Okay, we lost some time on the 20%, but we got very quick feedback.

I have an exercise that we’ve done for an Agile training. Well, I’m probably not the only one, because I’ve learned it somewhere else. We ask people to just stand in one line, and the very first part is you stand from length. The tallest at the one side and the smallest – at the other side. That’s pretty easy. You see that, you look at the people around you, and you know that you are doing it right.

Then we ask the same for the number of years that you work at this company. You know some of the people, so you might know more or less how long they work there, and you can figure this out. Actually when you then go to the line and ask people how long do they work – a couple of weeks, a couple of moths…

I’ve done this last week with 40 people, and I think we had 5 people that were wrongly situated.  There was one person, 6 years, that was at the wrong end, and another at the other end. So there were a few people that are wrong. They did that, I think, in about 2 to 3 minutes, probably less. They created the line. And then in less than half a minute we checked and we’ve found people who were wrong, and we’ve fixed the line. And that’s it. That’s less than five minutes.

If I would ask people to write papers and to make sure that they have the exact perfect line, and they only get one chance it will probably take them twenty minutes before they figure it out even if they could talk. And we did this exercise without talking.

Yes, it’s feedback: learn, do something, make a mistake, but have enough time that we win that makes up for the mistakes, and then we can correct it along the way.

Judy:  With that illustration, I think, it gives a good feel for why when teams are distributed, working in an Agile way with iterations, with feedback is actually going to work so much better than a waterfall process. If you’ve got everybody together doing routine stuff, all in one place, you can just about see waterfall working occasionally. If you’ve got everybody distributed, there’s just no chance.

Yves: No, all you have to do to make sure that you totally don’t make any mistake and to know everything upfront. There’s very little chance that that happens. We have been building houses for probably at least 2,000 years or longer, and nobody can build a house within time and within budget. Well, not completely true. The ones who can create houses within time and budget are the ones created ten same houses in a part of a city. Then they can do this. With the first one they need to figure it out a little bit, with the second one it goes already better, and by the time they have finished the tenth house they know  pretty well how long it will take and how much it will cost.

But we don’t do that in IT. A lot of people who think that we just create a new version of this project. But that’s not true. The situation, the world has changed so much, because that’s the reason why we are doing new projects, that we still end up changing a lot of stuff.

Judy: And of course, IT is changing so much of the rest of the world, which is presumably, why so many other people need to adopt these kinds of approaches to work.

Yves: The whole world is changing. It always goes faster. And on top of that, we are also using our own tools to change our own environment, which is also speeding stuff up.

Judy: On the subject of speeding stuff up. I’ve just realised the time. And we are over our self-imposed limit of half an hour. So we better draw this to a close, much as I am reluctant to do so, because this is really a very interesting conversation. However, I said half an hour and let’s stick with that. If people want to contact you and find out about kinds of things that you are up to, who do you want to hear from? And how should they contact you?

Yves: I’m interested in hearing a lot of things. But I’ll start with contacting before I forget it. The best way to contact me is on Twitter. It is @YvesHanoulle, in one word. I assume, you could probably add a link somewhere in the podcast.

One of the projects that I’ve started a few months ago is I’m actually writing a book about hiring people. It’s not about the whole process of finding people, but it’s really about selecting the people. There are actually a lot of Agile coaches who are involved as I am in selecting people for teams. At some point one of my ex-clients called me back and said, “You had a list with some questions and some ideas and how to ask. Could you share this with me?” Once I heard this it was like, “If I shared this with one person, why don’t I share it with the rest of the world?”

So, I created a Google Doc, added the things in there. I shared it with that person. I also asked, “Could you add the things that you would do?” And before we knew it we had again more than 30 people helping out. It’s on Google Docs (Google Drive), because it’s the easiest way right now to share it. It will probably move to Leanpop [? not sure] in the coming months. But right now, we still have some chapters that need to be edited.

I’m actually actively looking for people who have some interest in finding people and selecting people, but also have some techniques that are more unusual. I know that asking questions is not the best way to do it. Sometimes it’s much better to ask people to do some kind of work and to find out by them doing some kind of work how good they are. There are some other exercises that are in the book. I’m pretty sure, there might be most professional people at some point who are helping out in selecting people. So I’m interested to see who has interesting and crazy ideas to add to the book.

Judy: That sounds exciting! I’m looking forward to reading it already.

Yves: I will share it with you right after our talk.

Judy: Right, thank you. Thank you so much for being on the podcast. I know people will have learned loads and loads from listening to this conversation. Best of luck with the book! And best of luck with all kinds of collaboration, because I know there are many.

Yves: Thank you. It was wonderful to do this. Thank you very much.

Leave A Response

* Denotes Required Field