Real Work vs. Bureaucratic Silliness

Panelists:

References:

• CASE – Computer-Assisted Software Engineering
• Intentional Learning
• A Hands-On Introduction to Exploratory Testing
• The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
• Agile Iowa 2016
• National Software Testing Conference NORTH
• Lean Agile Scotland 2016

Transcript:

MATTHEW HEUSSER: Hello, and welcome to The Testing Show. I’m Matthew Heusser, here live, [FIST BANG], at Agile2016—I probably shouldn’t bang my fist on the table—talking to a panel of experts about a couple of new and emerging ideas that I hadn’t heard before. So, we’ve got Emma Armstrong, all the way from Cambridge, England.

EMMA ARMSTRONG: Hi. Yeah. I’m Emma, and I’m a tester. I work at Willis Towers Watson, and I’ve been working in the industry… for a rather long time, trying to help promote the community that we want to build.

MATTHEW HEUSSER: So, you’ve had the experience flip where you go from, “I have seven years of experience,” to the kind of, “Yeah, I’ve been around.”

PARTICIPANTS: [LAUGHTER].

EMMA ARMSTRONG: Yeah. I’m old.

MATTHEW HEUSSER: Dan Ashby from Scotland.

DAN ASHBY: No. Cambridge now.

MATTHEW HEUSSER: “Cambridge now.” I can’t do Dan Ashby. Given me time.

TIM OTTINGER: Americans cannot do Scottish accents ever. It’s a rule.

DAN ASHBY: “I’ll do an American accent.”

PARTICIPANTS: [LAUGHTER].

DAN ASHBY: Yeah. Dan Ashby, Global Head of Testing in a Services Team at AstraZeneca. Heading up a great testing team now, less of the hands-on stuff now, but I still do try to talk more about testing to customers and things like that.

MATTHEW HEUSSER: We have Claire Moss, who is local in Atlanta, at VersionOne.

CLAIRE MOSS: Hey, y’all. Welcome to my hometown. Was that Southern enough?

PARTICIPANTS: [LAUGHTER].

CLAIRE MOSS: If you want to find me on the Internet, I’m: @aclairefication. I’m an Agile Tester, that’s been in it for over a decade. That’s sort of vague, but also experienced.

MATTHEW HEUSSER: And finally, we have Tim Ottinger with Industrial Logic. Welcome to the show, Tim.

TIM OTTINGER: Thank you. I suppose, as of this month, about a 37-year veteran of software, having lived through the methodology wars and the case wars and everything else that’s fun. I am a consultant and a trainer and a writer, a hack and a small aquatic mammal.

MATTHEW HEUSSER: In CASE, if you didn’t pick up on that, it’s Computer-Assisted Software Engineering.

TIM OTTINGER: Yes.

MATTHEW HEUSSER Which was kind of a thing for a while.

TIM OTTINGER: Until we learned better.

MATTHEW HEUSSER: It didn’t work.

TIM OTTINGER: No.

MATTHEW HEUSSER: That was the only problem with CASE. Before we dive into it, is every single person here a speaker?

PARTICIPANTS: Yes.

MATTHEW HEUSSER: So, tell me the name of your talk and if you have slides up or you’re going to put slides up, and we will link to it in the show notes. So, Emma, what are you talking about?

EMMA ARMSTRONG: Dan and I are talking together, and we’re talking about, The Big Agile Communication Game, and we’re not actually talking about testing as such. But, great communication is pivotal to good testing.

DAN ASHBY: Yes. We managed to squeeze in a model.

PARTICIPANTS: [LAUGHTER].

DAN ASHBY: It wasn’t very heavily about testing, but we played some games and everyone had fun.

MATTHEW HEUSSER: Okay. And, Claire?

CLAIRE MOSS: We did two workshops this week. I was co-presenting with JoEllen Carter on Intentional Learning and then with Matthew Heusser on an Exploratory Testing and Hands-On Workshop.

MATTHEW HEUSSER: Tim?

TIM OTTINGER: Yes?

MATTHEW HEUSSER: What are you talking about this week?

TIM OTTINGER: Well, I did on solo which was, Agile Practices for Everybody in which we did a number of games to help people seat an Agile mindset and understand the context for practices that we discussed. I also did two “duets,” I guess, one with Brandon Carlson on, Unconventional Agility and Sacred Cows, and I also did one with Bryan Beecham on the first day which was about, Learning from Bad Examples, Why people program bad hypothesis because the examples they learn from are horrible. Nothing testing specific, but I certainly do work in testing and with testers and enjoy that.

MATTHEW HEUSSER: So, tell us about our RWBS.

TIM OTTINGER: Ah. So, the idea of the “real world” work that we do, anyone who has a job or has an occupation or even a hobby, there’s the real part, there’s the reason that we do what we do, the thing we get to do when we get to the office, the part we look forward to, the “real work” we will always dive into with gusto. Then, there’s his other stuff that you have to do so that people will let you do the “real work,” and I refer to that as the “bureaucratic silliness.” So, we draw this line. On the one side we write, “Real work (RW)” and the other side says “bureaucratic silliness,” which is abbreviated “BS,” and all people have to work with “real work” and “BS.” And the BS, you can tell from somebody’s behavior, because it’s the stuff they put off until the end, hoping they’ll run out of time and not have to do it.

DAN ASHBY: I was reading a book recently called, The Phoenix Project. In The Phoenix Project, they talk about four types of work, but I totally associate with you’re saying with that as well because a lot of it is silliness. Actually, in The Phoenix Project, I can’t remember what the four types of work were—changes was one.

MATTHEW HEUSSER: Planned and an unplanned, right?

DAN ASHBY: Yep. Planned and unplanned. It kind of was in each, four of those categories, that’s silliness. I think that’s something that I’ve definitely experienced, a lot of the bureaucratic stuff, especially in testing as well where it’s kind of, there’s actually, this huge debate going on about terminology and stuff like that. So, we were talking about, for me, I just don’t care what terms people use. I don’t care. It’s just the understanding that people have. There is a battle with some types. I find it easier being at the top of the chain though, and influencing down, rather than being on the team and trying to influence up.

TIM OTTINGER: I refer to that as, “swimming upstream.”

DAN ASHBY: [LAUGHTER]. Yeah.

MATTHEW HEUSSER: So, as a tester, what’s the “bureaucratic silliness” that you have to do? What do you think are some examples of “BS” for testers?

CLAIRE MOSS: I think one example would be recordkeeping that doesn’t provide value. Sometimes that manifests as test cases, which are overly detailed and easily outdated, but they’re manually maintained.

MATTHEW HEUSSER: Yeah. So, test case maintenance?

CLAIRE MOSS: Um-hum.

MATTHEW HEUSSER: So, I’ve worked with many teams, or at least talked to teams, that say things like, “We didn’t have time to maintain the test cases, and now they’re out-of-date. So, we just threw them away.” Kind of like, “What just happened?” And then, they keep working anyway. So, what value do they have? [LAUGHTER].

DAN ASHBY: So, one of the biggest challenges that I’ve had to face was when someone with this plain product and scrum master, and they pretty said that they, “don’t care about testing.” All they wanted was “minimal viable testing.” [LAUGHTER]. I almost died. I guess, face-palm. I don’t know how to respond to that.

EMMA ARMSTRONG: I think, for me, I’ve had the exposure where there’s the “real work” of providing the information to the team I’m working on, to provide them consistent information that they can show where we’re getting to and the progress we’re making, and then there’s the “bureaucratic silliness” where we have to do an extra run just to show management the fastest it can ever be at this moment in time, which doesn’t actually relate to the consistent metrics that we’re using to show our progress, “If you put it in a system with 100 machines, how fast could it ever run?” I don’t know that management actually want to see that, but that’s what I’m being asked to do and it’s taking my time out to produce something like that. So, I’m not sure it’s actually meeting a need, but it’s something that people think because they very rarely ask what data people want to see.

MATTHEW HEUSSER: So, certainly metrics that are hand gathered and added to a spreadsheet, I’ve seen. One company I worked with, we were supposed to gather these metrics. I forget what spreadsheet we were using, but it was web-based. You could tell who looked at it, and no one ever did. So, I just stopped filling it in, and no one noticed. And, Time Tracking. So, my contractors need to fill in their timesheets, so they can get paid. And yet, I’ve got a fantastic one, who is brilliant, but you have to remind him to do his timesheets. I’m like, “You know want to get paid, right?”

EMMA ARMSTRONG: I do like your one about spreadsheets because I work with actuaries who charge by the hour. I have to fill in the timesheets, even though I’m the developer who gets a fixed salary.

MATTHEW HEUSSER: Yeah. So, I don’t want to. Capex versus Opex, I don’t care. It’s not my problem. I just want to test software. So, that would be “bureaucratic silliness,” for me.

EMMA ARMSTRONG: But, don’t you think “bureaucratic silliness” also comes into our personalities—depending on the type of personality we are, the line’s in a different place.

MATTHEW HEUSSER: What blew my mind, when Tim explained it to me the first time, is that I have gone through periods where I’m demoralized about the work, where I’m in work avoidance, and what I’m doing is checking e-mail. The first thing I do in the morning is check it, trying to find an interruptive event that can make things different, to break me out of my pattern. The “real work” for me at the time was checking e-mail. Well, according to this model, yeah. Right? I don’t if you’ve ever been in work avoidance, but it’s not a good emotional mental place.

EMMA ARMSTRONG: Mine was revision avoidance, where my house was the cleanest it had ever been, so I didn’t have to study. You procrastinate and do anything but.

MATTHEW HEUSSER: You didn’t study?

EMMA ARMSTRONG: Um-hum.

MATTHEW HEUSSER: What were you studying for?

EMMA ARMSTRONG: My Master’s Degree.

MATTHEW HEUSSER: Oh, sure.

TIM OTTINGER: Well, in a lot of teams, strangely enough, and of course this isn’t about the line inside your head, that for a lot of people, the improvement is “bureaucratic silliness.” So, you’ll find people who they have the assigned work. You know, “We’re supposed to get some things done, but we’re also supposed to then improve, you know, internal coaching.”

MATTHEW HEUSSER: Your annual goal. Your annual goal to move to this way of doing things.

TIM OTTINGER: Right.

MATTHEW HEUSSER: To adopt TDD within the year.

TIM OTTINGER: Oh, we’re going to start doing BDD when we have time. We’ll do test first. We’re going to start doing Three Amigos Meetings after the crunch, someday, when we have leftover time that we’re not using for anything real. [LAUGHTER].

DAN ASHBY: So, here’s a question: Do you think a lot of the bureaucratic stuff stems from less understandings from the intention?

TIM OTTINGER: I can’t hypothesize it. So, the reason that I had brought this up was because I have realized that, as a change agent, my job is to take useful things from the “BS” aside and make them a part of the daily work, when I would write code and test it, which I still do sometimes. But, in the old days, when I’m done with the code, then I’ll write the test, and it tells you where the line was drawn. The “real work” was the code I’m going to deploy. The tests I write for the code are “BS” that I do so that I can write the code.

MATTHEW HEUSSER: Tim, being a programmer, for him, test means “unit test.”

TIM OTTINGER: Yes. It’s strictly unit test.

MATTHEW HEUSSER: I’m okay with using the term “unit test.”

TIM OTTINGER: Oh, and manual test. So, we have microtests that are testing lines of code individually. So, when I changed my life was when I went to TDD as a programmer. Now the testing is a part of the “real work,” and now it has power to transform my practice. But, as long as it’s on the right-hand side, the “BS” side of the line, it has no transformative power, and the trick is to move it, for each person, into the “real work,” any kind of an improvement, and that’s my purpose for that. And also, it’s self-knowledge, because I’m a long-term pair programmer, pair tester, pair ops, or whatever we do, pair coaching. I thought that I loved pairing on everything, and then I found myself—I looked back at my time for a week, and I realize I had put off pairing with somebody until the last two days of the week—and I thought, “Why did I delay that?” It dawned on me, “This particular work and pairing with this person,” I had pushed away from the “real work” into the “BS” side, and I wasn’t valuing that as a natural part of my work, which taught me, “Maybe I don’t believe as strongly as I thought I believed.”

CLAIRE MOSS: So “BS,” to me, sounds like a negative thing. Why would it be a great idea to move the “BS” into the “real work”?

TIM OTTINGER: Well, remember, it’s a mental attitude. Let’s say you have to do exploratory testing but you also have to do some regression testing, “Can we push the regression testing to right before we release?” “Well, yeah, if it’s not the “real work?” But, if it is the “real work,” if it should be the “real work,” then we need to move it into its correct place.

MATTHEW HEUSSER: So, you can say, “I believe that X has value, but if you’re not acting like it has value because, for some emotional reason, you’ve considered it “BS.” You’re acting like it’s “BS.” No matter how much you say it and you really believe it when you say it, “I know I need to do X, but I just don’t want to do it.” So, you can push it off. If X actually was valuable, then by pushing it off, you’re decreasing your performance.

TIM OTTINGER: But, on the other hand, there are things that we see as the “real work,” so I have, in the past, spent way too much time in marketing online things, when I had stuff to do. So, what I had done is I had put the wrong things in the “real work” side that probably should’ve been pushed to the “BS” side. It really wasn’t that important for me to do that, but I had put too much value on it. And, with work avoidance, you could say, “Well, my job is to be available and responsive to my peers right now. That’s the “real work,” because that other thing, that’s kind of bureaucratic silliness. I don’t want to engage in that.”

DAN ASHBY: And, that’s always going to be from your perspective, right?

TIM OTTINGER: Yes. Yes, individuals.

DAN ASHBY: Your bureaucratic, sort of, “BS” work might be someone’s really valuable, important thing that they need you to do, right?

TIM OTTINGER: Yeah. When that connection is tightened, then it becomes “real work.”

MATTHEW HEUSSER: I think we get this incongruence between what we really genuinely believe and how we act.

EMMA ARMSTRONG: Do you need to get team cohesion then on what’s the “real work” and what’s the “bureaucratic silliness”?

CLAIRE MOSS: I think that everyone will have a different perspective, sharing those might help us to determine what the teams’ “real work” is, but I think there probably are activities that are not equally valuable to everyone on the team or even everyone in the larger organization. I mean, why else would we think of it as “silliness”? Surely, someone wouldn’t ask us to do things that are silly and wasteful, right?

EMMA ARMSTRONG: Isn’t there an element that, some of the stuff we’re not actually, necessarily asked to do, we just think we are supposed to do them?

DAN ASHBY: It comes back to sort of what you were talking about with the spreadsheet online. I have a very similar story, where they were asking for test reporting via Excel, and I accidentally sent them a blank document and didn’t notice, and I noticed a week later. So then, I went back. I think someone might say, “How was that test report.” They were like, “Yeah. It was good.” I was like, “It was blank.” [LAUGHTER]. So, it was kind of like that felt like one of those tasks that you were kind of just talking about where it’s just ceremony because it’s been done for so long and it’s never questioned, and eventually, they’re going to question it. They’ll be like, “Oh, well, there’s too many words in it. It’s not useful for us anymore, but it used to be.”

CLAIRE MOSS: I think you’re right about establishing habits in a certain context and then not recognizing when they lose their value, when they become less appropriate, given the changes that have happened, whether it’s team disruption, or you take a consistent team and put them on to new work. All of those environmental things that made that strategy successful, might no longer allow it to be successful.

TIM OTTINGER: When waste takes the wrong side of the line, then you get functionaries, and a functionary has this function, and that’s the reason they live, “I update the spreadsheet. My job is to be the JIRA groomer, you know, or supporter. My job is to—” You know, whatever the case is, it’s wasteful, but it’s on the wrong side of the line. For somebody, that’s the “real work” and alignment is tough. So, you asked about the team, I think alignment is really crucial here, but if we don’t recognize where the line is, we don’t know that we’re in misalignment.

MATTHEW HEUSSER: There’s at least two things I see here. One being, if it actually is “BS” and it’s waste and we correctly identify it as “BS” and waste, we do it last, we do it to satisfy some weird stakeholder in an odd department who insisted that we create this report, sometimes you can just get rid of that stuff. You can go to management and, “How are you going to hit that deadline?” “Not doing this anymore.”

DAN ASHBY: So, to spend this around into testing, this is quite common, what’s a misconception around what testing. I’ve worked in companies where the people at the top have said, “Get rid of testers.” They would see what the testers do as being the “BS” work and then they’re trying to implement a strategy that’s kind of based on misunderstanding. If we don’t have alignment and we recognize that we don’t have alignment, there’s always going to be a problem with authority.

TIM OTTINGER: Oh, I hope not.

MATTHEW HEUSSER: Our “real work” is someone in authority’s “BS”?

DAN ASHBY: Yes.

MATTHEW HEUSSER: Is that what you’re getting at?

DAN ASHBY: Easily. Yeah.

MATTHEW HEUSSER: It sounds like. Emma?

EMMA ARMSTRONG: I think you also have the scenario where you could have two people in testing who have a different approach. So, one person believes that you can do session and charter-based testing to replace the traditional regression testing that was there, and then they have conflicting versions of what’s “real work” and what’s on the other side of the line. I think Tim making us aware that there is this line and it is individualistic and if we talked about, “Where is the people,” it might really help us have the conversation about why it’s defined there.

DAN ASHBY: Yeah. So, I guess what I’m trying to really get to, “Is it really a people problem?”

TIM OTTINGER: I think all problems are people problems.

DAN ASHBY: Of course. Yeah. But, it’s kind of, there’s always going to be a disconnect somewhere.

MATTHEW HEUSSER: There’s disconnects between people where, “What I think is real work, you think is BS.”

DAN ASHBY: Yeah.

MATTHEW HEUSSER: I think there’s disconnects within yourself where, “I seem to be acting as if this thing which I espouse as valuable, but I put it off as long as I can, what’s that about? How can I get it to be fun again?”

CLAIRE MOSS: I think that Tim mentioned that you’re framing information in your head about, “I categorize this as real work and not BS,” or vice versa and that determines part of my motivation toward it. But, you also do have that feedback of the actual behaviors and how they correspond to the thinking that you believed you had, whether you really are recognizing it or not. [LAUGHTER].

TIM OTTINGER: Yeah. How you actually vote with your time and it’s a very interesting thing, because it really is internal first. Most organizational dysfunction, I will posit, and I’m willing to contradicted, comes from misalignment and fear of misalignment, “Why is it that you must have permission to do your job?” “Well, because I’m afraid you might not be aligned with me and you might be doing things I don’t want you to do or for reasons that don’t align with my reasons. I want to get this project done.” You might be amusing yourself. That’s not aligned. So, what I’m going to do is, I’m going to put in rules that hold you in alignment, where the alternative is, by the way, that we can align, but that would require us to interact and know each other, which works great until you’re managing 5,000 of your least close friends.

CLAIRE MOSS: I think also though, in order to be in alignment, you have to be vulnerable and admit that you might have misinterpreted something. That may not feel very comfortable.

EMMA ARMSTRONG: At Lean Coffee this morning, Michael Tarter brought up, “What is the risk in being open?” I think it’s exactly that. It’s vulnerability. The one thing I said, I was asked to do some security testing once, and I just put my hand up and said, “I’ve just got to say security testing is not my forte. I can do SQL injection attacks. I can do a threat model. I can do a threat model, but it’s not my forte. It’s not my area of expertise, but actually admitting that, made me look like I was incapable of doing my job, rather than being honest that it was not my forte.

MATTHEW HEUSSER: Do you think people really took it that way? “Ooh, Emma doesn’t know how to do this check on this checklist. Of the 16 things, she can only do 15 of them.”

EMMA ARMSTRONG: Yeah.

MATTHEW HEUSSER: That’s too bad. I’ve worked in organizations where that would be, “Well, I’m really good at that. Let me help you.” Boom. Not many.

EMMA ARMSTRONG: [LAUGHTER].

TIM OTTINGER: I will acknowledge the risk, and as a consultant, I come into a lot of organizations and I have to admit that I don’t know their domain, and it’s been the most growth engendering behavior change of the past 20 years, but I have to come in and say, “You know what? I really don’t understand pharmaceuticals very well. I’m going to have to have a guide, and by the way, I’ve never really programmed in Scala before. How can we work together?” It’s interesting, though, because in that, you learn to model the vulnerability of it and the honesty of it, but it is brutally hard when you know that they’re paying a lot of money to have you here, that you have any deficiencies at all, it’s peeling off armor, and it’s very difficult.

CLAIRE MOSS: I would say that’s not just for consultants. I’m a new employee. There are lot of things I don’t know. I just taught a session on, Acquiring Skills and Assessing Your Own Ability, and I put a big slide that was tweeted, about how I’m new to DevOps. It’s something I’m interested in. It’s something my employer’s interested in. But, to admit that I don’t know, doesn’t feel great, except that I have hope that I can improve that.

TIM OTTINGER: This is a really great place for me to mention that this isn’t something that’s rigorously studied, this “real work” to “bureaucratic silliness” line. This is really more like observational humor. There is no study behind this. There is no science behind this. It does seem to have both explanatory and predictive value, but there is no rigor. So, this idea we’re discussing is just an idea, and I want to make sure that you know that. That this isn’t me as a scientist delivering something that’s well studied and known. This is us kicking around and riffing.

MATTHEW HEUSSER: Tell us about relevance ratio in the time we have left.

TIM OTTINGER: Oh, okay. So, this is another bit of observational humor, [LAUGHTER], about developers, but it was interesting to me to see that some people, when they’re in cubicles or offices, are miserable beings, and they love an open floor space. And then, you get people who are in pods or open plan, and they’re just miserable. And, I started wondering, “None of these people were wrong, and I believe in placing curiosity above judgment.” So, I started off with, “Well, those people are wrong,” and then I recognized, “Oh, that’s not curiosity.” So, I started digging in. So, here is my theory as observational humor: There is a relevance ratio. So, you take a look at the total amount of information around you—conversations, pictures, scrolling screens, etcetera—and then that’s the denominator. The numerator that goes on top is how much information relevant to the job you’re doing right now. If you were going to try and sit down and do some really good test strategy and really get a good assessment of a user experience in the middle of the keynote conversation, yesterday morning as everybody was clapping and cheering and laughing and being shocked, that would have been harder. It would’ve been harder yet to do it in the hallway with everybody passing by it because most of the information is irrelevant. So, to bring this back to my original case, if we’re sitting in a pod and we’re all doing work together, it’s almost idyllic, but if we all do solo work, then silent offices are almost perfect. The information flow and the relevance of information matches to the job we’re doing. On the other hand, if we have cubicles and we sit with people who are also testers but they’re not testers on our project, the relevance is low, but the information is high. It’s a dystopian environment. So, it’s really about if you’re with your peers, with your tribe, or if you’re away from your tribe.

CLAIRE MOSS: So, I think, to restate this, it’s about signal to noise.

TIM OTTINGER: Yes.

CLAIRE MOSS: “Which part of it do you need to know right now?” And, that may change over time. What I find is that, if I am in a shared environment, opportunities arise that I didn’t anticipate. So, if I have irrelevant information at this moment, and yet it’s there, I may pick up on it and change what I’m doing to find out more about this information that didn’t seem important until it was available to me.

DAN ASHBY: I totally agree, and I’ve got a prime example. When I used to be the sole tester in a company, and there was a lot of developers. A lot of the time, I would test and I would eavesdrop on conversations. So, because people hadn’t really worked with a tester, I was their first tester, and I was their only tester, they would tend to leave me out of conversations and meetings. But, their conversations were around the desk, so I could just get involved anyway, right? If that conversation was taken into a separate location, it would be much harder for me to get involved. As part of the eavesdropping, I was able to point out some assumptions they were making as part of discussing the stories and things like that, and then eventually, they discovered the value in inviting me into the conservations. When they took on more testers, they got invited straight away because they saw the value of having them there. But, working in silos, like having the cubicles and things, I think I would really struggle with that.

CLAIRE MOSS: It sounds like you were trying to get a literal seat at the table.

DAN ASHBY: Yeah.

CLAIRE MOSS: And, in order to do that, you had to know what was going on around you that hadn’t been directly—your presence hadn’t been—requested, but you saw that something was going on and you had the option whether to join in or not. So, sharing that information about when communication’s happening is an opportunity to make a decision about it without necessarily inserting yourself.

EMMA ARMSTRONG: I’ve noticed a slight side of that, though, is people’s personal preference. So, I’m a people person. I will get up and walk, even up stairs, to talk to someone, because I would rather talk to them. However, we have people in our office who might be working on their own at that point or they’re working on something what they deem is “extremely complicated,” and therefore, they want to get into the flow and any noise from any of us around them absolutely irritates them to the extent that we have now a separate office, which is a “flow zone” that people can go into. One of them sent an e-mail one time saying, “I decided to work from home for the natural quiet, and I know I’m one of the culprits. I’m one of the laughers in the office. But, for me, if I don’t have that eavesdropping, I can’t keep up with the guys, but it’s almost a fine line between rudeness. Someone will say something and I’ll turn around and say, “Oh, that’s that,” and speeds up the solving of a situation. But, it’s close to being rude, because you are eavesdropping outside your conversation zone.

DAN ASHBY: I’m keen to hear your perspective from a developer point‑of‑view, because I work with a lot of developers that stay away and kind of have headphones on—right?—and want to be in that silo, but most of the testers I’ve worked with want to work in a group. Do you see a difference that in the testers that you work with compared to developers?

TIM OTTINGER: One of the things that I have a tendency to do is I tend to teach pair programming and mob programming. I am, first off, an introvert with a big-capital I, in bold, and italics, and possibly in a separate font.

PARTICIPANTS: [LAUGHTER].

TIM OTTINGER: But, I have recognized the value of working with people in groups. Now, if I’m expected to do solo work, then flow requires me to get rid of all of the distractions because I also have a hummingbird brain that will flit from flower-to-flower. So, I have to lockdown if I’m going to be doing solo work and I really got to get it done. In fact, my solo speech, I had to reach some serious isolation to really go through my solo talk, and then I had to come out and vet it with people. So, in that flow, you’re starved of signal, other than one thing. So, the focus is really great. When they go put the headphones on, they’re in a different room, and they’re in their own headspace. But, I find that solo work is just generally not a good idea. It’s almost never the right thing to do. You want solo work when the outcome depends upon it being your personality and your voice, which is really not the case with programming. Programming is something that we write to each other. On the other hand, people have expected programmers to be cats, so they don’t really collaborate. They don’t really interoperate. Each one does its own thing. They couldn’t give a fig about each other. They’ll fight over food and toys. I think that expectation has developed a generation of programmers that haven’t yet learned to collaborate. So, my answer is, “No.”

EMMA ARMSTRONG: I’ve found it interesting over the years working with predominately academic coders, and we were talking the other day, there’s different types of developers in the sense that you’ve got the software engineers, you might have the architects, but sometimes you do have the programmer/coder, the academics, who believe that they’re trained to work solo, but only in academia. And so, having done their PhDs, etcetera, that is what is learned behavior, and getting them outside of that is much more tricky than when the new graduates come out of university, etcetera. They’re much more open to the mobbing and the pairing and actually getting people involved.

TIM OTTINGER: So, it’s almost as if working solo has taken an ethical dimension there, because you do your own work and you get your own work done, and when it takes an ethnical dimension, that moves being alone to the “real work” side and interacting to the “BS” side.

CLAIRE MOSS: That may be a factor in the academic setting. You’re being evaluated individually. So, if you’re doing primarily paired work or you’re achieving flow with others, how do people look at your performance? So, that kind of goes back to assessing productivity.

MATTHEW HEUSSER: So, who’s speaking at what next?

TIM OTTINGER: Agile Iowa, introducing.

MATTHEW HEUSSER: In Des Moines?

TIM OTTINGER: Yes, in Des Moines.

MATTHEW HEUSSER: I will be in Des Moines.

TIM OTTINGER: I will be introducing Modern Agile there.

MATTHEW HEUSSER: I will be talking about Agile Testing there.

EMMA ARMSTRONG: I have no more commitments this year.

CLAIRE MOSS: Congratulations.

DAN ASHBY: Harbinger Model. You need to go up and do that.

EMMA ARMSTRONG: Yeah. My session got picked for Open Jam on Quality Testing As a Service.

DAN ASHBY: I think I’m free until September, and I’ve got my first keynote. It’s at the National Software Testing Conference NORTH in the UK, and there’s a few old school main techs. So, my talk is entitled, How Ignorant Are You?

TIM OTTINGER: And, I just remembered, I’ve just been accepted for Lean Agile Scotland. So, if you’re going to be there, I will see you there.

DAN ASHBY: Yeah. I’ll try to be there.

CLAIRE MOSS: In September, we have the Stack Conference in Atlanta. So, I’m onboard there, and I’ve anticipate doing a workshop.

MATTHEW HEUSSER: If you listen to the show a lot, you know that I’m all over the place. You know where I’m going to be. But, we’ll be coming back in two weeks to do another podcast. Thank you guys so much. I owe you one. Have a Hershey’s Chocolate Bar.

EMMA ARMSTRONG: Thank you.

MATTHEW HEUSSER: I really appreciate it, guys.

EMMA ARMSTRONG: That’s great. Thank you.

TIM OTTINGER: Hershey’s needs to call you. We’re looking for a sponsorship here.

PARTICIPANTS: [LAUGHTER].

MATTHEW HEUSSER: Our real sponsor is QualiTest. We don’t talk about them enough on this show. They do a lot of fantastic things. Check out the website. They’re the reason this show is here, and if you have staff-aug needs, they’re the number one Pure Play Software Test Company, and I endorse their work. Thanks.

DAN ASHBY: Cool. Thanks.

CLAIRE MOSS: Bye, y’all.