Interview with Agile Coach Mark Kilby

Published September 22, 2015 by David Horowitz

mark-kilbyMark Kilby is an agile mentor and coach who has played many roles on the software and product lifecycle stage. His passions include serving servant leaders and building sustainable organizations that truly bring value to the people served inside and outside the organization.

This interview touches on agile in general, distributed teams, retrospectives, and coaching. It includes some funny anecdotes as well as some great advice for newcomers to the agile world!

 

YOUR STORY

Retrium: How did you get started in the agile world? What sparked your interest?

Mark: I had been in software for a little over 10 years and I was working for a manager where everything was “priority one” and those priorities changed every 5 minutes. That was a very interesting work place, to say the least. I came across this article in one of my tech magazines about this weird thing called Extreme Programming and I read the article and I went, “Wow, this is crazy enough it might work!” So I got the book and I went, “Wow, this really might work!” So I started trying it out and hey, it worked! That’s how I got started and so from about 1999 until about 2003 I experimented on my co-workers. They all became guinea pigs, whether they wanted to or not because I really wanted this to work. One of those groups went off and formed their own startup and they said, “Hey, you know that weird agile stuff you were talking about? Do you think you could come here and help us with that?” And that’s how I got hired in as a Scrum Master back in 2003.

Retrium: And then from Scrum Master you became a coach?

Mark: Yeah, so at the time I was actually hired in as a software architect and I just kept doing more and more of this coaching stuff and kind of slid out of the architect role and into the coaching role because I was finding that the tougher problems were not the technical problems. It was the people problems, the communication problems and misunderstandings, and people not seeing each other’s point of view. So I started shifting what was in my toolbox and using some different kinds of tools that I never learned in engineering school.

whiteboard

HOW AGILE HAS CHANGED

Retrium: I know what you’re talking about! So has agile changed a lot since then from your perspective? Or is it pretty much the same thing, just new contexts, new teams?

Mark: Wow, yeah it’s morphed a lot. In the early days, it was certainly more developer-centric and then as managers started discovering it and some valued it and some were threatened by it, there were the early agile wars around who had the best agile methodology for teams. And then everyone wanted to figure out, we see it working for our teams, now we want to see how to do this in the large. So the scaling wars started. So now we have multiple scaling frameworks that are duking it out. My philosophy has always been: use the set of tools that work best for the team or the organization. So, for teams, I’ve used scrum, I’ve used kanban, I’ve used hybrids of that, I’ve used some of the tips and techniques from the Poppendiecks, if you know lean software development, you’ve come across that book. And then on the scaling side, I’ve used Scaled Agile Framework, I’ve used bits and pieces of the others. I think Disciplined Agile Delivery has some interesting concepts as well. But I’ve learned it’s not worth being a zealot about any one of these. It’s really understanding what’s going to help the group of people you’re working with at the time, whether it’s an agile team of 7 plus or minus 2, or organizations of thousands.

Retrium: It seems like over the past 10 years or so, based on what you’ve said, there’s more formal structures that you can pick and choose from, whether it’s based on scrum vs. XP vs. lean, or at the scaled level, there’s different ones there. There’s lots of options, whereas there wasn’t in the past.

Mark: Yeah, and we’re starting to see other disciplines really start to get involved with agile. So for many years, user experience really wasn’t talked about that much. And now with Lean UX and some of the conversations there, we’re starting to see, how do we map out the details on what this discipline looks like that we’re building. So there’s that, there’s the testing community, there’s all these disciplines blending in there.

Retrium: There’s been a lot of change in the past 10 years. Where do you see things going in the next 5, 10 years? What changes are coming to agile?

Mark: That’s a tough one! So, as we saw with the team based frameworks, scrum has become the dominant one but certainly no one is going to say it covers all bases. I think we’re probably going to see something similar in the scaled frameworks, where one of those scaled frameworks will probably become the most popular, mostly because it gets the most press, and I’ll leave it at that. Not going to go into detail! [Laughter] But, I think what’s missing is the bigger picture, the bigger ecosystem. It’s not just what happens within the company, it’s what happens outside the company as well. So these days we have some great advice, great training materials on how to interact with your customer. What about the ecosystem of your customers? This is where Lean Startup has filled the gap, and that’s why it’s gotten so popular.

Retrium: And it fits so well with agile.

Mark: Yeah. But I think the next phase, and we’re starting to see little bits of this from Lyssa Adkins and Michael Spayd, they’re doing some work there, and there are some others that are doing some work around the systems level thinking of the whole organization. Some of the stuff that Dave Snowden has done with Cynefin has definitely influenced that as well. But it’s how an organization can co-exist well with its customers, with its partners, and even with its competitors. I don’t think anyone has really figured out the agile version of that yet.

thinkers

DISTRIBUTED TEAMS

Retrium: One of the other trends that we’ve noticed of course, coming from a tool perspective targeting distributed teams, is that there is this trend towards being distributed -- whether that is simply because of outsourcing or it’s because you’re choosing from a strategic perspective to make your team distributed since you can hire better talent wherever you’re located -- more and more teams are becoming distributed. So, one of the things we’re very interested in finding out is how can we make distributed agile better? So do you work with distributed agile teams?

Mark: I’ve worked with distributed teams for many years. With my early coaching, we were sometimes as little as 1 to 2 time zones away, and sometimes as many as 13 time zones away. Nobody on the moon yet! These days though, the company I’m at right now, Sonatype, we are really a completely virtual company. Everybody works out of our homes. And with that, we use scrum, which most people would say requires face-to-face. Well, we’re face-to-face right now -- on video. But it’s not so much face-to-face, it’s do you have honest, open dialog that’s important. Do you trust the person you’re interacting with? Do you feel like you can openly express your opinions and not get shot down? That, I think, is that shift you and I are seeing, because that’s why we’re talking, in this move towards a distributed agile ecosystem.

Retrium: You’ve identified trust and empathy and having real relationships with people as core to a good team. Is it harder in a distributed context? Or the same as with collocated teams? How does that forming of trust change if you become distributed?

Mark: Oh, well certainly harder. Because usually it's through some sort of shared experience and usually it’s more an experience that you’ve been in together. Learning how people react, learning their strengths and weaknesses and how they complement yours. That’s the key thing. But we’re seeing now in our distributed environments, we’ve got good connectivity. We can pick up a video channel anytime and talk about things maybe that are bothering us. Maybe it’s a one-on-one kind of retrospective. And say, “Hey, remember what happened here? You said this? I wasn’t so great with that.” And plus we have other tools like Crucial Conversations and other tool kits that maybe we can bring into the distributed space and help us build stronger relationships. So, I think we’re at the point with the technology that we can do almost as well as face-to-face. I’m still not going to say we can replace face-to-face. But you and I have never met in person. I’m looking forward to the opportunity to doing that in November (at the Distributed Agile Teams Conference) but you and I have talked and we’ve got a connection, and we’ve never met. And that’s happened more and more over the last I would say five years with the boost in technology and capabilites.

Retrium: So, it’s a better tool set that’s allowing people to build better relationships today.

Mark: Yeah, yeah.

Retrium: And so, what tools have you used that you like the most? What tools do you recommend to people trying to get started with distributed agile?

Mark: So it’s interesting. That’s usually the first question that people ask, and for me, the tools aren’t always that important. It’s really, how are you connecting with people using the tools you have? So for the teams I’m coaching right now, very rarely do we use video actually, because we’ve already got connections in place, we’ve got relationships in place. And with that, we’ll use a task board of some sort. Right now we use Jira -- Atlassian’s Jira. We use Hipchat for all kinds of things. Hipchat is the day to day communication. It’s also the backchannel during some of our live meetings. So if somebody can’t break in on the audio or if we don’t have video going, we can’t wave at each other and we can use that backchannel. I’ve even blogged a couple of times on different ways people can use that. Certainly you’ve got email. There’s pluses and minuses there. But any tool we have, we try to make sure you can get people connected in that tool. Google Docs is a great example of that. You can connect people in that tool. So one of the things we do with tools like that is we’ll run virtual Lean Coffee. So people listening or otherwise not familiar with Lean Coffee, you bring a bunch of folks together, they pitch topics, the group votes on what they think is most important, and the group can collaboratively decide, “What do we feel as a group is most important to us to share right now?” So you can do that in a Google Doc. You can do that in an environment like this, which is a simple task board behind you. But the thing is you've got to focus on is the connections you’re making with folks and not worry so much about the tool. So I’ve used all kinds of tools and probably abused them in some cases in different ways to make sure that people are connected when they’re online.

Retrium: At least you’re abusing the tools and not the people on the team, right? Better to do it that way.

Mark: [Laughter] Absolutely. Until the machines rise up against us, you know I’m okay with it. [Laughter]

_MG_8355

RETROSPECTIVES

Retrium: Exactly. So, when you’re talking about a distributed team and you’re talking about retrospectives in particular, are they easy to run or hard to run? What are some of the challenges you’ve faced while trying to run retrospectives with your distributed teams? What are some of the things you’re looking for to make it easier?

Mark: Yeah, so the big thing about any retrospective is you want to make sure everyone’s got an equal voice in the retrospective, that they can raise whatever it is they need to raise, that they can do it in a safe manner, without any kind of retribution or any kind of team member shooting them down. And that’s really tough in a distributed environment, if you don’t have the right ecosystem in place. So one of my teams, Lean Coffee is one of their favorite formats -- I’ve actually tried to introduce other ones and they reject it -- right now they like Lean Coffee because when I showed them that technique, they said, “Oh, wow! It’s not somebody setting the agenda. We can set it.” And that was very powerful for them. And even those that are a little more reserved, a little more introverted, they still feel like they can put in their two cents. Maybe through chat, maybe through the Google Doc that we’re capturing notes in. But everyone still feels like they have a voice. And so that’s one of the most important things for me, is making sure that everyone has as much of an equal voice as possible. Another thing that using the backchannel is, not using video all the time, we can’t see how people are feeling. But if you can encourage them to use chat to maybe say, “Ah, I didn’t really feel so great about that” even if it’s a private one-on-one chat, you can still get the same sense of where are people in the conversation of the retrospective.

Retrium:  So running a retrospective is one thing, but then following up on the retrospective is an entirely different exercise. So can you talk to me about that? What are some of the challenges and breakthroughs you’ve had with following up on retros?

Mark: Yeah so the big thing, and I believe you’ve played the Scrum Master role before, is, “Oh, we’ll just have the Scrum Master take all the actions.” Don’t go there. Don’t go there! Because you have enough to do, and yes, the developers’ time is important, but what’s more important is for them to own the actions coming out of that. So one of the best things to do is when things are proposed, ask “Ok, who can take this one on? Who can own this?” Sometimes it might fall to the Scrum Master because maybe it’s gonna take a significant amount of time, but I try to get the team members to own at least part of whatever that action or idea is.

Retrium: Yeah, I think a lot of people think of the Scrum Master as the impediment remover, which is certainly part of the role. But if he or she is the only one doing impediment removing, then the team doesn’t feel like it owns the problems, nor the solutions.

Mark: Yeah, here’s another tool I use as a Scrum Master. It’s called disappearing. So one of the first things I did when I came on board, the team was already using scrum and the first thing they asked me was, “What are you going to change? We know you’ve been doing this for years.” And I said, “My goal is not to change anything. My goal is to see what’s working for you. Don’t muck with that. And then see where you guys need help. And yeah, there’s a lot of stuff I could suggest, but I’m not going to force anything on you because you guys won’t own it. My goal is to coach you to the point where you guys don’t need me and put myself out of a job.” So, when they started getting more mature, I started disappearing. I started disappearing from daily standups, and then the product owner kind of took over running the backlog grooming sessions and I started disappearing from those. And it got to the point where they’re very self sufficient. They still like me to run the retrospectives for them, and that’s okay. But eventually we’ll get to that point, where they can own the retrospectives.

Retrium: And do you think a team can ever get mature enough that they actually don’t need to run retrospectives at all?

Mark: So that’s something we’re toying with actually. That same team that I started with, I’d say they’re very solid scrum team whether they’re face-to-face or remote. And they got to the point where they were making all kinds of micro changes. And we’d get to the end of the sprint and I’d say, “You guys have any topics?” and they’d go, “No, not really. We already kind of took care of it.” So okay! We came up with a working agreement, if nobody has any topics we won’t have a retrospective. I know there are probably agile coaches out there going, “Ahhh!” But what was funny was, they went for about 4 sprints and they went, “This feels weird. It feels like we should be talking.” And they’ve now gone back to the retrospectives and we started talking about when should we adjust things mid-sprint vs. wait until we need a larger conversation. So I’m letting them decide when to make that shift. Now, will it ever go away? I don’t think so. It just may happen on a different cadence.

16[1]

COACHING

[bctt tweet="We spend a lot of time at work. And if you’re not enjoying it, why are you doing it? @mkilby"]

Retrium: Yeah. Let’s transition a little bit into coaching. What’s your favorite part of being an agile coach? What speaks to you the most? Can you talk a little bit about your success stories that have made you feel like you’ve been doing a good job as a coach?

Mark: For me it kind of goes back to that first position where I was struggling with that one manager. It really was a grind. It wasn’t a death march, but it was close at times. And what I learned out of that, and applying some of the agile techniques like extreme programming, is for me coaching is about making life better. I mean that sounds very squishy and you know, rainbows and unicorns. But really, we spend a lot of time at work. And if you’re not enjoying it, why are you doing it? So just as a side note, a few weeks ago, we were wrestling with some big changes and I reached out to my senior VP on Hipchat and I said, “Man I’ve got to talk with you right now.” So we get on the phone and he says, “Is everything okay?” I go, “Yeah, I just wanted to talk through this issue with you.” He says, “I thought you were going just say, heck with it and leave!” I go, “No man, I’m having too much fun!” [Laughter] I’m just passionate about the work. And that’s the point. Work can be tough. But if you’re really passionate about it, you’ll get through the tough parts. And so the big thing for me in coaching is getting people to understand why are they in this seat or standing desk? What is it that drives them day after day? And are they getting that out of the work? The biggest part of that is, do you see the value in what you’re doing? Do you connect with customers? Do you really get to find out what thrills them? Or not? And do you have a way to adjust your own work so that you’re delivering stuff that thrills them? That’s huge for me if I can get that to happen.

Retrium: Yeah. One of the problems I’ve seen when talking to teams that are new to agile, especially when you’re in a coaching type position, is that because it’s a fairly big buzzword these days, there’s some backlash against it now. “Oh agile, everyone talks about it all the time! I don’t want to do that.” Is that something you’ve faced as a coach? How do you overcome it?

Mark: Oh yeah. When I was consulting, there was a few times where I was brought in to “train somebody.” And I could tell within the first 5 minutes, “Oh this is not going to be pretty.” There was one really fun one. I was brought in for a two day scrum training and I could tell just from the initial questions that they didn’t want to be here. And finally I said, “Ok guys, I get it. You don’t want to be here.” And they were just shocked that I called that out. And I said, “And that’s cool. Still, I’ve got a job to do and here’s what I’ll recommend. We’ll touch on the material but really I want to know what is irritating you about this.” And so we basically built up a backlog of irritations and I used that to drive the class. So I still got through all the material, but I dealt with their irritations. And the funny thing was they got way more out of that class than they thought they ever would. And I actually got great reviews after that!

Retrium: You changed their opinion I suppose.

Mark: Yeah, but the thing was they had a lot of misconceptions about what agile was. And basically not only how it would change the work but maybe even in some ways eliminate the work. So there was a little bit of fear behind it. So we talked about that in a safe way in the classroom. When they all came back the second day, I knew I was hitting the right spots.

Retrium: Right. So any advice for aspiring agile coaches? People who are just getting into the business? What would you recommend to people? And what would you recommend looking out for also?

Mark: Yeah, wow. Very different these days. When I first started, I think there were maybe 10 good agile books. And now there’s an Amazon full of them. And lots of bad ones. And you can’t always trust the rating system. I would say that if you really want to get into agile coaching, you want to get experience with a few different teams and then eventually a couple different companies. But along the way, find another agile coach that you trust and can serve as a mentor. That’s something I actually do for some folks here in Orlando. They want to get into that agile coaching role, and I kind of help them on different skills. Also if you can’t get that, there are some organizations that can help. Agile Coaching Institute, and I get no referral fees here, I just really like what they’re doing. This is Lyssa Adkins and Michael Spayd and I’ve worked with them on and off. They have done a phenomenal job at defining what are the skillsets that an agile coach really needs. And that’s now part of the ICAgile curriculum and I think they have built a very good foundation. If you really want to get into this, it’s going to take an investment. Mostly an investment of time and study. Taking a bunch of different classes. But really if you enjoy helping others to get to a better workplace, that’s a great path to kind of talk to them. Their bootcamp is awesome. I have been through it. I have sent others through it. And I still get no referral fees, Lyssa and Michael! [Laughter] But really, I’ve watched that class evolve and they bring in material that I’ve seen nobody else bring in. Just really helping you rethink even agile as you go on that agile coaching career path.

Retrium: Ok, last question as we’re running out of time here. Back to the beginning, I asked you how you got started in the agile world and what sparked your interest in agile. What words of advice do you have for people who are just getting started with agile themselves? What resources would you guide them to? What practices would you recommend them starting with? Words of wisdom coming from a very experienced agile coach to people very new to agile.

Mark: Ok, to get started I would say you’ve got to find a way to just do it. And a good starting place would be scrum or kanban, either one. Scrum I tend to direct people to because there’s a little more structure there and if you get into all the practices, you’ll understand how they work together and how they really support some of the values that you read about in the agile manifesto. After that point, as I kind of mentioned as an agile coach, you want to find a guide because as I was saying earlier, there’s a lot of information and misinformation out there about agile. So a great way is tapping into a local user group if you can. Another great resource is Agile Alliance, Scrum Alliance, Scrum.org, have ever growing libraries of information. Tap into those. If you look into #agile on twitter you’ll probably find a lot of these coaches. But the one thing is, if you can go to some of the agile conferences and meet these people who write the books, a lot of them are really good people! They are happy to spend time and chat with you and get you connected with others. That’s the one thing I really like about the agile community. So get in the agile community, either through your local user group or a conference. They’re going to help you on those next steps.

Retrium:  Perfect! Thank you so much Mark. I really appreciate your words of advice and wisdom. If anyone wants to get in touch with you, how do you recommend going about doing that?

You can reach me via email, mark@markkilby.com or my website www.markkilby.com or on Twitter @mkilby.

Mark Kilby was interviewed by david Horowitz, CEO and co-founder, retrium

Distributed team? Want to run effective retrospectives?

SIGN UP TODAY!  Your First 2 retros are free