Demanding Technical Excellence with Declan Whelan

Drew LeSueur: Hi and welcome to another episode of the Agile Weekly Podcast. I’m Drew LeSueur.

Roy vandeWater: I’m Roy vandeWater.

Jade Meskill: I’m Jade Meskill.

**Drew:** And with us today is Declan Whelan. How is it going, Declan?

Declan Whelan: Oh great. How are you guys?

Is Demanding Technical Excellence Still Relevant?

Drew: Doing good. Today, we wanted to talk about demanding technical excellence. I’ll start off with a question for you, Declan. Why is this still relevant? Why are we still talking about this today?

Declan: I think it’s probably more relevant than ever because from my experiences as an Agile coach over the last few years, I’ve seen Scrum become more and more prevalent. Which is great. It’s more like just a framework for project management and as we’ve crossed the chasm in many ways with Agile, I’m seeing a dilution of technical skills.

I think it’s kind of ramped up a little bit, because the people that were most motivated for Agile in the early days, tended to be very technically forward looking, and technically adept. That, I think, is becoming less so as we’re moving into larger organizations, where people aren’t quite so motivated perhaps, to be self learners and so on. I think the demand or the need to promote technical practices is stronger than ever.

Drew: Great. Technical practices, I think a lot of stuff like pair programming, the XP principles and practices, is that the kind of stuff you are talking about as well?

Simple Design Is Just Missing Now A Days

Declan: Yeah, exactly. I remember the podcast you had with Arlo earlier this summer, and a lot of that for sure. In fact, he said it so eloquently in many ways, with his metaphor of the train and Scrum just being the steering wheel and the rest of the engine. Or I guess actually the car, becoming some of the technical practices.

He didn’t mention explicitly, and it was the subject of a talk I did in Dallas last week at Agile 2012. It was simple design. I found that to be kind of very illuminating that in the version one annual survey that they do, they list the technical practices. They barely get over 50 percent on any of them.

They think unit testing might be 70 percent, and then all the rest of the technical practices are maybe 50 percent, but most way down like 12 to 20 percent, but the really strange thing is that simple design does not appear anywhere. It is not even on the list. I find that quite fascinating.

Jade: I came into the whole agile world and ecosystem through Extreme Programming (XP). I’ve always wondered why it didn’t quite get the legs or the following that Scrum ended up really capturing. Why do you think that is?

Declan: I don’t know for sure, but my suspicion is that Scrum is just so much easier for organizations to grok. It can fit on a single page, it doesn’t look too hard. I think just that, and I am sure the Scrum certification models had a part to play in it. I think it was mostly just the simplicity of the model.

Roy: Is it maybe the centralized nature of something like Scrum?

If you get a product owner Scrum Master that is properly trained, they can kind of disseminate that amongst their entire team, but if you want to practice a lot of these technical practices, you have to have an entire development team that is able to do all of them.

Do you think maybe that plays a part?

Declan: I am not so sure. I think you’ve got a good point. This is perhaps a little more specificity in terms of the roles that might make it easier. We’ve got project managers, so we can make them product owners, and we’ve got project managers, we can make them Scrum masters and that’s not too hard.

Whereas with maybe the titles don’t fit quite so cleanly with XP. It disappoints me that XP has not become more popular than it is, but the odd thing is that teams are doing Scrum really well are actually doing all the XP practices anyway.

Jade: Yeah, that’s what we’ve found as well that for teams that we’ve been on or coached that as the maturity of the Scrum implementation came along so did that desire to implement much higher quality technical practices.

Scrum As A Way To Build Technical Debt Even Faster

Declan: Yeah, that’s great when it happens. I am not so sure that that’s going to happen consistently with some of the newer organizations taking on Scrum. I hope it isn’t, and believe me, I’ve been thinking a lot about what can I do to help make sure that happens? Because, on the flip side, I’ve seen Scrum provide teams with the tools to build huge mounds of technical debt faster than they ever could before.

Jade: Yeah, that’s true.

Declan: My mention of demanding technical excellence came up from a meeting that the signatories of the Agile Manifesto had last September. They, basically, came up with a plan directive. They felt that over the next 10 years, we really need to crank up the technical excellence throughout the industry.

I believe that, too. It’s not that there aren’t other important things, it’s just the thing that really strikes me as having waned since the last five years.

Jade: How does one demand technical excellence?

Declan: [laughs] I don’t know. One thing that I’m really excited about is that in Dallas, I’m the newest member of the board on the Agile Alliance. I feel that that gives me an opportunity to explore that a little more deeply. In terms of pulling from people like you and other passionate people about what it is as a community can we do to perhaps…I would choose the word “foster” technical excellence.

The “demand technical excellence” was just Sutherland’s term. I might choose slightly different terms. Look for ways, certainly, with teams. In terms of what you’ve described.

You’ve been able to demand technical excellence in the sense that fostered teams moving from Scrum into extreme programming practices which is awesome. Some things people have suggested, bringing back the original XP conference.

Certainly, the software craftsmanship movement has something to say about technical excellence. At this point, I’m really just getting tuned into the idea and I’m quite open to how we, as a community, coped.

Fostering Technical Excellence

Jade: I’ve often thought about it in that, I feel like, I can demand technical excellence from myself because I understand what that means. I like your idea of fostering into others. I think those two go hand‑in‑hand.

If I am relentless about demanding it of myself, hopefully, that is creating that desire in other people to want to follow that example.

Declan: Actually, the things I’ve done as an Agile coach, pair programming, certainly, is a great way, in and of itself, is a technical practice, but it, certainly, fosters the spreading of knowledge and skills that deepens the more technical aspects of good design.

Expanding the definition of “done”, having regular retrospectives, promoting learning. There are lots of things that can be done, certainly, at a team level.

I’m thinking, also, that more, on a wider level, how do we do that as a community as well?

Drew: As far as the technical excellence stuff goes, you being an Agile coach, is it ever hard for you that you’re focusing more on team related stuff or on other things that are apart from just maybe sitting down with somebody and pair programming and doing test‑driven development with somebody? Is that ever an issue with you?

Declan: It is. I, certainly, have this stance as an Agile coach that my job is to provide teams the best help that I possibly can. I work hard to be tuned to find out where they pain is and where I can have the most leverage, and I focus there.

As I’ve moved up into larger organizations, less and less of the time do those points of leverage ended up being technical. I’m OK with that as a coach in doing my job and as my role.

But, as a software developer for 25 years, I do find it difficult because I just find if I’m not coding on a regular basis with this…there’s kittens that die…

[laughter]

[crosstalk]

Declan: …my brain, right? As a professional, I don’t have an issue with it. But, personally, yeah. I really want to keep coding on a daily basis.

Drew: In my experience working with teams, I’ll pick one of the XP practices which is pair programming, which I really love, and I do a lot. I’ve been on a team where that’s been hard for some people, where they’ve gone their whole program career not pair programming.

Then, all of sudden, somebody comes in, like a coach or somebody else, who wants them to do that. Transition‑wise do you have any advice or anything you would like to tell us?

Running Experiments

Declan: Some of the things that Arlo mentioned are things that I really believe in. Certainly, running it as experiments, making sure that it’s viewed not as a team commitment, but as something to explore, and making sure that the team feels they’re in control.

I’ve sometimes done it the other way, where I just get teams to agree to pair program for a short amount of time. I’ve, perhaps, had a different experience with Arlo. I find I get benefit even if the teams pairing some of the time. That’s quite a bit better than not pairing at all.

Maybe getting them to do full immersion pairing might be too difficult. I certainly have found cases where it’s too difficult. It may not be because people don’t want to.

It can be the culture or the organizations, so it’s actually mostly outside of their control. Certainly, I think going moving with empathy [laughs] and with giving people a choice and putting out offers rather than them trying to force it down anyone’s throat.

Jade: I have to follow that up with a confession. When I first heard of pair programming and some of the XP stuff, I thought it was the dumbest I’ve ever heard of. I was a developer and I was managing other developers. I thought what a waste of time having two people sitting at one computer.

This is the dumbest thing in the world, until I experienced it myself with someone who was very good at actually doing pair programming, and including me in that process, really brought me along. Totally converted the way I viewed that practice.

Now, I’m a huge advocate of it. Love it. But, I was highly skeptical at first.

Declan: I think that happens a lot with a lot of these technical practices. And too, another thing that I’ve become more attuned to as well is using games.

I think Joshua Kowalski came up with a pair‑drawing game, which is a great way to introduce people to the idea without having them commit to it in any way, but experiencing some of the benefits from it.

Jade: That’s cool.

Drew: It’s cool talking about your transition, Jade, right? Seeing when teams start to capture the vision of some of these practices when they’re excited to write tests or when they say, “Oh, let’s write a test for us here,” when maybe they wouldn’t have before.

Or get excited about pairing on something or, “We’re going to pair if we want to get this done faster.” Those types of things are exciting to see with teams.

Declan: What I’ve learned the hard way as well to really look for where the energy on a team is, so if the energy happens to be when I’m doing more testing or refactoring or pair programming and moving, even though as a coach, I might feel that they might get better leverage from pair programming over something else.

I tend now to move towards where their energy is because that’s more likely to be successful. If they’re showing energy before something and it’s not pair programming, I’m OK with that. [laughs]

Drew: Great. Yeah. Good stuff. Thanks a lot for joining us, Declan. Do you have anything you’d like to share with the audience?

Declan: I would. I’ve had a very interesting couple of months, being the newest member of the Agile Alliance Board, which I’m very honored to have. I welcome any insights or suggestions people may have for me in that role, particularly, towards promoting technical lessons.

Another thing that I’ve done the last two months is I’ve co‑founded a start‑up called printchomp.com. Chomp as when you’re chomping on something good.

We’re using Lean Startup and Agile and you can find us at www.printchomp.com. We’re going to be launching in mid‑September, so sign up and we’ll keep you informed of how that goes.

Drew: Awesome. It’s been a pleasure. We appreciate you joining us on the show today.

Declan: Thank you for having me, my fun.

Drew: All right. Talk soon.

Jade: Bye.