At the XP Days Benelux 2012 conference, Yves Hanoulle did a session about the agile and lean mindset. InfoQ spoke with him on the mindset, his experiences with pair working, and how he collaborates in the agile community.
InfoQ: At xpdays 2012, you talked about the difference between "doing agile" and "being agile". Can you elaborate on that?
Yves: One of the things that got me started is Dude’s law from David Hussman. It says that the value of a project is defined by why over how: value = why / how. So when you focus only on “how” and the “why” is zero, it doesn’t really help: If the why is zero, you can have a 1000 for how, but the end result will still end up with zero. So it is really important to focus on why before focusing on how, or at least at the same time. Where, like as in the agile manifesto, it doesn’t mean that we shouldn’t do anything on how. Tools and practices are important, but the why is more important.
If I look back at all the books that we have in the agile community, unfortunately they all focus on how to do it. We have management techniques as in scrum, management methodologies or frameworks, we have methodologies that talk about how to do pair programming, etc. Some of these books talk about why, but we have a lot of how there. Maybe I haven’t seen it yet, but so far I haven’t found a book that is mainly talking about why. I’m not the only one talking about it, there was a keynote at the Agile 2012 conference in Texas that was also talking about the why, so somehow we’re multiple people in sync, and are having similar ideas which is always a sign for me that it’s probably good. Something is the air in the world about the “why”, it seems important right now.
InfoQ: So your agile and lean mindset is about the why?
Yves: For me much more about the why then about the how, it’s not the only thing but it’s definitely a core part in it. For example, I once worked with a team that was officially agile and was doing a lot of agile practices. But I felt that they didn’t understand anything about agile, that they weren’t really agile. In the same company we had another team of which the agile people said “they’re not really doing agile, they’re waterfall”. And it’s true, they didn’t do stand-ups, they didn’t do a lot of other stuff, but in the mindset they were much more agile, and the company was much happier about them. People started talking in that company that agile is really bad for business and that waterfall projects were doing so much better, so agile is no good. Where for me, these so called “non-agile people” actually do understand agile much more, and the reason why you are happy with them is because of agile. But that was something that could not be said in that company, it’s a company where I dropped using the words agile, scrum, and XP. I didn’t use them anymore because it was counterproductive.
InfoQ: Can you give some examples about ideas to create an agile and lean mindset, that people can use in their daily work?
Yves: Agile games are a good way to create an agile mindset. One reason is that a lot of ideas about fast feedback and small steps are really about changing your mind, your mindset. To learn that, it’s important to have a safe environment to experiment. If you are in an environment where failure is not an option, and people are really pushing hard on that, even the idea of making a small mistake in such a companies is mind-blowing for these people. If you have workshop where you can find a way to do something, and see that actually the one part where you did a lot of mistakes ended up with a better result then the one part where you were punished for any mistakes; that’s when people start to learn! They learn when they do something, and practice to get better at it. Of course I’m biased in the sense that I learned much through agile games in the agile Benelux community. There might be better ways, but it’s the way that I have learned. That has worked really well for me, and I’m biased to think that it’s the best way.
InfoQ: Pair programming is known to many people. You talked about pair working. So what’s pair working, can you give some examples?
Yves: The idea of pair coaching, the name that I am using mostly when I talk about pair working (I’m thinking it might be better to call it pair working), came from my father. I had the luck that I was able to do a lot of workshops together with my father. We had a workshop were we wanted to have some people do more command and control, for an exercise on leadership. If you do that at an agile conference, where people really believe in self-organization and in coaching, it’s hard to have some of the people to lead command and control because it’s really counter intuitive to them. For the exercise we wanted to show the real difference, because most people have never experienced command and control fully, or fully coaching, it’s always some hybrid. And we realized that one way to help these people is to put an extra person next to them, so that they could support each other.
We started to think some more about that, and realized in the corporate world the official way to work is one person leading somewhere between 5 to 5000 people, Which is the so called default way, what we often call the only way, and it’s accepted that in our environment that’s the best way. But this is not the only way, there is another part of our world, another part of our life, where the default is two people, and that’s in parenting. In parenting you have a mother and a father, with a mother role and a father role. So our idea was: why don’t we try this model that works in our personal life also in corporate life? And for some people it might work better, for other people it might not work. And the more I’ve been talking about working with two people, I think it’s 7 years ago that I first started using the words pair coaching, the more I saw that, in a lot of places in corporate life that’s actually what we do. Policemen by default are always on patrol with two, at least in Belgium. Pilots are always with two. There’s a very nice story about an airplane, where a pilot died during a flight and none of the people in the plane noticed it because luckily there was a 2nd pilot who took over. And in radio and television shows these days, the rush hours are always with two people, or at least one with a sidekick. In scrum you have a product owner and scrum master, which is for me similar to a mother role and a father role. A product owner will be the one who will say what needs to be done, and a scrum master is protecting the team from product owner and might at the same time be pushing them a little bit internally. So you have some differences in these roles, where before typically a product manager or a program manager would take on both roles. I’m not sure if it was designed as a pair coaching role by the founders of scrum but it is definitely a due result.
Now a problem these days when I say to companies “hey, I want to do pair coaching” they tell me “that’s too expensive”. “Now you’re saying we do not need one coach, now we need two”. As a clever way around that, I say that I want to coach with an internal person. I tell them: “I will coach that person, and I will teach that person a lot about scrum and agile and XP, and that person will teach me about your corporate culture and how things are done in your company”. In that sense we fill two different kinds of roles. Extra advantage is that it also helps me leaving the company faster; it is not my intention to stay very long with companies. For me it’s important that I make sure that my knowledge stays in the company and pairing with somebody internally in the company makes sure that he grasps not just what I’m doing but also my intentions behind it. So that’s one way that it can resolve the problem of selling to be with two.
InfoQ: I see you do so many things in the community, many different things. Where do you find the time to do all of that?
Yves: The reason I why can do that is because of the community. Over the years I became really good at asking for help. How I start most of these on-line collaborations is: I see a problem that I have for myself, I try to find ways how I can solve it, more or less for myself, and then ask for help. A nice example is the agile conferences calendar, which keeps track of all the agile conferences around the world. After I launched that calendar, I quickly realized that this is something not just for me. I know a lot of people who are interested to know about other conferences. One is of course speakers who want give talks around the world. Another thing is conference organizers. To give an example, right now we’re at the XP Days Benelux conference, while at the same time XP Days Germany is taking place. Which is a shame, because over the years, sometimes we had people going to both. This year it’s impossible, people have to choose to one or the other, or you can have some crazy people like Olaf Lewitz did last year, one day coming to XP days Benelux and the next day going to Germany or vice versa, I don’t remember the order. Ok, so we need more crazy people like him, but that’s not the way how I want to stimulate that.
I initially shared the conference calendar with 10 to 20 people. I told them where they could find it, and gave them full access. And said: “if you know anything, any conference you want to add, go ahead, you can do anything with it”. We now have more then 70 people that are updating it. So if every person adds 1 event every year, then every week updates are happening. I receive an email when people make an update or delete something. So when someone accidentally deletes something, I sent an email: “did you think it was locally and removed it from your local calendar, and by mistake removed it from the conference calendar, or is it just the conference is cancelled?” When people deleted it by mistake, I don’t put it back, but ask them: “please, put it back”. I verify and I help people to fix it. There’s only one person that actually deleted 2 things, everybody else is just learning. So, I can do a lot of on-line collaboration because I asked the community to help me with it. The main reason for me is to make sure that also there I’m disposable as fast as possible. The agile conference calendar is definitely not mine anymore, it has become a community thing.
Earlier, InfoQ wrote about the release of "who is agile" , a book by Yves Hanoulle about Agile community leaders and influencers. Another article on InfoQ describes the Agile reflection of the day, which is a daily question on twitter that people can use to reflect and share their experiences.
About the Interviewee
Yves Hanoulle is Creative Collaboration agent in Europe. He has done all possible jobs you can do on a IT related project. Yet for him, IT is mainly about working with people. The last years Yves started a lot of online collaborations with agilists over the whole world.
Who is agile, agile retroflection of the day; CoachRetreat, ... If you have some spare time and want to learn about agile from your home, you can contact him, as all these projects can use some more volunteers.
Yves was called one of the 25 agilists to follow twitter. See if you agree at @YvesHanoulle.
