Tim Ottinger

Hi, I’m Mike with Uketastic. I’m sitting here. We’re just outside of Software craftsmanship in McHenry County. I interrupted Tim Ottinger to come out and do a quick interview. Tim has written the Agile in a Flash cards or he co-authored the Agile in a Flash cards that Agile teams can use to make sure that they’re on the path of Agile enlightenment. Also he contributed to the Clean Coder book, which all of us are familiar with. Thank you very much for sitting down with me. The first question I want to lead off with is, you wrote this list of all these core concepts to Agile and it’s a pretty thick stack. Was there anything that when you started off with kind of maybe changed as you were maybe something in time realized wasn’t quite the way it was when you – because that’s the thing with Agile is you learn. Not so much actually. We incubated for about a year and a half. Jeff Langer and I did on the website and then when it actually came time to build the book, we really just thought we were going to take articles off of the website and turn them into cards. But we really couldn’t do that because we realized that we were addressing too techy of an audience. So we ended up breaking it down to four sections so we can talk about the project leaders and the managers and the planners and everybody in there. I think the cards have actually stood up pretty well. Our problem was that we limited it to 52. Okay. So you had to do it a few times in a year if you’re going to go through it. Yeah, that’s right. You can do one a week and some teams have. But now there’s just so much more that I wish I could put in there. There’s so much that’s behind those – it’s a very lossy compression when you take whatever’s in your life. You start making these little axioms. And now it’s a four by six card. So the chapter two from Clean Code actually is condensed to I think like a four or five point card somewhere in the back of the deck now. Yeah. And I spent a lot of money on the book and made it a pamphlet. So it sounded like it wasn’t originally going to be flash cards. It sounded like it was going to be a book originally. Well, it’s kind of a weird origin. So I was working for Object Mentor, this was several years ago, in Des Moines at Geo Learning. And one of the gentlemen there, I knew he was a good programmer, his name was George. Hi, George. He was – he asked me – he had missed a morning session. Uh-huh. So I could catch him up. Right. And so as an act of complete chutzpah, I said meet me in the training room with three index cards and a Sharpie and we’ll catch you up. Okay. I had no idea how I was going to do it. But we wandered in. And I know George is smart. I know he knows what he’s doing. He just hadn’t done TDD. So I wrote down Bob Martin’s three rules. Right. And I did the red-green refactor and I did the first properties. And he understood well enough that in the next session he could join with the group and contribute equally. Yeah. And then he realized people are way smarter than we think. Right. And we teach things over four hours. It could have been 15 minutes. Right. They could – And then practice. And especially with experienced people, they might not have maybe followed specific rules, but so much of this is a distillation of practices that are already out there. Right. And when you kind of – people are – and you can point to say, “Oh, it’s this thing.” People might be like, “Oh, okay. I can relate that to X, Y, and Z that I did over the last five years,” or whatever. Yeah. So just give me the cheat sheet. Yeah. So then Jeff and I thought we would write a book and it would be a companion deck to the book. Okay. But nobody understood that. Until we got to Pragmatic Programmers and they said, “Oh, yeah. That’s a good idea. You know, we don’t think we’re interested in the book.” Oh, we just want the cards. We just want the deck. Yeah. So we spent, you know, a chunk of a year working on the deck. So there isn’t anything that’s really wrong in there, but I think nothing could go far enough and nothing could go deep enough to really get to the important stuff. Yeah. And then I’ve been boning up more like on Brain Science, David Rock and Carol Dweck and Csikszentmihalyi and Haidt and all these different guys. I really kind of wish that I could have earlier gone through and done all of this about how to coach and how to learn, and that could have been like a whole section or a whole other deck. So not even just how to be an agile team, but how to lead an agile team. Yeah. And how to think about leading. Okay. Yeah. That’s… Don’t really think about thinking. Think about leading too much. I mean, a lot of us are… I mean, a lot of us are developers who are kind of like focused on just how I can contribute, but taking that step back and… I mean, is that even like going to the next level of your career or is that something that even applies to people who are working on a team and aren’t in a leadership position? I think that… I think it applies to individuals. I think it was… Was it maybe Keith Ray or maybe Jeffries or maybe Reinsberger, we’re talking about having an inner critic. Right. So when they’re practicing writing code, half of their brain is split and is critiquing and observing how they go about solving their code problems and how they’re thinking through the problems. So they’re actually kind of like two people. Right. Which that’s hard to do. But by mindfully practicing your code art, you can suddenly realize better ways that you can step things out and things you didn’t realize that you need to learn. It’s kind of like… So ultimate small community, two pair programmers. Yeah. One person, while they’re typing, they’re thinking very pragmatically and very detailed and very… Right. How do I solve this problem? Yeah. They’re just going to get that thing to happen. Yeah. And then the other person who’s watching them, yeah, they’re watching for syntax errors or what have you. Yeah. But they’re also thinking, “Is this the right direction? Is this a good answer?” Where are we going? Does this make sense? Yeah. Where are we going to end up by going this way? And I kind of want to do that inside my head, but I’m finding that there are just too many cognitive biases. Yeah. You really can’t entirely do it. Yeah. But you can develop a sense of watching yourself work, which I think is important for everybody. Right. Well, that’s kind of like with Koryan’s katas and even Zed Shaw’s Learn Program the Hard Way, it’s you do these things by rote and you do rote enough that you stop thinking about the problem and you start thinking about how you’re approaching it. My fingers, like doing guitar practice, can I get my fingers in that position? It’s not… I could just do the same note a hundred times. But I just want to get that position and it’s the same thing with the code. I don’t want to solve this problem, I just want to solve a problem while. Right. Right. So it’s the shuhari pattern. We have a card for that. Oh, yeah. That’s right. Yeah. It’s one of the cards. One thing, though, I just want to tie this into user communities, though. You kind of described a pair as the ultimate small community because it’s two people that have to collaborate and agree on a direction. Yeah. Yeah. And share knowledge of that code and the problem. But in the more macro groups, the user groups and the conferences, you travel all over the world. Have you gotten a chance to go and experience other groups or other conferences and see a conference in Australia as it compares to a conference in Copenhagen? Not quite so much as that. Now, I did just get back from New Zealand and I attended the Canterbury Software Summit, and you’ll find it’s a lot like our conference. Our conference is here. You know, the scale is a little different. The South Island there, they’re really now starting to become agile and they’re really using like distributed governance and all kinds of crazy, you know, we would consider far out. Right. But they’re small. And they are very tight into their community and they have their own consultants. So it’s actually a very tight-knit group and people know each other and they’re all in a similar experience of growing toward agility and growing into new technologies. Yeah. So what is distributed governance? That’s kind of an interesting question. There’s a nice talk by Scott from AdScale. Instead of having a hierarchy of bosses, your company is formed into rings of influence. So maybe you’re a programmer, but also you have a knack or an interest in the work of maybe writing proposals and collecting new business. So you may be sitting in both of those rings. Oh, okay. Yes. So there’s a ring that decides how to pay the bills and what the salaries are, and there’s a ring that decides how to … Usually they’re very separate. Right. Those guys over there handle economy. Those guys over there handle HR paperwork. So it’s actually being managed, ruled, and run by little communities and people are members of different communities and, of course, the task is the reason for the team. So if you’re into bill paying and money management, you can be a part of that little community within the company. Yeah. It’s really amazing how well they’re doing, how open and transparent and how sharing they are with everything. It’s really a great place. Yeah. Now, I don’t see that so much here. Yeah. Yeah. It’s a little bit more hierarchical, a little more rigid. Yeah. Well, anyway, I want to say thank you very much for taking the time to sit down. Thank you.