| Interview with coach Declan Whelan. Our discussion, held June 1, 2008 at the Agile Coach Camp. |
WW – Take a minute and tell me about yourself and your background, and how you became a coach and what you’re up to.
DW – I’ve been in software for… I realized it’s over 20 years and I think, “Oh my gosh, but I have the gray hair to prove it.” About four years ago I was doing some consulting work with a company in Toronto. They had decided to go agile across the board and they brought in some excellent coaches such as Jim Shore, Jim Highsmith, Joshua Kerievsky, and Gunjan Doshi. I had heard about XP before that but I hadn’t really taken that much interest in it. But then I saw what was going on. It was phenomenal watching the energy level and feeling that there was a deep and radical transformation happening. I got bit by the agile bug from that experience.
I then had an opportunity to work with a company that was really struggling with their software development group. They had been habitually late, habitually buggy. They would plan two or three point releases right after every major release because they knew they’d be patching it up. They were really at a point of failure. Someone said they were looking at firing the whole software team. I was a last resort. Now, the problems were really much wider than the software team but that was the flash point. This was a good opportunity to bring agile in because they had nothing to lose. So we did, somewhat incrementally because the team couldn’t turn on a dime. We just did some simple agile things then slowly evolved it so that after 18 months they were ready to launch a full-blown XP project which was quite successful. After that, the team transitioned to use a combination of Scrum and XP.
I continue to consult with this company and have expanded my agile repertoire. I now provide agile coaching, training, and development on a wider scale.
WW – What practices did you start with on the incremental path you had them on?
DW – It was simple PM stuff. I had the business unit work with me and the lead developer to estimate all the open issues and classify them as:
“A”: Must have
“B”: Should have
“C”: Nice to have
I then talked to the development team and got their buy-in that they would commit to and support a date if I guaranteed that they would have twice as long to do the work as they themselves estimated. They supported that.
Then we gave the business unit a development budget for the “A” issues:
“A” Budget = # of developers * working days / 2
We guaranteed to the business unit that we would deliver all the A issues. We would try to get some of the B’s and C’s — “If they happen to fall in the same area of the code, you might get some of those.” They key was that we committed to a date and that gave the business unit some degree of certainty that they could plan around. We then met with the business unit on a regular basis to track progress and to reprioritize as any new issues arose — but we held them to their A budget.
And it worked. The team was able to get all the A’s and they got a few B’s done and they met their commitment. The business unit were impressed: “Oh my gosh, that’s the first time we ever had a release delivered on budget and on time.” We were actually one week late but that wasn’t bad compared to their traditional three months late. After that, the team planned and executed the next four releases like clockwork. So it was really just team building, setting reasonable expectations, and building trust and confidence. Once the team and I had credibility, we were able to take the next step. “If you like what this is doing for you, we can be an even more effective team if we take the next step.”
WW – What do you find the challenging areas for the coaching you do, either personally or from the angle of the hardest group or person to work with?
DW – I find for me, the hardest part on a one-on-one basis is the really skilled software developer. I find it really difficult to go in and be in the position of saying, “We’re all in here to learn. Life is a continuing learning experience and perhaps I can bring you something that maybe you haven’t seen before.” But if they’ve been doing it for as long as I’ve been doing it, and especially if it’s in their domain and they’ve been working on this team for ten years, they don’t think there’s anything they could possibly learn. I find it difficult to get them to switch that bit in their mind, to open up to the possibility that they could learn something new. For me that’s been the biggest personal one-on-one challenge.
WW – Do you have any techniques or tricks you try with that?
DW – I’ve tried to be technically really good. I try to write code frequently, if possible every day. Try to stay current so I can gain some trust that I know what I’m talking about. Pair with them. I still find it a challenge. The really good people will always claim, “Yeah, that worked well in this case, but in the 95% of the cases I deal with…” It seems to be this credibility thing, that I have a hard time bringing people to the stage where they can see for themselves. Do you have any?
WW – I do the same – I think pairing with them and being able to demonstrate that I can do solid things helps me too.
WW – What do you to do keep up with your own learning that you need to do?
DW – Read. I read a lot. I tend to read seven books at once. I don’t know if it’s a common pattern, it’s probably not a good pattern. I also buy a lot of books that I have on the shelf. So if I have a question on planning, I’ll go get Cohn’s book on planning. I tend to have a large number of books.
There haven’t traditionally been a lot of practitioners in my geographical area. I’ve been trying to build an agile community in the Waterloo area, which is where I work. That’s looking good. I’m hoping that next year we’ll have a local agile group.
I’ve had fairly challenging positions. I’ve been heads-down in the trenches for three of the last four years. It’s only been in the last year that I’ve made an effort to get a website blog, go to conferences. I’m working on that part of it now.
WW – Is there a book you’re reading now you particularly recommend?
DW – The one I’m reading now is Agile Software Development, second edition, by Cockburn. I started the appendices first like Alistair recommended. I find it fascinating he draws on relatively old stuff, stuff that was written in the ’70s, and it resonates today. I’m an abstract thinker; I like to go from the abstract to the concrete, not the other way around. I think that’s the way he writes. He derives concrete from the abstract content, and I like the mental model he likes to write from. I really like the jargon/analogy of a game. I’m a coach of kids in sports, and the strongest metaphor I’ve seen for agile coaching is coaching children’s sport teams.
WW – Thank you.
DW – You’re welcome.
Resources
- Mike Cohn, Agile Estimating and Planning.
- Alistair Cockburn, Agile Software Development, 2/e.