Kane Mar is the co-founder and principle consultant for Scrumology. He has been involved in the Agile community since 2001, initially as a developer and later as a professional Scrum Coach and Trainer. Kane Mar studied and worked with Ken Schweber (co-creator of Scrum) and was one of the first accredited Certified Scrum Master and Certified Scrum Trainer worldwide. Kane Mar is highly regarded as one of the most experienced and leading exponents of Scrum.
This interview touches on agile in general, distributed teams, and retrospectives. Kane presents a bit of a "devil's advocate" point-of-view on distributed agile. Read on to find out more!
YOUR AGILE JOURNEY
David Horowitz (CEO, Retrium): Let's start with an overview. How did you get started with Agile? What's your story?
Kane Mar (Agile Coach, Scrumology): Quite a long story actually, I used to be a traditional waterfall project manager...
David: I'm sorry about that!
Kane: Thank you for the condolences! I started out as a very, very traditional project manager. But I found that with waterfall, it's absolutely possible to deliver on-time and on-budget, but the difficult thing is that you need to make a lot of compromises and personally I found that a lot of the compromises that I made were very, very personal.
So I think I was effective, I like to think I was effective but I also feel that I wasn't necessarily the nicest person to work with. I'm originally a Kiwi from New Zealand. When I left New Zealand, I went to San Francisco and the first project that I worked on in San Francisco was a sizable project, it was roughly about $35 million. So it wasn't huge but it wasn't trivial either and it was a death march project. It was a really oversold project and it started out really bad and it kept getting worse. It didn't get any better, it got worse and worse and worse throughout the duration of a year and at the end of the year the whole thing collapsed. The project simply imploded! It was a failure for the company and it wasn't trivial, $35 million dollars just gone up in smoke. And so the client that we were working for -- I mean of course it was a failure for them. And the company I was working for, it was a failure for them.
I took it very personally. Why make these personal compromises? Wouldn't it be better to be a nice failure rather than an asshole of a failure? And so I took a long hard look because quite frankly I didn't think that the software industry was sustainable for myself. And so I was actually looking to get out of the software industry. This wasn't my only failure, it was the biggest, but there were a few others before that and I'd gotten really really tired of that and so I decided that either I had to change how I was behaving as an individual or I had to find another industry to work in.
And so I started looking around and by coincidence I ended up working with ThoughtWorks. I'm not sure if you're familiar with ThoughtWorks -- most people in the Agile industry are. They're probably the largest Agile consultancy. I worked with ThoughtWorks for roughly about five, six years. I got a chance to work with Ken Schwaber, the co-creator of SCRUM.
David: That must have been an amazing experience, working with him.
Kane: It was yeah and quite incredible, I mean he was very good with me and he didn't call me an idiot or anything like that, he was very patient. [Laughter] Looking back at it, some of the things I did were just crazy.
David: Welcome to the club!
Kane: [Laughter] But it really opened my eyes to different possibilities and then I went on a journey. It was really, really hard because basically what I was doing, I was unlearning a lot of the bad practices that had been established in my behavior. And so it was a rough two years. It was a lot of professional growth and a lot of personal growth. But after a year I began to see that this is a better way to deliver products, a much more sustainable way to deliver products.
And in large part because of those experiences I've been in the Agile community ever since.
David: So now you run a site called scrumology.com?
Kane: Yeah, I left ThoughtWorks a while ago, I've worked with a whole variety of different companies, always in the Agile or the SCRUM space and all the companies that I've worked for have become smaller and smaller and smaller until now when my wife and I came over to Australia in 2009. Together we founded Scrumology and so Scrumology is really just us.
David: That's great, and it's a coaching business?
Kane: Yes coaching, and I do SCRUM training of course, but I also coach organizations. So I go into organizations and talk about where they are at and the problems that they're having and those sort of things.
DISTRIBUTED TEAMS
David: And most of the teams that you coach and most of the organizations that you work with, are they co-located or do they also function in a distributed fashion?
Kane: [Laughter] They're all over the planet! They're distributed everywhere. That's the reality with every organization that's larger than a mid-sized organization -- and when I say mid-size, 500 people. But anything larger than roughly about 500 employees is almost by default distributed in some way, either across the country or across the planet.
David: I'm going to grill you here, you probably won't be happy! I pulled out out one of your tweets from a few months ago:
I feel that remote working has introduced more problems to teamwork than it has solutions. https://t.co/qhD9HiiLSH #pmot #agile #scrum
— Kane Mar (@scrumology) August 21, 2015
Can you explain that a little bit and since you work with distributed teams, what do you tell them?
Kane: I tell them the same thing I'm going to tell you right now, quite honestly. There are reasons for doing remote working and a lot of those are good sound reasons. So for example, you may have someone on the other side of the planet who is a specialist in a particular domain and you need their help. That's a very sound reason for remote working.
Also many companies do remote working because they've purchased a company in a different location. They may buy a company in Europe for example and then the next thing you know, you're working in a distributed fashion with Europe. Those are all good reasons for a distributed software development in some way.
There are problems with that and all the problems are about communication. Now the hard thing with software is that software is in a large part almost entirely about communication. Communicating between the customer and a team, within the team, communicating between the team and support, these are all areas of communication and they're all difficult to work with. As soon as you start putting pressure on those lines of communication, that's where you start to see problems. And that's exactly what a distributed team does! It deliberately puts barriers between individuals so that communication becomes difficult.
Organizations will often think -- quite naively I would add -- that having a distributed team is no different from having a team that's co-located and I think that is absolutely incorrect.
It's a foolish, naive notion of how to build good products. And so my personal point of view is that all of the reasons for having a distributed team don't really make a lot of sense if your intent is to have a high performing team that's producing a great product.
David: One of the arguments that I've heard for structuring your team in a distributed fashion is that you can hire the best talent regardless of location. Do you agree with that statement?
Kane: Yeah, I think that might be very, very true but let's also be realistic about what many organizations are trying to say. What many organizations are trying to say is that they can reduce their cost. When they start talking about hiring talent oversees what they typically mean is that the wages overseas are cheaper.
What many organizations will do is they'll try to offshore for work and turn their work to either India or China or the Philippines. The interesting thing about distributed software development -- and it's sort of like an unspoken truth because many people know this to be true but very few people talk about it -- is that if you want to have a great high quality product produced in a distributed way, the only way to do that successfully is to spend a lot of time with your teams making sure that they communicate. That includes things like flying people backwards and forwards between the different sites, supporting video conferencing, supporting the team forming in a single location right at the very start. Now all of these are great practices and they do make having a distributed team much more effective and much more doable but it is so costly to do that, that I think that it almost outweighs the cost of offshoring the work in the first place.
One of the few things that you will never see in any conference especially within the Agile community is the fact that having distributed teams doesn't necessarily mean that you're going to have a cheaper product. I don't see that the cost savings are there because the effort that you need to do or to go to, to make it successful is very expensive. So you'll end up paying that cost anyway in some fashion or in a different fashion.
David: And yet the reality of the world is that more and more companies and therefore more and more teams are becoming distributed, for better or worse.
Kane: You are absolutely right. I totally agree with you. They are becoming more and more distributed, I think often for the wrong reasons. Cost is not a good reason and that's really the point that I'm trying to make. If you're trying to reduce your cost by having a distributed Agile team, chances are it's not going to save you anything.
RETROSPECTIVES
David: So let's imagine a company that understands and agrees with what you just said, and yet decides to become distributed nonetheless. Out of all the different ceremonies that a SCRUM team typically runs through in a sprint, which ones do you see as the most important for distributed teams and which ones do you see as the ones that are perhaps the most difficult for a distributed team?
Kane: Well, I think that the most important ceremonies are the same whether you're distributed or not. I'm not sure that I could choose quite honestly between say, for example, the sprint planning meeting which is really important, or the review meeting -- it's also really important! The daily scrum I wouldn't drop. I guess I'd say they're all important!
But for me retrospectives are massive because that's your learning opportunity, that's your opportunity to improve going forward and I mean if you take that out, then you basically take out any ability to have continuous improvement and I think that's fatal for a team, regardless of whether it's a distributed team or whether it's a co-located team. I think the retrospective is really really important.
It's a little bit sad because I see many organizations drop out the retrospective and I think that's the worst thing you can possibly do.
David: Obviously we agree with you that retrospective is really critical so I'm glad you said that! [Laughter] If you don't mind, I'll take another quote that you have. Do you see if you leave a digital trail? Everyone does. It's a little scary, right?
Kane: I'm okay with that because I'm okay being wrong, I've been wrong in the past and I'll be wrong again in the future, that's alright.
David: It's what makes you Agile! [Laughter] So you said on Quora a few years ago that retrospectives are most effective when done face-to-face simply because so much information is communicated non-verbally. So obviously this is almost the exact problem we're trying to solve at Retrium. What have you done to make distributed retrospectives more effective?
Kane: So of course the very first thing that I would do is try and engineer a situation where I don't have to do distributed retrospectives because that's just the way that I tend to work. If that is totally unavoidable, the one thing that I'd encourage teams not to do are conference calls. Conference calls are lethal.
David: I've never been on a good one in my entire life, they just don't work!
Kane: No, no and I'm talking from my own personal experience because every time I find myself on a conference call at some point I'll be playing a game on my iPhone or reading the news or something like that and that's not a great use of anyone's time.
Video conferencing is great, Skype or appear.in that you guys are using is a great solution as well. Being able to see people's faces, I think is quite important so that you can see their emotions just to have a little bit more empathy for the individual. If you're going to do it, I don't like having a team all located in a room and then only the outside parties video conferencing in. I don't like that because to me it feels like there's a separation, a barrier.
So when I like to do say that everyone has the same rules. If one person is going to video conference in then everyone's going to video conference in, even if they're in the same location, I'd still encourage them to all video conference in so that everyone's at least on the same footing.
David: And then once everyone is on the video conference, how do you structure the conversation?
Kane: I don't think that it really matters or that it's very much different in a face-to-face conversation. You'd still do the same thing, it's sort of the same exercises, you could still have the same conversations. You could have a little bit more difficulty managing people talking on top of other people and so having a discussion upfront about etiquette is always a good idea, just to make sure that everyone's on the same page. Once you've done it once or twice, once everyone is familiar with the ground rules, everything tends to flow quite seamlessly.
Some teams that I've worked with in the past have used the talking stick. It's a Native American tradition and it comes from the tradition that only the person who is holding the talking stick is allowed to speak. They have the floor and of course it's just simply a way to allow them the opportunity to voice their opinion. Many SCRUM teams will take that into their meetings and their practices, many SCRUM teams will adopt a mascot.
A very common mascot here in Australia is to use a rugby ball, because it sort of makes sense. When I was in the U.S. we used to just throw a stuffed toy at each other and that works pretty well as well or all those approaches work really well.
David: Of course that works only for a co-located team. At least I can't throw a rugby ball halfway across the world!
Kane: That's right but you can pretend to virtually throw it at someone and they can pretend to virtually pick it up and so that's how virtual teams work. It can be made to work, it's not quite as comfortable, but it can be made to work.
David: What's the role of the facilitator in all of this? Do you need a facilitator?
Kane: Not for a good team. Of course new teams will need one. If you're not careful, retrospectives can turn very, very negative. Especially with teams that are used to traditional project postmortems, like if you work on a waterfall project and at the very end of the project, you have a postmortem. Then focusing on the negative -- it's too late, it's too late to do anything useful in order to change the outcome of the project.
Of course if you're doing a retrospective at the end of every single sprint, so say for example you're doing two week sprints, you're going to do a retrospective every two weeks and the beautiful thing about the retrospective is that it allows you that opportunity to change the outcome. It may have sucked last sprint but you know what? Next sprint we can do something else and have a positive influence. And so there's no reason why the retrospective needs to be negative, it should be a very positive learning experience, and it often is, but you do have to coach your teams to understand that.
I'm not saying that they shouldn't bring up problems. Of course they should bring up problems, of course they should discuss them. But there's no reason why you can't discuss problems without attacking people personally, or being offended, or any of those things. You can still have a mature discussion around what the problems are and address them and in the next sprint things get better.
David: Well I think we've run out of time, but this has been great. Fantastic insights. We really appreciate it!
To get in touch with Kane, visit his website www.scrumology.com or follow him on Twitter @scrumology.
Distributed team? Want to run effective retrospectives?
