S3 E6 - Mike Harris - Profound Testing
This episode features Mike Harris, a Tester at Geckoboard who self-identifies as a Tester. We discuss how vital Dr. Deming's ideas are to testing, especially around the System of Profound Knowledge, with Mike, who has worked in testing for 20 years. It is another example of Dr. Deming's ideas' relevance in the modern era. You can find Mike on LinkedIn below:
Resources and Keywords:
Mike Harris's blog: tested analysis (Wordpress)
Mike Harris's Twitter: @testandanalysis
Books mentioned:
"Testing Stories" by Mike Harris
"How I Could Test That" by Mike Harris
"The Goal" by Eliyahu M. Goldratt
Deming's works:
"Out of the Crisis"
"The New Economics"
Concepts/methodologies discussed:
Deming's 14 Points
PDSA (Plan-Do-Study-Act) cycle
PDCA (Plan-Do-Check-Act) cycle
System of Profound Knowledge
Red Bead Experiment
Ishikawa diagrams (also known as fishbone diagrams)
Five Whys (Toyota)
Operational definitions
Organizations mentioned:
British Computer Society (BCS) specialist interest group in software testing (SIGIST)
DevOps Research and Assessment (DORA)
Toyota
John Willis's book: "Deming's Journey to Profound Knowledge" (mentioned as being written by the speaker)
Transcript:
John Willis: 0:02
Hey, it's John Willis again. And it's another profound Deming podcast. And I found another sort of Deming, eight out there, you know, just trying to find everybody that just wants to talk about Deming. So, Mike, you want to introduce yourself? Okay. Hello, my name is Mike Harris. I'm testing professional, I work for Decker bolt in London.
Mike Harris: 0:24
I'm also vice chair of the British Computer Society specialist interest group in software testing, which we call sugest. It is much shorter and simpler. I've contributed a couple of eBooks about testing. First of all, testing stories, I mentioned Demick. Had I could I test that, and I have a blog, which I've regularly write about them in as well.
John Willis: 0:52
So that, you know, I think only once I got called out for asking this question, so I think I'm going to stick with it until I get called out twice. But I find him a lot of people have a damning moment. You know. And so and it was for me, and most people I asked, so like, so what was your sort of damning? Like what was sort of like the moment like my moment, it was like I had a moment. And in fact, for me, there's always these moments like, wow, really talking about a tell me your sort of your background about like, why you got interested in Deming, why you passionate about him, I was
Mike Harris: 1:29
tested at a startup in London, we were moving to an agile transition with a couple of Scrum teams, no Kanban team. So I was managing testers and part of the management team for that. And just decided to find out a lot more about Lean agile, actually, all the management data we studied, and we read, we had an Agile coach. And then he kept coming up in all the books I was reading, is this plugged me? Okay, so who is it? So I read more about him, and just found that his philosophy seems to underpin everything that we were trying to do. And what we did was successful as well. We got a successful exit from from that startup. So that made me think, well, this works. And that's really where I became, that was my Deming moment. That's how I became very sort of very interested in deadening and has continued to explore his work ever since.
John Willis: 2:30
Yeah, no, I, you know, I thought it was fun. I, you know, you I guess you were talking about sort of, uh, you know, I've heard this. So I have gotten to know Elizabeth Hendrickson, you know, she's another sort of agile testing, you know, and she was, in the early pockets. They were some of the early, Agile and Scrum advocates for you know, we're basically also pointing out Demings work, and I started, I think it was your one of your blogs, we talked about Chet Soglin and Scrum.
Mike Harris: 3:00
Yeah, that's right.
John Willis: 3:03
Do you go back to some of that early stuff? The, I guess one thing I saw is you you it looks like you run the red bead game.
Mike Harris: 3:13
Yes, this is about it. I've never actually run it, it'd be an interesting thing to do. But I've written about it a few times. Yeah.
John Willis: 3:22
What are your thoughts about it? So in general,
Mike Harris: 3:25
I think it's, each time I write something about it, I see something new. I think it's really interesting and useful, because you can talk about a whole range of issues without it being somewhere that you've worked, or your friend works. So it's very handy in that way. I think it brings out issues where people feel powerless at work, they're held responsible for things that they can't control. Just one of the essence of it. But also, the other essence of it is that people feel that that because they're managed rather than lead. So there's all sorts of issues you can deal with that. The first thing, that second thing I think I wrote about it was actually, what should you do with the inspectors, or the test team in the red beads? Because they don't add any value? They're telling everybody well, actually, you haven't done what they've met your target? Well, they can't meet their target. So actually, what could you do with them, and they've got a lot of skills. So there are useful things that they could do. And if you look at other parts of Demings philosophy, he talks about how you need to be working with your suppliers to improve quality. So in fact, what the big issues with the red beads is in fact, they're supplied a mixture of red and white beads. And if the inspectors were to use their skills and work with the suppliers, then they could improve the quality of supply of red beads and they'd be less white beads in there. And I was like, let's read the two more white beads in there. And that would help people improve the quality of their work. So there's that I think there's all sorts of things you can do with the records. I think, then we had quite a number of different lessons you could learn from it.
John Willis: 5:22
Yeah, no, I agree. I mean, I, I've, you know, I've been thinking a lot about, like, I saw your article, and I really liked it. And then I thought about, like, you know, I've been, you know, really so So I finished my book, right, like, 10 year journey, but now you're really two years of serious, you know, it's called Demings. Journey, profound knowledge, where I really try to tell a story of how he picks up profound knowledge. Right. And, and, you know, is a big part of it, but they're all in knowledge variation. Yeah. And systems. The thing I thought about it after your article, I was like, this is really cool, right? And then I said, you know, I immediately had this, like, what if Devin came back today, Dickie be pretty upset, that like, guys, like, that was the game when I died in 93. Like, you didn't like expand it at all. And he does leave some breadcrumbs, like you said, where he says, you know, you know, possibly when you realize that, you know, that, that it is out of the control of the workers. It's in process, basically, you know, he says that, that would be a time to go back to the suppliers and stuff like that. And, and I think, like, a modern version of this game would be to stop it like the fifth iteration, and then have like, a post mortem. And then have, you know, sort of, like you said, the testers are, you know, they're, they're, you know, we're assuming they're just willing workers, but like, in our world, typically, they're very sort of valuable people that run. Yeah. And like, everybody has stepped back and take the system view and say, you know, what, we've got, like, two resources that are not being utilized properly. Yeah. They basically be sort of involved in just some other sampling or, you know, like, yeah, to do that's what you're sort of saying, right?
Mike Harris: 7:17
Yeah. Building quality in covers from Deming. And so one of the ways you could look at building and is working more closely with your supplier, I think the article I mentioned the four parts of the system of profound knowledge, and how you could you could better could lead you in that direction, and support your decision, because you need to live in that variation. So actually, that would be one of the things that you'd be measuring, you'd need to look at psychology, because you've got some inspectors who presumably feel good about what they're doing. And they've been doing it for a while. And you're actually thinking, well, actually, you would like them to go and do something else. But so there's this important part of psychology there. There is this part of systems thinking as well, that actually read beats company, it won't these company is not an autonomous system. So actually, they've got a look at how they work with other systems, such as their suppliers. So there's, there's always so much there. So much, so many different directions, you can you can go in and what I've tried to do it with each thing that I've written is just take an aspect of the red beads so that people can see that that's useful, or this is useful.
John Willis: 8:38
Good. And so if you're testing, like how do you find sort of Deming philosophy, you know, sort of work its way into, you know, the, what you do on a daily basis, or how you help customers? Any good examples there?
Mike Harris: 8:56
I'd say one of the interesting things for me recently was this theory of knowledge, actually, because perhaps the most commonly used testing technique, boundary value analysis I've used, and I've got a pat on the back, so that was good. But actually, when I got involved in a discussion, I realized I'd use the technique incorrectly. And if I hadn't had a theory as to how to use the technique, I wouldn't have had something to theory to revise, I wouldn't have learned from it. So I think that that was something there that I've learned from just recently. Initially, I was very interested in the Deming Cycle, but actually, the system of profound knowledge has become far more interesting. I think more recently, I think I was interested in the Deming Cycle because working sort of both a football team making a monthly release and then the transition to work. Getting into teams working iteratively is huge. And you could just see the benefits of planting steady X was you weren't able to do in a waterfall months he released. So this was, that was my initial game. But it's saying that as testers, you could say, well, we've got a problem here. Why can't we do that and learning from what you were doing. But just just recently, the same with serious knowledge? I think it's very interesting. I'm going to post something about it next week.
John Willis: 10:34
Yeah, no, I think, you know, the, I think there's the whole PDSA in the history of PDSA, I think it was a run Mo, and I know you did something about this, the history of PDSA, and it's sort of fascinating from where it starts from sure it then it goes to sort of, you know, Japan, and then it's sort of called PDCA. And look at the whole history. But the thing I've thought a lot about is how do you meld the plan, do study act with the profound knowledge. And I think there's a mapping that works, right, which is the, you know, the planning is really that, I think I've said this before, but I think that the more I've learned about the system, or found knowledge arts, so just I think anybody who's listened this far in a bike as knows what it is, but it's theory of knowledge, theory, variation, theory, psychology and appreciate it. And I think that, you know, there should be an order, you know, and I, like, I'm still sort of, like, convinced I'm right about this. But I think the order is, you know, the theory knowledge, which is, how do I know what I think I know, you know, back to Yeah. And then the, and that's the plan, right? Yeah. And then the sort of do is? How do we like, check or verify what we think we know, right? To doing the sort of, you know, and a lot of ways it's the theory of variation. And he's more than you see, it really is analytical statistics, like, you know, how do we sort of use the statistical analysis to tell us, you know, where we're gonna go to sort of figure out the problem, and then your study, then is your psychology and systems thinking? Okay, right. And then your act is like, what you've learned and what you what, what sort of decision? And I think in that case, that the theory knowledge and PDSA map very well. And because you're always starting off with this, sort of like this, you know, this piston logical question of like, what what is, you know, what do I think, what do I, what do I think I know, right? And then you're sort of going through some process to that. So I think they both were very consistent. And, you know, and I think if you take your sort of boundary you to go boundary plan analysis, or boundary value analysis or value. Okay, cool. And if you take that into your example, basically, you had, you know, fortunately, you didn't just do it, you had a theory of what it was going to do, you use some type of a type of analysis, to figure out what it what was the, you needed that to sort of be able to then study the analysis and study, you know, you, you know, depending on what you needed to do, and correct me or add to this, but you, you know, at some point, depending on who you are interacting, what the motivations were, what your inner inner relationship motivations, were you, you had a psychological lens, you play the sort of system thinking, like, is what I'm about to do gonna, you know, just improve a local improvement, or it's gonna. So, yeah, I think that's pretty cool. Yeah. And I think just looking at some of the other stuff, you, you talk, I did write about continuous delivery and continuous deployment. And I guess, in general, tell us a little more just about like, the, I think this is worthwhile. Anything more on Deming, but like, what should we know about? It sounds like, you know, I've had a couple of people, Adam Hawkins, and like I said, of Elizabeth, and I think a lot of people in DevOps don't really making an assumption based on me, we don't really understand there's true strong history of people who've been doing testing for years. Understand a deeper discipline than just that testers. You know, the early days of DevOps was get Devon ops together, and then he like, oh, well, now we got to go get the testers, the QA people to come in and write and write, like, okay, and seem like it was easy to get the QA people in, then maybe the network and hold on Wednesday. Okay, right. Yeah. Because because, you know, I'll say you you guys got it. But But I guess the long version of my question is, what is sort of the state of the art of testing or what But you know, what should we know about the the world? You know somebody who's it's your craft events?
Mike Harris: 15:08
Yeah. And I think it's a good question. I think that testing is about constant learning. It's about having a wide range of skills. You know, there's talk about T shirt, T shaped people, I've just been reading a Chicago, he talks about cone shaped engineers or well shaped engineers. And actually this range of skills that you got your central skills here at tastic. But actually, you can do lots of other things as well. You can write SQL, you can write some code, you can have opinions on design, you can facilitate meetings. So if you've got a range of skills, and you've always got to be interested in developing those skills, I think one of the key skills is thinking critically, because you're going to be looking at it and saying, how would that work? I think there's an also an important thing from looking at things. From a customer's point of view, there's a range of skills, things, techniques, you can do that, I think quite interesting in theory of jobs to be done, which is something we use a Geckoboard. I would say that there's, I think interpersonal skills are really important as well, because you think you're giving bad news, you know, so actually, psychology is very important. So I think that's, that's really very important as well. But I think it's about continually learning. And I've been working in testing for 20 years in a range of different roles. And I'm still learning. And so I think that's really important. And I think for me, one of the important things to learn is, is actually to go back to the greats like like Deming, and the learning from them, because if you're not working on a plan to study act cycle, as a tester, you're going to have a problem. But you've got to plan a test, you're going to execute the test, study the results, and then act on the results. And I think it's really good to see things in that way. You're also looking to build quality, and you're not going to be the bad guy that comes along at the end and says, Oh, no, you can't ship it. You actually, you want to be working with the developers. So that actually, when it's ready, it can just go, you know, this is the sort of thing that you're trying to learn, I'm trying to learn from Deming. And that he helps us in so many different ways, initially, sounds very interested in the cycle. But then you found the applications of systems thinking and things like wanting teamwork across the company. That's really important. Because actually, you need to be collaborating with the developers, with the designers with the product owner, with customer support. That's all done. So the what the, the importance of things like driving out fear, for a tester, that's really important. Because if we can't ask naive questions, sent in facts, or difficult questions, it, it's going to make our role very difficult. And it also thinks it makes it far more difficult to ship quality products. This is, again, something that Dan said, so I said, okay, yeah, there's so much here. And each time I look into something, there's more and more, you know, remove the barriers to what he called good workmanship. Well, actually, yeah, that's really important, isn't it, you need to feel good about what you're doing, you need to be treated well. There's all sorts of things you can apply that to there. One of the things that occurred to me that actually that if your development team hasn't got any women engineers in it, perhaps you're missing out on some fantastic engineers, and actually not having women engineers is a barrier to good work. And again, I would say if you've got women engineers in your team, and they feel they're not listened to. Well, in fact, that's another barrier to good work, because you're missing out on some fantastic engineering.
John Willis: 19:06
No, I think there, there's so much there, right, like the psychological safety, you know, sort of aspect of, you know, just and I agree, I mean, it was a great document in our categories, where they, they really showed how diversity sort of like, especially in sort of marketing, engineering, or engineering or product ideas and stuff like that. Having all male, you know, like, it was just missing incredible opportunities. But yeah, I mean, there's no doubt diversity adds, you know, you know, I would say exponential value, but like, but certainly more than just linear value, but yeah, and I think the other thing I love that you talked about, like, early on when I was trying to understand the system found knowledge, right, like, you know, variation like you can, you know, like you spent a lifetime because there's tons of information for manufacturing there and you can sort of learn there are layers to it that that you know, as you get deeper and deeper, theory, knowledge was a little bit harder because I had to go back and really figure out like, where he got his, you know, you know, he mostly a lot got a lot of that from, you know, sort of pragmatism and early philosophy. And it's just some thinking again, there another just, you know, once you realize he, you know, when he said appreciation system, somebody asked a question once, like, I wonder why he didn't just call it theory of systems thinking, right, but like, there's some theories that maybe why I think he figured that everybody already knew, like system thinking, but that's a damning thing. But serious psychology was the one that so I struggled with, to really get beyond just cliches, you know, intrinsic versus extrinsic, we're done. But so I love when you said that, like, you know, a part of a theory, psychology in your work is, you tell people bad news. They the sort of empathetic transaction that you're going to have to sort of figure out from your side and their side in, like, in fear, drive out fear. That's, that's what's like, we're all like, can we do we feel depending, you know, sometimes I feel like, you know, I'm the guy that speaks around the world. And I know this, and I know that, but then you put me in a sort of forum where there's, like, you know, a bunch of PhD people. And I'm like, you know, I know, I have a question here. But like, should I, you know, like, we all have that sort of thing, and you write it, it reduces quality in any sort of scenario where we don't, you know, we're like, we just don't feel comfortable. And some people just make you feel comfortable, right, but, but just don't know, the comfort level that people you're with.
Mike Harris: 21:44
It's also very interesting in that I raised this when I speak at conferences about any testing conferences, because there's been a discussion last couple of years about the importance of psychological safety. And so when I talk about Demings, 14 points, I say, try that. Well, we talk about this now, the psychological safety. What are the points stemming says it's the managing management will struggle over every one of these 14 points. And actually, the fact that he wrote this book in 1982, I think he first spoke about the 14 points in Tokyo in 1978. Well, actually, we're still talking about the need for it now shows that struggle. And I think that one of the interesting things about the 14 points and what the point I'm trying to make there is actually, you can see that struggle there. And actually, you can D personalize it. You're not sort of saying actually, that's about my manager, actually, this is about a longer issue. It's about education, it's about leadership. And in fact, that's a far easier way to deal with these things. And if you're feeling frightened at work, then in fact, you know, it's not your fault. You know, it's actually it's an issue with leadership. And I think that makes it far easier to deal with. The first time I spoke about this, someone came up out of the audience afterwards and said, you know, we have a climate of fear at work. And that was a real tragedy. Because for her for that, in that particular developer, that was a real tragedy. For the whole team. It's really bad for the whole company, it's really bad because they're going to be shipping, poor quality works. And for the company's customers, it's really bad as well. And actually, because of the way Deming deals with these issues, you can see it in that context. And as an individual, you shouldn't feel bad, you shouldn't feel threatened and you shouldn't feel it's your fault. It actually, you know, that it's an issue to do with leadership.
John Willis: 23:45
Yeah, absolutely. You know, it's, uh, you know, one of the things when I first read new economic or non economic far out of out of the crisis, I thought, Oh, this is gonna be great. Well, you know, for me, like I've said this many times is we were in a DevOps open spaces, and I had read a whole bunch about the Go rat, and a goal and, you know, Jean, he sort of forced me and forced me to recommend that I read the goal before reading the Venus Project. And then we were in open spaces and Ben Rockwood basically said, John, it all goes back to Deming, and I'm like, Come on, don't just throw another name on my plate, you know, and, and he said, Well, do me this favor, go sort of look at Demings 14 points. I did and I'm like, holy crap, this could be a DevOps presentation. You know, this is, Deming said I love where he is. This guy did this thing this morning for Dora metrics, you know, operational definitions in which and let's talk about that in a second. And, you know, the people were talking about, like, you know, like, there's always thing comes up about management and how we can get it right and leadership and I just said, you know, like Deming said, like in the 80s, you know, the tyranny of the prevailing style of management, you know, like, you came today sit and go, yeah, it's still the tyranny The prevailing style of management, right? Yes, yes. Yeah, we, I think we struggle. You know, and I don't know, like, you know that my other sort of pet peeves is why I get excited when I see somebody like you and sort of software domains of like really understanding and taking them and stuff. Because, you know, you know, I know I'm down the rabbit hole, but like, I just think, in our industry, we should we give it a try, because it's, the stuff has been around for 100 years. It's used in nuclear power plants, it's been used for creating posters to cars, you know, and we just somehow ignore this level of operational science in our in, in our domain.
Mike Harris: 25:43
It's what drives me to speak, that drives me to write, because my understanding is that these ideas largely come out of the, the bell telephones in the 1920s, when Bell telephones were creating, what was the first national telephone system for the United States, this was a huge projects that actually brought together 10s of 1000s of people, all sorts of people. And they learned to not fall off. Shewhart was fair, Deming was there Duran was there. And the lessons I learned from that aren't taught in computer science courses. I know a tester who's got an economics degree, they will have their economics course. I think sometimes it comes on an NBA. And so actually, my life as a tester, or the life of other testers is so much better. If we actually understand the lessons that came from that time, the timeline that you've identified of Denning, Toyota lien child, the good stuff comes out of, you know, comes out of that timeline, history of ideas. And I want to share that. So that's what that's what's been motivating me to do what I've been doing. And aren't if our life is better as testers, actually we're producing better quality work. They're producing better quality products. So there is a relationship there. And I that that's what really motivates me to do it. And I think it's a great shame that people, these things aren't covered in computer science courses.
John Willis: 27:24
I think computer science, you know, I think I was talking to Mark Burgess, who is one of the pioneers of infrastructures code. And he I was visiting with him last week, and he said, The rumors of science and computer science are greatly exaggerated, you know, you know, like, the, you know, if you think about, like, it sort of drives me nuts, when I get invited to a university to talk to like the professors about their curriculum, and I see that it's really sort of two worlds. It's like, like, what's three, it's like, classic, you know, like, compiler design curriculum, or some of the better engineering schools are doing, like, preparing their kids to go to like Google or, you know, like, really sort of distributed computing. But that's incredibly advanced. And it's a small subset of what people are going to do. Yeah. And then the, the, the only other sort of discipline really is, is sort of the IT business management, which is basically 90s, right, Oracle, and, you know, and I look at the industrial engineering degrees, or some of the supply chain, and they're all over operations management. And, you know, some of them focus on Deming or some of them just take the aggregation of all these ideas and, like operations research, but, you know, again, it wasn't just Deming, right? There was like you said, Duran it was sure there was there was a lot. It was Bell Labs, it was Toyota. But the point is, like, you know, make me king for a day I would have you know, you have the E you have the IE right? Why don't you have like an SC you know, software like that is it falls under the same like you take all the same classes that you take for industrial engineering. Last year is all software composition are and we would you're right, we just are. We're not we're just not kids get a lot of people I know in the Dallas community, like they'll actually try to hire a supply chain. Sort of IE student before they'll hire a computer science student. Okay, yeah. You're more likely to have this kind of skills, the Agile the lean, yeah, than they would if they're sort of been doing like advanced, you know, sort of distributed computing or CAP theorem, rasp whatever, ish stuff right?
Mike Harris: 29:49
One of the things I found is that when I introduced this vitals for first time, people said oh, you're going to talk about software there. Well, actually, no agile didn't start with software. Okay, so people tend to think well agile starting with a manifesto, you hear someone say, well, well actually, NASA put astronauts on the moon with waterfall because it came before the, the Agile Manifesto. And actually, well, these are important bits of understanding of how, what what Agile is, because there was so much of agile in place before the manifesto. But the Plan, Do Study Act, I failed it. That's why I talk about the history in that way. Because I think it gives people a deeper understanding. The same with Lean, I feel the need, I found the need to introduce and say what Lean is, because again, people think it's some kind of software theory. Whereas actually, we all know it came from Toyota. And in fact, it these things aren't covered under degree courses. And I think it's a bit of a problem.
John Willis: 30:57
Let's try to do in my book, right, I really made my book more of a journey than a biography. I mean, you know, it's my first sort of book that I've written all by myself, which, but so, you know, one of my best friends who was my first reviewer of the book, you know, I, you know, he told me, I had way too many stories, because my goal was to write Michael Lewis version of the demi story, or the or the Bill Bryson. And I think I've gotten reasonably close. But even this best friend of mine would say, John, you're not Michael Lewis. Point taken. But what I tried to do is, somewhere along the way, I realized the story needed to be about this man's journey of understanding profound knowledge. Like, where did he get the pieces from? So like, you know, you know, like, I think you just mentioned Ishikawa and I definitely want to talk to you about him. But there's so much more than just sort of the sort of Deming to Toyota to lean to agile, right? There's literally, you know, pragmatism or epistemology, right, which is the core of their knowledge there is, there is, you know, sort of operational definitions, which I'd like to squeeze in, which comes actually from, you know, mainly from a physicist in physics, right. Right. And, you know, and then you have, like, sort of what happened in Japan, you know, like in between Deming and Toyota, right, like Ishikawa to Gucci, right? Like all this stuff, right? Like, if I look at these college curriculums, they're like, my son's taking, he's in his sophomore year in a supply chain, you know, and he knows, he knows everything about Deming, and he's in his mass lecture hall. And, you know, he's out about, you know, five or six weeks into this, you know, supply chain one on one or whatever. And he called me up that night dad, my professor mentioned, Dr. Deming, you know, did you say anything? And he's like, No, I was a lecture hall dad, you know, so but, but I mean, like, I don't even know, to the extent they really get the narrative. You know, the way like you and I would think, okay, like, if they asked us, you know, hey, write, of course, that you'd need to know, because everything you want to know, for sort of, you know, I'm assuming that you, you'd be like, how do I prepare future testers. In a world where I could create, these are the things I would teach him, I think those would be the same. That would be a sim curriculum that I would want to be part of like what I do from sort of management theory, or DevOps or dev SEC ops or IT risk, you know, put all that together.
Mike Harris: 33:37
I think it's also very interesting. One of the things I like about them, is that it's not a big man theory of history. He's not the Polian of quality by himself, actually. And I, I think the fact that he brought brings in ideas from different people, he refers to Shewhart, as the master of this, actually, there, there is, I think, an element of humility in that, and I think that's good for us all. And that the work you've done in looking at the background or all the different ideas, I think it's absolutely fascinating.
John Willis: 34:15
No, I love that quote, he's not the Napoleon. I mean, one of the things I you know, I quickly came to conclusion, especially in all the things that happened, Japan, the complexity of the people who went in first before damming how Deming wound up there when Japan came in, what did use like Isha cower, and then what happened there you know, what was going on with statistics before damning got there, right, like, and so the first thing like I wanted to be like crystal clear in my book, which was, Deming did not create the miracle in Japan. Japan created the miracle in Japan, right? Yes, yes. That's why I love you like Deming is not the Napoleon and he did. He was incredibly humble, you know? On this, just everything you know. Yeah, I mean, it's just story after story of like, it's why the Japanese loved him. Right? Came in this gentle giant that was so wanted to understand their culture. He said that the the juice, the statisticians, the engineers were the best students he ever had. Wow. So he just like they loved him. And he loved them. You know, it was just so you said, I love that. You know, I've been really trying to go back and build this, like, interesting sort of, you know, sort of, like graphic timeline of all the influences and Isha College. Such a deep role in. So, so it sounds like you've done some research on Ishikawa.
Mike Harris: 35:48
Yeah, I came across it, because I was looking at different ways to carry out root cause analysis. Okay. And I discovered the Ishikawa diagrams. And I thought they were brilliant. Because you can describe so much on one piece of a4, you could work at them as a group, it will contribute to them. And they will all go online. Every app has got some kind of way of creating an Ishikawa diagram. So they are brilliant. And I became interested in through that. And I recently read one of his books, which I'm going to put put a short review of it a couple of weeks. Stick. Okay, this code shapes engineers. That's how we did that come from that. Yeah, there was just like, Okay, this is lots of really profound stuff. And the way he changed Plan, Do Study Act to Plan Do Check Act. I understand Deming didn't like the chain set of study, I think discussion around that's quite interesting, I think for us as testers, if you're working on a plan, do study act, study makes far more sense. Because sometimes you can feel pressured, I'm just going to check this and then move on. Well, actually, you don't want to, you want to study it. But it was also interesting, as I hadn't realized, as he subdivided, do plan into two separate parts. And that makes that makes you think a little bit more than I could because this they are about education and training, thinking what education and training we can you leave when you do planning, and then doing the education and training when you do part? Actually, that's quite useful. And it does emphasize something that can sometimes be in a pressured situation be overlooked the need for education and training, the need for learning. And so I thought that that was interesting as well.
John Willis: 37:42
Don't you know that one of the things I think I've conclusion, so Devaney was very words mattered to him, like, and so, you know, the one of the things I wanted to go back, and I wanted to really understand why he changed the seed, to ash right. And I think he felt that the sort of check was sort of one it was it sort of, maybe implied that there wasn't sort of a cycle. It also implied sort of this, like, sort of, you know, like stopping point, or I would say, a deterministic, like, yes or no, right, which is difficult to like, the way he thinks, especially being sort of born in a quantum physics world. But I think the other thing I've realized, because it's the same thing with when he changed, like, chance and assignable cause to, to basically, you know, common and special or uncommon, and it's really common in special course, right. I think part of that, too, was he wanted to make sure words mattered. But he also understood, there was a difference between the culture of how a word was interpreted particularly in a very intrinsic culture, right. And I read something the other day, because I was coming back and I was looking at Toyota owners five why's and he used your there's a lot of pushback today about root cause, in fact, I just did a podcast with seven, school service management daughter now, she wanted to ask me why, you know, why did the young kids or the new kids are all against records? And so, you know, I gave her my explanation, and you know, why I think people have, you know, feelings against it. But I went back and I saw a Toyota owners, you know, he talks about root cause and the five ways, right, or whatever disorder article about how the, in very intrinsic culture, you know, that sort of a root cause is less corrosive, because, you know, let's face it, most of the people who worked at somewhere like Toyota felt they were they were empowering the company. So they didn't get the sort of a blame or like, okay, way the sort of Western culture Has Yeah. So I think I think it might here's my sort of long winded point is, I think Deming because he spent so much time in that immersed himself the culture, not just the training, like he was a big fan of kabuki theater. I mean, he literally spent a lot of time immersed into that culture. I think he also more than just words mattered. I think he understood the cultural references, the differences were PDCA probably works well, in its interpretation, Japan, but in a Western culture, could have the bit wrong meaning, and I think that that with assignable and chance, you know, I think he you know, so So I think there's two levels, one, he really felt you had to have the right words. And then he understood sort of more than most, how the cultural difference of a word might mutate the interpretation.
Mike Harris: 40:58
Essentially, it's one of the things I'm just reading the Ishikawa he writes about Deming, and he says, Deming was a good friend of Japan, he really knew Japan. And actually, that's, that's a very powerful thing for him to said,
John Willis: 41:13
no, they, if you read, his secretary wrote a book on seesaw care, I forget the name, but the name but the page takes all his notes. And she published it. And it's basically, you know, like, you get the, like, the real sense of, you know, how he'd be exciting to see somebody for Saki, or you know, and like, you know, like, he loves, you know, you can read it, but then when you read his notes, you realize you just love to coach, let's end with. So I've been really digging into the notion of operational definitions and definition. And I, you know, it's again, that sort of peeling the onion with Deming when you read like New Economics, and he mentions it a bunch of times, and you sort of see it spread throughout the book. And you're like, Yeah, this is important. And at some point, for me, like a lot of things with Deming, the light bulb went off, and like, Oh, now I understand what he was talking about in chapter two. And how that is, and literally, I just did a presentation this morning to the door folk about, you know, the door metrics, and how, you know, we don't have clear operational definitions for like, lead time. And as an industry, we really need to sort of do better and follow hats or some of the other disciplines like, nuclear. So what are your thoughts about operational definitions or definition,
Mike Harris: 42:36
that they're a great thing to test us, you know, that it gives us a way of talking about something that we do, because if we go into planning, we want to have the idea of operational definitions at the back of our mind or at the front of our mind with it, because we've all been to a planning meeting where somebody we go to make a better, whatever it is faster, more easy to use. And if one says yes, and but there's a testicle civil, actually, how do we know? And they've been able to articulate that. And it's not just us saying it, then actually, you know, there was a sky Deming, and he said, Actually, we want to have some criteria and sampling. Okay. So actually, really, really, really very useful. I always included in my talks, because I think testers find that particularly useful,
John Willis: 43:30
ya know, the feedback I got from the dark, I mean, I thought like, it was going to be dangerous going into the lion's den and, and sort of, like insinuating that, like the, you know, and everybody was real positive. Do you find that most people in the testing community don't really, I mean, you know, this is my sort of bug about sort of DevOps in general. Certainly, Dora, and, and again, I think for anybody listening, I think door, you know, what, Nicole, and jazz, you know, tastic, for industry? Unquestionably, yeah. Yeah. It's sort of 10 years later, and now like, let's really act like engineers, do you find and so but my sort of thing is we're not right, we're using these metrics. And when we're sort of not having clear operational definition, do you find that in testing? That's the case to or most people aren't being clear? Or do you find that people tend to be better at that, in general?
Mike Harris: 44:23
I think testers feel that one of our roles is to try and make things explicit. Well, one of the things I admire about developers is how they will take a user story or a spec that's got lots of implicit requirements in it, and they'll then admire it and they'll get it, they'll understand it and they'll produce what's expected of them. Whereas a tester your sickness, actually, I'm not quite sure what that means. That can be one thing or it could have been something else. Are we assuming that this is this has been done before we do that and having those questions? Does save work later. down the line. So I think that this is still an issue, I would have said that the development community, generally I would have thought this is still an issue, testers are a part of that community. So I think operational definitions are really useful.
John Willis: 45:14
I really would like to sort of see it really sort of brought to the forefront on a lot of our sort of DevOps dev SEC ops and IT risk conversations. They would treat me sort of, maybe I'll ask this question. It's been great. Actually, I've been really enjoying this. You know, one of the guys that work with Bill Benson, you know, and he's, he had an operations research background. And then he did a lot of software development architecture at Red Hat with me, and now we're working together on some sort of automated governance stuff. And, you know, I share my knowledge of learning a Dami. He shares his research and, you know, one of the things I think we think, is an interesting concept is in, in software, we we focus on on requirements. But in other disciplines, there's more focus on specification. So I think, is an interesting conversation probably to have about the difference between sort of a requirement and a specification and software delivery. I don't know if
Mike Harris: 46:12
it's actually I have not been part of that discussion. Actually. I haven't seen that. It could be because I've worked largely in startups, and we tend to use user stories. I'd haven't gotten the large documents, which I'd imagine you've got elsewhere. But yeah, that would be a different, I can see that there can be there's a difference in meaning. But so we tend to think, is this user story adequate? Have I got enough points? What about the acceptance criteria? And the discussions based around that? I think seeing this, this is what you're suggesting, if you'd see these are stories of specification, and they mix up to requirements. So
John Willis: 46:56
there's a boundary between sort of creative ideation and sort of rote manufacturing mentality, right. So I like I don't really know what the right balance and answer is there. Right. I do believe that we do fall more on sort of the ideation and the knowledge creation, which, you know, just I mean, yeah. And but maybe a little more spotlight on the notion of, you know, which brings in the variance and to your point, like, again, you know, what, if you could be better at sort of go no, go for acceptance testing, and you could use more stuff? I don't know. I mean, it literally read lately. It's just me and Bill, having this sort of conversation, we're going to try to write about it a little bit more. But I was trying to since when you brought up the acceptance testing and the part of testing, it just made me think about questions. So. So to be determined. Yeah. Well, Mike, this has been fantastic. How do people find you?
Mike Harris: 47:57
Find me on best on Twitter, where I'm at a test and analysis firm, your LinkedIn, I'm Mike Harris. I've got a blog, which is tested analysis, Wordpress, so that the right people join it. So thank you very much.
John Willis: 48:16
Yeah, put up put all the links in the show notes. And it was good. It's good. I know, we've been trying to set this up for a little bit while now I know we're, I'm sort of loving all these sort of fellow DevOps travelers, you know, that we're sort of. We're, you know, we're running into each other a lot on LinkedIn and stuff, and it's just a lot of fun. Well, good. Well, thank you, sir.
Mike Harris: 48:36
Great. Okay. Thank you very much. Let's have a conversation. All right.
