Josiah Renaudin: Welcome back to another TechWell Interview. Today I am joined by Jared Richardson, the principal consultant at Agile Artisans and a keynote speaker at this year's STARWEST event. Jared, how are you doing today?

Jared Richardson: Doing great. Good to talk to you again.

Josiah Renaudin: Yeah, good to talk to you again, too. Before we really dig into the content of your keynote, can you just give us a refresher on our experience in the industry?

Jared Richardson: Oh, gosh. Sold my first program back in 1991, beautiful little CBIT with so many memory leaks it made a grown man cry. Got involved with Small Talk. Came up through Java, was one of the second public signatories of the Agile Manifesto. Got a phone call when the authors were writing it saying, "Hey, you got to get in on this." Started the local agile user group here in Raleigh Durham, North Carolina, back in '07. We just passed 1,800 members. One of the, if not the largest agile user group in the world, I believe. Definitely the largest one on meetup.com last time I checked. Working with Andy Hunt these days, one of the authors of the Agile Manifesto on a new agile methodology, the GROWS Method, so that's keeping me busy. I pay the bills as a coach and speak to conferences from to time, as I'll be doing in Anaheim.

Josiah Renaudin: Absolutely. We always try to evolve as testers or as any member of a software team, but I was reading through your abstract and you were talking about these certain walls that testers hit. Why is it that so many testers hit a personal development wall and fail to get past the required training they need?

Jared Richardson: I think most organizations, most teams, they get stuck in the short-term delivery trap. It's, "Oh my gosh, this is what's going on, we have to work this problem, we have to work this release, we have to solve this," and they're so busy working individually as a team and as a company that nobody ever looks up. I came into work with one team, almost a decade ago. Thirty testers, and people are constantly fighting fires, putting out fires, fixing problems. Good people doing good work. They were so busy with their heads down, they had never heard of something like continuous integration. I, instead of helping them, took a step back and put in a CI, you know it's cruise control back in the day.

Several senior members of the team complained bitterly to me and to my manager that I was not sitting beside them and clicking through test scripts. A few months later, when the CI system was up and running, and running automated tests and automated test suites and eliminated a lot of the work people were doing every single day and freed them up to actually do bigger picture work, their minds were blown. We get so busy getting stuff done we forget it's not, I don't know the highest good is not to do the work in front of us efficiently, it's to do the right work.

I think that's why we end up hitting a wall. We're so busy working, we're so busy doing what we're asked to do and then one day we turn around and the industry is moved past us. The problem with most corporations today is quite often, they'll say you know what, the industry's moved past you, have a nice day, and they'll outsource your job, they'll lay you off. They'll hire somebody with the right skill set. While I believe it's much more cost-effective to train as you go, I don't know that you can always trust your employer to do that and that puts the responsibility squarely on your own back to drive forward on a day-by-day basis.

Now we're moving over to the keynote material, right? It's intentional experimentation as a way to keep your skills cutting edge, to bring in new technology, and to make your job easier. To leverage what you know and to make sure you’re more effective. On the one hand, it's great for your company, it's great for your team, but it future-proofs your skill set because you're always, I say always, right, weekly, you’re spending time, some part of that week, trying something new. Maybe it will fit, maybe it won't. Maybe it will be a good fit for the next project. If you're taking a few hours each week, you're going to be the one that knows all the cool new tool kits, you’re going to know the new tool directions, you're going to know how to automate this script. You'll become invaluable. I'm talking a long time.

Josiah Renaudin: It's absolutely fine. You mentioned the corporate culture and that's what I think a lot of this is, where you’re focused on getting these tasks done instead of, of course getting tasks done but also improving yourself, making yourself future-proofing in a way. Growing in this kind of manner can almost feel like a second job at times because you’re worried about getting every single task done, you’re schedule is already stuffed, but you also have to think about the future and you don't understand the stuff now, so move along. How difficult can it be to do your regular job duties while also learning new skills that prepare you for the future?

Jared Richardson: When I'm in that kind of environment, I try to, I've been at the company before where you have to do this in the, evenings and weekends, which is not great, but when I'm at most places, I try to carve out two or three hours, maybe on a Friday afternoon. I try to carve out a couple of hours at least once a week. I call it Seinfelding it; I think Seinfeld called it the daily chain. If you want to be good something, you don't ... Someone was asking Seinfeld, "Hey, how do I be a comedian, how do I be a screenwriter, how do I do what you did?" and he said, "Whatever it is you want to do, put a calendar up. Every day when you've touched it, even if it's thirty seconds, put an X through there." He said, "Some days, maybe you'll touch that script," in his cases it's a set of jokes or a screenplay, but in our case, a test script or a new automation tool or some research.

One day you may only get five minutes on that, but one day, that five minutes may stretch out to an hour. If you try, if you can't do it every day, at least do it every week. If you touch it on a regular basis and you revisit it in some small way on a regular basis, one day you turn around and you have become the expert.

That said, most places I've worked, when you come in and say, "This needs to be automated," or "This needs to be improved," it is difficult at first to get them to understand that it's necessary. I was talking with a former client this week, and he was saying, "I told the story of you," I'm like, "Well, that must have been a boring story." He goes, "No, no, no, no. We had a build that was taking two days," he said, "and you came in and trimmed it down to eleven minutes." I'm like, "Well you forgot the six months in the middle where I was saying, 'Hey this is on a on old machine, it's on out-of-date hardware.'" This build only ran on a single machine. We pulled it out, we cleaned it up, we poured it to Ant, we took advantage of Ant's threading capabilities and we put it on modern hardware. Once that one build went from overnight to not enough time to get coffee, was the joke and complaint we got from the developers and testers.

After I did it once, then management came back and said, "Wow, this is great, teach us how to do it on twenty other areas." You may have to fight the fight right up front. Maybe you bring in Selenium and nobody thinks you need to automate anything at the webpage level. You do a proof of concept. You show them. Sometimes you have to lead the way from the front you can't talk people into change. You have to show them. You have to prove it. You have to quite often do it first yourself.

Steal the time if you can. Take half an hour here, half an hour there. If you absolutely have to, maybe you do in the evening, but that's again, that's also one of your warning signs you're not in a very progressive organization. The point is not to pick it and hope it works. Intentional experimentation says to pick it and see if it works. If you're three, four weeks in and you're trying Selenium and it just doesn't work well for you, drop it. Go try something else, right? Move down to a different level. Move to a different tool, move in a different direction. Never stop learning, never stop trying.

Josiah Renaudin: You did mention the idea of future-proofing yourself. Of course it's extremely important when the industry is changing so rapidly, when new methodology is coming in, when you need new skills to survive. What skills to you feel are the most important to learn or even master as testing continues to move forward?

Jared Richardson: Let me step back a little bit and invoke the Dreyfus model of skills acquisition, which is something Andy Hunt brought to our industry back in his Refactoring Your Wetware book. In the Dreyfus model, it tells us that when we're at the beginner's level, learning is hard. It's difficult, it's frustrating. When we are experts, it becomes easy, it becomes second nature, it becomes intuition. Those of us that have been doing this for a few years, operate hopefully at level four and five. We're pretty good at what we do. We're not used to working hard to learn. We've lost the beginner's mind. We've lost the expectation that learning something new is hard. The most important skill you need to cultivate is the ability to continually learn, especially when it's not fun.

When you kick down from level four and five on what you know to pick up a brand new tool kit, a brand new scripting language, a brand new automation tool, it's not going to be fun. It's like you were lifting weights for fifteen or twenty years, and you go and try to do squats. The next day you can't walk. Eventually it's not so bad. Eventually it becomes second nature, it becomes habitual, but most people quit when they try to learn something new and they've not learned in a long time. That's what you're going to have to cultivate and that's what you're going to have to go after. When you start using muscles you've not used in a long time, it will not be fun. I tell you what, it's a lot more fun six months down the road than it is that first couple of days.

Josiah Renaudin: It's kind of shockingly so now, where even I know—I'm younger and I'm not that far out of college, and I think I grew up in this era when you can just, not to sound like an old person who complains about how far they used to walk to school, but when I try to solve things, it's always you go to straight to Google, you go straight to you phone to figure something out. The idea of learning something can be daunting, especially if you get in this rhythm, if you get in this kind of daily or weekly pattern and someone's like, "All right, learn this new thing."

Like you said, it’s like you haven't done a curl or you haven't lifted in a long time and suddenly you try to do it, and your first instinct is, "I don't want to do this. Why would I want to do this? What I've been doing before is working fine," so the idea of trying something new and expanding your skill set can be really tough to kind of look at that and understand, "I need to put this amount of work in, but I don't want to do that work." It's hard to get over that initial mental hurdle.

Jared Richardson: It is, especially if you've spent a long time at level three, right where you’re executing on these recopies that you know and have done for years, or if you’re level four and level five, that's the skill. If you learn, everything else is, you can do anything. A lot of times, we, well to drift into the whole ageism thing, a lot of times the company will let the more seasoned people go often because they're not learning. There's other reasons and it's a broader problem, but that kid right out of college is used to learning like mad, and if we can stay in a place where we're constantly learning, where we're teachable, it really changes the game and your value in any team.

Josiah Renaudin: You mentioned intentional experimentation, deliberate learning a couple of times in this conversation. Just to make sure we have a good idea of what those are, can you define those two terms in this specific context?

Jared Richardson: Sure. As I've looked back over my career, I've been very lucky, I've gotten to work with some really smart people, and talked to them about their career. I wrote a book Career 2.0. I interviewed a lot of my friends and got stories and whatnot. What I've noticed is that most of us had our great leaps forward through accidental learning or an accidental experiment or you got lucky enough to work alongside somebody who knew Ruby on Red, or who knew Selenium, who knew about continuous integration and continuous testing. The great moves in almost everybody's career that I talk to, including my own were dumb luck. They were accidental. Rather than wait for my next big learning or my next big move forward, one of the things that Andy Hunt and I put into the GROWS methodology is, "You know what, let's continually intentionally experiment."

If we're going to pick up a new framework, I don't want a framework, I want to look at three frameworks and I want to use each one for a week or two and then I'll come back and make an intelligent decision. I don't want to use the first hit in Google. I don't want to use the first easy example that I find on the web. I don't want to just learn what the guy in the cube beside me knows. I want to deliberately acquire knowledge on a regular habitual basis.

There's a whole section, Andy and I have an onsite GROWS workshop that we do for two days, and there's a whole hour or two on deliberate learning. Your learning notebook, how you drive yourself forward in the absence of any external force doing it. When we talk about deliberate learning and intentional experimentation, that is a game-changer for how you acquire information and it takes you out of that, "Hey, I got lucky again, you know, I worked beside a genius and got to pick their brain." And moves you towards actively seeking out and finding new things to learn.

Josiah Renaudin: The GROWS method itself does include intentional experimentation as a key concept. How does intentional experimentation in GROWS relate to the intentional experimentation for testers? Is there any overlap we can take advantage of?

Jared Richardson: It's way overlapped. It's the same thing. In GROWS, it's broader than just testers. There are sections in there for executives, for developers, for testers, for teams, for customers. It is the same intentional experimentation, though. You see a need, in fact, if you look at the GROWSmethod.com website, the big graphic on the landing page has these arrows that run in a circle and that is the intentional experimentation loop. You see a need and you go try something. You don't try one thing, because that's a prototype.

I worked with a client who would pick a tool, claim they were doing a proof of concept, and then always adopt the tool. They never ever eliminated the tool during the proof of concept. It wasn't a test, it was a prototype. It was pre-adoption, but they were told they should have a proof of concept, so they had one. If you have two or three proof of concepts, if you have two or three experimental usages of different tools, of different approaches, of different testing methods, then you have to pick one. You actually have to pay attention to the feedback and make a choice. In GROWS, we say, "See a need, go run three or more experiment, come back, look at the results, and learn from it, and then pick one and move forward." That same intentional experimentation loop in GROWS is the same one I will be talking about at the keynote in Anaheim.

Josiah Renaudin: Great. All of this learning we're talking about is fantastic and it's great for personal growth but you can never forget that a software team is just that. It's a team. If you learn, let's say you're in the NBA, and you start learning how to hit a thirty-foot jumper just every single time, you keep nailing it, that's great for you, but you can only go as far as your team takes you, so you want to make sure you share that knowledge so other people and so. After you've learned how to bring your testing skills to the next level, how do you effectively teach what you've learned to the rest of your team to make the projects much smoother and better?

Jared Richardson: I find the best way to lead is by example. I think I said earlier, I find it very difficult to talk people into change but I can show them how to change. In the testing arena, if we learn a new automated testing tool, we learn a new testing approach, I love to use something like continuous integration, like Jenkins is what I'm using these days, it's free, it's open source, hard to beat the price, hard to beat the community, the plug-ins and everything around it. I'd love to set up a Jenkins machine that is watching the latest install.

Whenever somebody updates it, they touch it, that new test runs. While I may not send the email out to whoever checked into the code, when I print out that error page, and I walk over to another tester and another developer and say, "Hey, Bob, that code you just checked in," cross your fingers and put them behind your back because you're fibbing a little bit now, and say "I'm not sure if this is accurate or not, but I'm trying out a new tool, I was wondering if you would do me a favor," Ben Franklin says, "You want to make a friend, ask a favor." "I was wondering if you would do me a favor and look at this error message and tell me if you think it’s legitimate.

Anybody worth their salt, whether it be testers, developers, managers, you pitch that and you must hand them a piece of paper that has the error message on it, and ten minutes after they have looked at it, they'll be in your cube and say, yes, it's legit, hopefully if you wrote a good test, thank you for telling me I've just fixed it. Why are you getting these and I'm not? How do I get this email that you just printed? Now, you've pulled in a second person, you've pulled in somebody else who wants to learn.

I'm a big fan of pair programming for developers and testers. You're a tester, you've just written a new Selenium script, pull somebody over and say, "Hey, I want to get a second set of eyes on this before I check it in, before I save it in the repository. Could you look at this and tell me what you think. Again, anybody worth working with, amateur tester goes, "Wait a minute, how'd you do that? You're doing this, I had to buy this mercury tool over here and we don't have budget for me to have a seat." You go, "Well when you get Mercury poisoning in real life they give you Selenium, so here's Selenium, an open source tool, and you have a good laugh and you show them how to use it and now you've got two people.

Set it up and run it. Make it work for yourself. If it's not solving a problem, ditch it, go try something else. Eventually, you will reach a place where you can effectively do what you couldn't do before. I've seen people that will take forty hours of manual testing and they have it run in three to four minutes of automated testing, and they show that script to another tester, oh, gosh, they're like, "Teach me, I'm here to sit beside you and look over your shoulder. I want to be able to do what you're doing."

You show good people how to save time and leverage their expertise, good people will want to copy what you're doing and will ask you for help. If you show it to other people on your team, and they go, "Oh, well, that's dumb, "You spent two days writing a script, I can click through that in half the time." I'm like but yeah but, "You have to click through every time." I forget who said it but it was "Change your organization or change your organization." Introduce new tools and if everybody thinks they're silly and you can't drive things in good direction, find an organization that does want to do these sorts of things.

Josiah Renaudin: Absolutely, and I don't want to give away the entirety of our keynote, so more than anything, just to kind of wrap this up, what central message do you want to leave with your audience after you do deliver your keynote in Anaheim?

Jared Richardson: I would say the central message is, "Don't leave your career in anyone else's hands, and keep the learning mindset. If you've lost it, reacquire it. Go learn something new today." I think it was Bill Gates back in the '90s who said, "If you get excited about something, and you don't act on it in the next twenty-four hours, it's like 94 percent change you won't do it." I'll dumb that down and say, "If you get excited about the idea, go do something now." Learn something. Something small. Something basic. A scripting language, an automation tool kit, an approach, something around test first, something around a soap testing tool, a rest testing tool. Learn something new every day. Pick a few things. Sit down and deliberately map out where you want to be in six months, one year, and five years. Write down the steps to get yourself there and every day touch one of those things.

Go out and Google and find five different things that you want to learn, write them down. Write down the five different things that you're going to try and to pick one. Deliberately lay it out. Don't be accidental. Run on our intentional experiments, try them, prove this works and that doesn't. When you're done, put them to work. Don't be afraid to throw anything away. Don't throw good money after bad or good time after bad. Even if you've spent two months on a tool, if it's not solving the problem you've got, throw it away. Don't waste three months. Start over and find what works. Then, send an email. Tell the world about it. Write an article. You'd be surprised how much it will make you learn to write it up and share it with other people.

Josiah Renaudin: Absolutely, I think that's great advice. Thank you again, Jared, for sitting here and talking with me. I will actually be in Anaheim this year moderating the virtual conference for your keynote. I look forward to hearing the full thing closer to the end of the year.

Jared Richardson: I look forward to actually meeting you in person for a change, instead of on Skype.

Josiah Renaudin: Yeah, about time.

Jared Richardson: Awesome. Looking forward it and looking forward to meeting some of you others as well.

Principal consultant and a member of the core team at Agile Artisans, Jared Richardson is a process coach who works with software teams to help them build excellent software. He sold his first software program in 1991 and has been immersed in software ever since. Jared helped create the GROWS methodology and has authored a number of books, including the best-selling Ship It! A Practical Guide to Successful Software Projects and Career 2.0: Take Control of Your Life. He is a frequent speaker at software conferences and a thought leader in the agile space. Jared lives with his wife and children in North Carolina where—quite by accident—they became backyard chicken farmers.