#258 Lisa Crispin on a journey to define what quality means
Transcript
⚠ The following transcript was automatically generated.
❤ Help us out, Submit
a pull-request to correct potential mistakes
Lisa Crispin 0:00
There's a book Practical Guide to testing and DevOps by Katrina cloaky. Available on lean pub. And she devotes a lot of her book to building relationships within your team and outside of your team. And that really, I read that book quite a few years ago now. And it really struck me and it's such good advice. And it's so important. You know, what's important to us, is communication and collaboration. The you know, your story about trying to interview good people to get on a team, it's not about what skills they can tick off a list is their ability is their mindset is their attitude is their ability to communicate is their willingness to take on new challenges. And these are the skills we really need to work on. And you can do that by building relationships with other people and learning their language. You know, if you want to work in DevOps, learn the terminology of DevOps, those kinds of things. And so that's, that's my advice.
Tim Bourguignon 0:54
Hello, and welcome to developer's journey, the podcast, bringing you the making of stories of successful software developers. To help you on your upcoming journey. I'm your host team building. On this episode I receive Lisa Crispin. Lisa is the co author and contributor to if my code is right, six books around testing. She is also the co founder of the agile testing fellowship, when she isn't writing or holding masterclasses in testing strategies. She enjoys working as a tester with an incredible agile team, or sharing her experiences or participating in many agile testing communities worldwide. Literally, Lisa, welcome veteran.
Lisa Crispin 1:39
Thank you so much. So it's great to be here. It's quite an honor to be a guest.
Tim Bourguignon 1:43
It's my pleasure, I assure you. But before we come to your story, I want to thank the terrific listeners who support the show every month, you are keeping the dev journey lights up. If you would like to join this fine crew, and help me spend more time on finding phenomenal guests then editing audio tracks, please go to our website dev during the info and click on the Support me on Patreon button. Even the smallest contributions are giant steps toward a sustainable dev journey. journey. Thank you. And now back to today's guest. Lita, as you know, the show exists to help the listeners understand what used to look like and imagine how to shape their own future. So as is customary on the show, let's go back to your beginnings. Where would you place the start of your directory?
Lisa Crispin 2:36
Well, I got my first programming job per trainee job. After I had been laid off from well, I was working for a government agency, they got this band that basically and I was looking for a job wanted to move to Austin, Texas. And I was went to the University of Texas employment office and I saw a sign that said, programmer trainees needed no experience required. And I thought, okay, good, because I have no, almost no programming experience. This was back in 1982. And so I went and took their aptitude test, and I happened to have an MBA, and they were looking for somebody with a business background with an MBA. So I got hired the same day. And I was very, very lucky because they had a wonderful training program. They worked in a very collaborative now, we would probably call it an agile type of approach. And I just got such a good grounding and how to work with end users how to help people learn how to learn from each other, and was a great place to start my career. So so that's how I got started. My my original college degree is in animal science with a concentration in beef cattle production and a minor in French literature. So you know, diverse backgrounds are good for software development, so it all worked.
Tim Bourguignon 3:59
Did anything attract you? Especially to this, this program? Besides the no other experience required? Did you
Lisa Crispin 4:09
desperation for a job? Okay, that's also, you know, I was trying to move to that city. So and when I interviewed with him, I would say qualities are really nice people. It sounds exciting, you know, I they're gonna, they gave me a lot of reassurance that we have this really great education program, and you're going to find it very easy to learn. And what we're really interested in is your domain knowledge, we can teach you to code. And I thought, well, that really, that was reassuring.
Tim Bourguignon 4:38
Okay, sounds good. Did you? Oh, do you remember the image you had of what it's going to be when you started?
Lisa Crispin 4:46
Well, I you know, I was in college at a time when people were still using punch cards. So that's why I stayed away from computers. And I did use them a bit in graduate school, but, you know, I think I had a Fortran course or something Um, but yeah, I didn't really it wasn't just certainly never crossed my mind as a career. And you have to remember to back in the early 80s, software programming was still considered a low status job. And there were quite a few women in it and salaries were quite low. So it wasn't seen as the as the, you know, desirable profession that it is today.
Tim Bourguignon 5:24
I got contrary,
Lisa Crispin 5:27
No, you wouldn't know. But if you read anything about it, people wonder why are there no, not so many women in software development, and there were that one time there were, but as you know, because back then hardware was the thing. It was like, let's get better chips and better hardware and make our machines go faster. But then the hardware store was started. And it's like, okay, what, how do we advance now? Well, we need the software to advance and as that became, a more necessary profession kind of got elevated, and salaries had to go up. And when salaries go up, and professionals, often the women lose out, which is a sad thing, but we've seen it more than once. So I feel like I was lucky to get in it when I did.
Tim Bourguignon 6:10
It sounds like it. And now you're talking about agile in early 80s.
Lisa Crispin 6:16
We didn't have that word. But we didn't, we didn't know about I don't know, waterfall might not even have been invented. We just have this, the data processing Division at the University of Texas had just created its own way of working. And we were sifting off a COBOL, we were using a for a 4g All that was very easy to work with very fast. And basically, when an academic department needed something or like they needed a registration system, or we want to put the library catalog online, or whatever it was, we we simply sit down with those people, what is it that you want, and try to learn what they needed and prototype it. And we can very easily create prototypes and let them try it out. And we would just iterate through that, you know, until we got what it was they wanted. And, you know, for things like the online library catalog, obviously, we needed to learn a lot about library science and things like that. So we worked hand in hand with the librarians and the people who knew the domain. And you know, that's agile development is very much like that, working closely with your customers, with your business with your end users, and getting that fast feedback. You know, and doing the Lo Fi efforts. So you can change things rather than waiting until you've got everything coded and say this is what you wanted. And so learning that approach at the beginning of my career, I think was was a big advantage.
Tim Bourguignon 7:42
Yeah, I believe so before you were deformed by wonderful.
Lisa Crispin 7:47
I was shocked by my first
Tim Bourguignon 7:50
which which is I'm going to say we're ready. But which is fantastic to see nowadays, working with young developers who haven't been through this and start with the Julita right away. And when you tell them about the way we used to do things, they look at you with big eyes, they just can't they don't get it. Why?
Lisa Crispin 8:06
What was what was that about?
Tim Bourguignon 8:11
I can already say, Well, back in my days, yeah. During this course, we'll actually the scores you mentioned, you didn't know you didn't. How did you say yes, I won't be able to quote you five minutes later. He said something like, I couldn't figure out this would be a job afterwards. Or this could be a profession.
Lisa Crispin 8:33
Yeah, I mean, nothing, I never thought I was gonna I first I was going to be a county agent, helping people learn how to run their ranches better. But that wasn't a very, they didn't welcome women into that profession at that time. And then I thought, well, I'll get an MBA, and then I'll work for some big agricultural company or something like that. And then I found they were all located in like the American Midwest, which I didn't want to live there. And then I got into this really great research area for for governments, and research, but again, that we had a lot of fun doing that research, but then that department got decimated, and so I was just, you know, leaving the job. And this was just a job. And for a long time, I thought, well, I'll do this job, until I figured out what I really want to do. And I just kept doing it and kept doing it. And, you know, after a few years, I realized, oh, no, I really like this. By I'll keep doing it, plus the salaries went up. So you know, it was a it was a good job, and I and I enjoyed it. And you know, if you wanted to move somewhere else, it was easy to get a job was very, you know, high demand profession. So, so I stuck with it.
Tim Bourguignon 9:47
And well you did. Remember to remember when this clicked when you stop thinking I'm gonna go back and say well, no, I'm good where I am.
Lisa Crispin 9:58
You know, I think it was about that. It's time I kind of switched over into being a testing, having a focus on testing rather than programming. Tell us about that. Well, we, we got, we never really thought about testing per se, like this first job I had at University of Texas, you know, we would just sit with the users in here, how does this work? How does it work for you, and they use it and they asked for changes, and we could easily make the changes, you know, so we can easily redo things or change things for them. So we never really thought about testing, we just put things in production, we had no process at all, at work. And then later on I was working for, I ended up working for a software vendor and tech support. And this was after I'd moved to Colorado, and and our developers are mainly in Germany. And so this was, again, I'm really old. This was before we even had faxes. And so literally, our customers who were usually big banks, big government agencies, big companies, what somebody would call us on their DBA, our main product was a database, they call us on the phone and like, my database crashed. And you know, we'd have to take a hexadecimal dump over the phone, and then figure out what line of code broke, I can't believe I knew how to do that once. We were so excited when we finally got a fax machine. But it was so embarrassing to have somebody call up and I said, I just installed the new release. And I cannot believe you didn't know about this big bug. No, we didn't know about it, because we didn't see it anytime before you did. So we got the idea. Our just our support people, we contacted developers in Germany said hey, is there any way you could maybe ship the tapes over to us maybe a week or two before you give it to the customers, even if it's not your final thing, and we can start trying it out ourselves? And then if there's a problem, we can start working on a patch. So that when the customer is called us, we can say, oh, yeah, we know about that problem. But we're working on a patch, they'll just be out in a few days. And that was so much better. And our managers were like, testing. Nobody had thought about doing that before. And, and so they said, Well, maybe we should have a department of people who TAs and the dudes who take responsibility for deciding it's time to release and go ahead and ship the tapes and all that, and let's set up a department for that. And who wants to do that. And I'm like, Oh, this sounds really fun, I'm gonna do it. And I think then that's when I really got into this is really fun, I got to learn every operating system in existence at that time. And, you know, I just, like got to learn almost a lot of different databases, for example, you know, I just, it was, I'm a generalist, I love knowing a lot, a little bit about a lot of things. And so that exposed me to a lot of really fun things. So that was a good direction to go in. And I think that's when I really thought the I really liked this, there's always something new to learn. I get to work closely with other people. It's all very collaborative. And it's fun.
Tim Bourguignon 13:03
It sounds like you have a big smile on your face. explaining all this. Your back there your mind, it is really fun to see. Did you see yourself? So you, you created this this department, I assume? And did you see yourself dwelling to this for four years? Was it? No, I'm gonna go back to development.
Tim Bourguignon 13:24
No, I just realized, I mean, I still was writing code, you know, and eventually, you know, automating regression tests and things like that, and, you know, writing code so that we could teach people how to use the products and things like that. So we did a little of that too. But, but yeah, I really liked putting, you know, putting the other hat on and say, how might a real customer use this product, and what might happen? If they did, and just seeing things more from the customer perspective, and trying to prevent problems going out to them, it was just, it was a fun challenge. Because you know, and then the detective work and it's like, ah, something happened and trying to narrow that down. I enjoy that problem solving and then working with the developers to fix it. You know, I find that very satisfying to just I really like getting to learn all the different know this back in the days when Vax BMS and wing and you know all these different crazy operating systems, Unix OS two, I can't remember what they all were anymore but in supporting people, you know, supporting customers on all those different platforms, this stuff it was I just found that really fun.
Tim Bourguignon 15:23
Did you was there already this this? I want to call it fights, but it's probably me priming you for the question. This this. Yeah, I've no better word for that this fight between manual testing and automating stuff. And
Lisa Crispin 15:39
we were so ignorant about testing that we immediately tried to automate things. I mean, we were programmers, so there were no tools around. So there were no commercial tools around at that time. Well, there were maybe a few, but it wasn't, it wasn't really a thing. But there were some kind of open source type things, you know. So it's a very different landscape than but, but we found some things that would help us and speed things up. We knew nothing about testing. I think I went to my first testing Congress in the early 90s. And it was a that was not a happy place, that the official software testing community back then. I really didn't, I didn't find it welcoming. I didn't identify with it in any way. Well, I went to this big conference and listen to the talks. And they were, there were some pretty good talks. But like, none of the speakers would talk to you, you know, the people who were not speaking were just nobodies. So it just felt like, well, unless you prove yourself, we don't really need to talk to you, or answer your questions or anything. I just found it kind of alienating I guess, in a way, I was like, Oh, I'm gonna go back. And we're just gonna keep doing things the way we do things. And happily kept working that way. And, you know, then we certainly got you know, that the early 90s, you started to see commercial vendor tools, or which are mostly the record playback type of tools that, you know, not not optimal. But they can help. And I, you know, I've worked, I went to work for a different database company, and, and what was interesting about that job was now now we were waterfall. But waterfall, now people say waterfall, they mean, chaotic, completely dysfunctional development organization. But we were waterfall in that we did have these phases, and they were long. And if we were a database company, our customers didn't want something any sooner than in every six months or a year, it was fine. But here was the difference. And what a lot of people how a lot of people applied waterfall was, you know, yeah, we had an A requirements phase and analysis phase, and all these different phases. But everybody was involved in all those phases. I mean, not that not the whole development team, or the whole testing team, but representatives. Were there all along, we did collaborate. And our, you know, I tested, we tested the requirements, which was really interesting. That was actually something I picked up at that testing conference. So it was useful, you know, to see if there are inconsistencies or ambiguities and making sure we have that shared understanding of what to build. And in our developers would, they would write unit tests, and they were supposed to, they were actually tasked with covering 100%. And they even had to write unit test plans, which I think it was a little overkill. It was always a test driven development, but good automated unit level regression test. And then we did have testers that we, we didn't really have a middle like service or API level type of thing was a database. But we had a UI level because we had a UI for our database. And and so we did use to take advantage of these new tools to to automate our UI tests as much as we could. But again, working closely with everybody, and we're, we were all in it together. We have continuous integration. We have automated deployments. These are just good development practices. And this was the early 90s. You know, these things got maybe popularized with agile and gotten new names with agile, but you could do them before over that. And so we had incredibly high quality, we didn't have critical bugs in production. You know, our customers were happy
Tim Bourguignon 19:28
to solve incredible. How did you stumble from one fantastic job to the next?
Lisa Crispin 19:34
Just blind dumb luck, I think, or maybe just because I met you know, I met good people. And then maybe then I like to say, when I switched to a new database company, it was because my boss had had moved over there. Somebody had been my manager. She's like, Oh, this is a really nice place to work and the company I was working for. They were not. They kind of weren't keeping up. You know, I kind of felt like they're not really Keeping up with the new things that people want. And also, I didn't want to just be stuck with one, knowing one company's products. So I moved to this other one. And it was just a wonderful, just a wonderful environment. And then I moved on to my first web startup just because I wanted a new challenge. Like, oh, how do you test a web application? You know, I had no idea. And I found some random person on the internet. Who, because going back to working on that online library catalog back at the University of Texas, I was familiar with the people who do who catalogue library books. And one of the companies who does this, it's really a universities, nonprofit company, OCLC, they, they do library catalog all over the world. I saw that they had a web test tool. Like, okay, this is familiar to me, this organization showed me. So let me find out more about that tool. And I met the fella, I met the developer the tool, and, and he taught me how to test web applications. Because we bought his tool. I ended up Friday ended up writing a book with him later. But um, but yeah, just this, you know, just being open to learning new things and getting to know people and I'm basically a shy person, but just getting to know people. You know, I learned later in my career, I learned that, you know, this was called building relationships. And it's really important. But I was just, you know, a lot of people have a saying, If you can't be smart, be lucky, I felt like it was just really lucky. To get Tim, to just sort of grab on to things like, this looks a little familiar. And maybe if I start here, I'll learn a little more. And just move through like that.
Tim Bourguignon 21:55
So good for you. This is very fantastic to see how you went from from one fantastic job to the next. And picking up new things along the way, and always having kind of a good environment. I was I didn't describe anything dysfunctional so far.
Lisa Crispin 22:11
No, I mean, after that, I eventually got there. But after I was pretty golden, the first good, good part of my career, okay, as you want to get there. Yeah, so the web startup I joined was quite a successful web startup as it happens. But as also happens with web startups, we got bought by a big stupid company.
Tim Bourguignon 22:37
Which means they have less fuel.
Lisa Crispin 22:39
And it's like, I do not want to work for this company. And by then I had moved into a manager position. I was still had time to do a lot of hands on but you know, the, the, one of the co founders of that company was just a wonderful person, also French, by the way. And, and in when he wasn't, they booted him out, because he was against selling to this big, stupid company. And I was like, Okay, I gotta look around for something else. And I really want to be, you know, more hands on, and all, all of our senior developers left, from the VP on down. And some of them went and started a new company, and there was our new consulting company, and they said, Lisa, we're gonna do this new thing called Extreme Programming. You know, here's this book by Kent Beck Extreme Programming Explained, we're gonna do this. It's so exciting. You should read this book. I thought, I spotted that on yourself.
Tim Bourguignon 23:38
It's right behind me.
Lisa Crispin 23:39
And I read the book, and you know, our web startup, we're doing a very traditional waterfall model. But you know what, that does not work in the fast paced world of web applications. And we can't we had a PMO. And we can say, well, if only we were more disciplined with our phases, so we will succeed by, well, what happened? The competition always beat us, right? And so I read the book, and I thought, Oh, my God is all about people. It's all about letting people do their best work. It's all about quality. It's all about testing. This will work. And, and so then I begged my friends. There was nothing in the book about testers a lot about testing. And but I begged my friends, like you have to hire me, you need to test her I'm sure. I'm sure you do. And so they were kind enough to hire me. So that's how I got on my first extreme programming team.
Tim Bourguignon 24:34
So how did you bring testers in this? In his book, which has new testers,
Lisa Crispin 24:39
it was really hard it was really hard. I mean, the first three books on that XP series that Addison Wesley did not as not a one of them mentioned testers. And, and they were actively kind of Anthalie anti tester because do you do you have to remember that extreme programming Grabau grew up out of a pretty small Well, at least kind of narrowly focused payroll projects. And they could sit in a room with their stakeholders and low stakeholders, were willing to write the tests, like customer tests, and they could automate them, blah, blah, blah, very focused on functional testing. So it just was a very well defined narrow area. And yes, in those cases, you don't need a tester, that's really true. But in real life, there are a lot of different contexts where somebody with testing expertise can bring a lot to the party. And I really believe that I really just see there's a lot I can do, I bring a different perspective, I can pair with a developer and bring a whole different perspective and, and, you know, eventually, look at all the different kind of testing, we have to do security testing, accessibility testing, performance test, there's a lot there, I'm telling you, that one programmer and one customer is not are not gonna be able to do all that testing. But there was a lot of resistance at first, although the community was very welcoming. And so I joined the Extreme Programming mailing lists, and I went to the first XP universe conference that they had here in, in North Carolina in 2001. And people just live in Carroll was a tester they were just as friendly and welcoming as they can be. And, and very encouraging. And when I said you know, somebody, really how to write a book about how to do testing on these projects on those extreme programming. And they're like, Yeah, at least you should. But I, you know, my the person who helped me learn how to do web testing also had gotten to extreme programming. And let's say, Okay, well, we'll write a book together. And we did. But they were very, very supportive. But I'll tell you a story. I wrote very early on probably 2001, or 2002. I don't know might have been earlier that anyway, early days of XP, Ron Jeffries was one of the leaders of extreme programming. And he was going to be in a town near Denver, where I was living. And I arranged to meet him for a drink. And I was late getting there because I got caught in traffic. I got there. And I met him. And he's a very, he's a very, very nice man, I love around the death, but this first time I've ever met him. And we're talking. And he's like, you know, anybody who's not writing production code on a extreme programming team is a useless fifth wheel. And almost burst into tears out there. I did burst into tears when I got home, I thought and my, my husband's like, why are you? You? You know, don't cry over this guy's an idiot. And he's not an idiot. And he ended up helping us a bunch with our with our first book testing Extreme Programming he helped to hate helped us a bunch. And I think we each came to see the others viewpoint. So it was hard sometimes. But as I kept back even said once in a talk at the, I think of the second or third XP universities like, yeah, people like Lisa Chrisman just came in elbowed their way in, you know. So it wasn't very welcoming space. And now we see we need all kinds of specialists, we need data specialists, we need operations specialists, we need design specialists. I mean, they're all kinds of people we need. So it's just a new thing growing up.
Tim Bourguignon 28:18
Do you? Do you understand where he's coming came from? I don't want to pick on the on on one reference. But But this comment is very interesting. Did you understand where we came from, from his vantage point?
Lisa Crispin 28:31
I think he said, you know, people often steal today's he testers is a whole different type of role. And and to be honest, I played that type of role. My role, my title at that web startup, was quality boss, I look back and think that's horrible. I actually decided whether something was ready to release. That's not my decision. That's a business decision. I can provide a lot of information about what the risks are, what we tested, what we haven't tested, what can happen, but it's not my it's not to me to say wish it was the business should do. And I really came to regret that. But somebody like that with that attitude is not going to work well, on an Agile team. We're not gatekeepers. We're not the quality police. And I had to learn that. And once I learned that, everything, we all understood each other a lot better. And and I do believe, especially today, you know, in modern software development, testers are often what I have been for the last 10 or more years, I see myself more as a test consultant. So I'm on a team, maybe there are one or two testers and in 30 developers, we're there to help everybody learn testing skills and to help everybody learn how to build quality in and it's a group effort. There's no way that somebody can throw code over the wall to us and have us tested it. It just wouldn't work. And so I think we all have that figured out this whole kind of different new way of approaching quality. You can
Tim Bourguignon 30:13
see, but I've been nodding for the past two minutes. That's very much what I what I see nowadays. And I thought that would be your interpretation of this of the sentence or in hindsight of the sentence, meaning the best teams have been on the tester role, and I've been making air quotes has been somebody who is part of the development of the team, let it be a pair programming effort or mob programming effort, somebody who's who's also coding the whole day, but who has a very deep knowledge of how to break things. And who can bring this as a consultant that decide early on team and say, Have you thought about that? That's how I would tackle this thing? And then let us let us do this. But but the testing effort, the testing effort, the doing the testing effort is not on them. Approaching how to break things is is especially their their, their, their expertise. That's what you use?
Lisa Crispin 31:14
Yeah, just kind of bringing down those what if questions?
Tim Bourguignon 31:19
What if we click on this, oh, don't do don't do this.
Lisa Crispin 31:24
And I've been lucky, you know, to work on a lot of teams that did pairing and and then my the last team, I worked on full time we did ensemble programming and and I'm not a coder anymore. I can write code by myself anymore. I don't you know, I realized I tried to couple years ago, it's like, Okay, let me get back into this, I can learn this again. Because I just don't enjoy it. So there's no way. But I do enjoy pairing around sampling with people who are coding. And if it's my turn to drive, they can tell me what to type is a little painful. But sometimes slowing down is a good thing for the group to do. And you save time, because you're more thoughtful. And you think about those what if questions in your preventing bugs. And it's just been wonderful to be able to work that way.
Tim Bourguignon 32:10
So you mentioned the word consultant. So you were part of the team acting as some kind of expert consultant, but really being part of the team and not being an outsider.
Lisa Crispin 32:24
Yeah, definitely not an outside force. And and, I mean, I was doing hands on testing as well, obviously. But But for example, at one point, our development managers, we were trying to move to continuous delivery. So we're trying to deploy to production, like twice a week, instead of once every two weeks, it was going very badly. And one of the reasons it was going very badly was we still, we still had the stupid manual or resin checklist for things we couldn't automate. And they were and there were like, two of us testers were trying to go through this checklist. Of course, when we go through the checklist, we've noticed all these other things, so we can't really use them. You know, it was just causing a lot of time. And we weren't spending our time doing the things testers really do well, such as exploratory testing. And so these really bad problems are getting into production, because we just didn't have time do the testing. So fortunately, the development managers realized it and said, Whoa, you know, what, we all need to be doing exploratory testing. And so one of the things they did it was really smart. I see very few development managers do this was put exploratory testing skills into the matrix or skills that developers needed to rise up the career ranks. And so and then they said to us, testers, because the place I was working at that time, we I'd been asking for three and a half years, I want to pair with the developers, oh, you'll slow my developers down. And I did occasionally get to pair with them or pair with a product owner appear with other testers, but but they suddenly they're like, Yeah, pair with his helpers. And could you have a couple of workshops and teach them some exploratory testing skills? And, you know, hurray, they were all motivated to learn it because it was part of their job and they wanted to, they wanted to do, they wanted a good product, they want to have nobody wants to have yucky problems in production. And, and so as a consultant, it meant I would bring in new ideas. Like I go off to a conference and learn something like example, mapping from Matlin where you take a have a conversation about a user story, and it's like, oh, okay, well, what are the business rules of the story? What are examples that illustrate this business rules? And now we all have a good understanding. So I learned that at that conference, and I came back and, and, and said, Ah, can I do a little 30 minute workshop with y'all just to show you this thing? Like, okay, you know, they kind of roll their eyes Lisa's been. I'm gonna, I'm gonna buy some really good artisanal cheese at the cheese shop down the street. I'll have that too. Okay. So they tried it they liked, like, Could we try this in our pre iteration planning meeting before the next iteration? Oh, okay, I guess we could try it. So it's bringing, like bringing in specific practices to try. You know, not all the time, but just every now and then I see that as a kind of consulting function, whereas a coach would stand back and observe and try to help people find their own problems and solutions. I'm noticing a problem that maybe we all noticed it in retrospect, oh, my God, our cycle time is so long, because our stories get rejected because we didn't understand it. We deliver something it wasn't what the product owner wanted? Well, let's try example, mapping. Maybe it'll cut down on that cycle time.
Tim Bourguignon 35:42
Poof, who worked?
Lisa Crispin 35:45
So yeah, I mean, it was, it's a mix. But we're always trying to transfer our testing skills to people who aren't testers on the team, because everybody's got to be thinking about this. The shorter the feedback loop, the more you can prevent bugs. And from the get go, the better off you're gonna be.
Tim Bourguignon 36:03
Did you have the feeling that this testing mindset in the development, development teams did not the right one in the head of the developers has changed over the web over the years?
Lisa Crispin 36:15
Well, I've always found that, you know, from the early Extreme Programming days, those developers were quite test test obsessed. In, you know, test driven development, while is really a code design activity, it still produces automated regression tests. And I do feel like there was a lot more emphasis on, we're gonna do this well, from the get go, we're not just cranking out lines of code. We're building something thoughtfully, and incrementally in these tiny little chunks and building it up, building it up getting the feedback so that we know we're on the right path. And I think that's a mindset that works really well, that produces good quality. And especially from the from the teams that adopted Extreme Programming, because they realize that it was a good way for them to work as opposed to big enterprise companies, where the CTO says, Oh, we're going to, we're going to implement safe and be agile now. You know, they don't automatically have that mindset, right. So sorry, anybody who really likes safe?
Tim Bourguignon 37:24
All right. I'm gonna be opinionated and say, That's all right. I want to be, I want to be novices, not nasty. But if I had a team that that isn't neither really testifying, nor really versed on XP, would you start by pushing them towards more more testing, or more toward the XP mindset? And and saying, Well, this is going to be the first building block to the rest?
Lisa Crispin 37:57
Well, first of all, I'd be really important to know is our team going to be allowed to be an autonomous self organizing team and manage our own workload? And if so, the first thing I would ask the team to do is let's sit down together and have a conversation about what quality means to us, and what level of quality that we want. And once we know that, then we can decide how we will achieve it. So for example, a team I had joined back in 2003 was my first scrum team. And I was lucky enough that our manager, our VP of engineering was Mike Cohn, who is well known in the scrum world. And then the most amazing coach ever. And so we knew we would be a good self organizing team because he made us do that. And so we still we sat around, it's like, well, we want to write code that we would be proud to take how much our moms and put on the refrigerator. And so how are we going to do that? Well, we've seen that the extreme programming practices to produce high quality code that you would want to put on your refrigerator. So let's, let's try those. Let's embrace those. And then we we, we made a real commitment. As a team, we are really going to do this. And we know we're going to run into problems, but we've made a commitment so that we're going to work around whatever problems those are. And so you know, the hardest thing right away was test driven development. Nobody had done it. So Mike brought in us more senior developer who had experience. He gave us time he got brought in people to train us. He said, I don't care how much you how many stories you deliver. I don't care how much volume of work you do. I care that you learn how to do test driven development because you have decided that you want to do it. And it took about eight months to get traction on it and because he could tell the business leaders because they worked really hard to hire him because they needed somebody this Same year software development was like just, you know, be patient. And they were getting they were getting some features every couple of weeks. They were they were happy. But because we knew we had this nominee, and he had to convince a team because it had been so dysfunctional before he got there like, no, really, you really can't take the time to learn this. I really don't care what there's no deadlines for you to meet. You just need to learn this. And, and it worked. But yet, it took a lot of patience and took a big investment from the business, which was a startup and but I found that when I'm on a team that maybe does a pretty good job with extreme programming practices, or other good core development practices, but they've never had the conversation about quality and what level of quality they want to achieve. They're less likely to become high performing teams. That's just my experience. And I just feel like because they don't, they don't really have an aspiration for where they're trying to go. I haven't made that commitment. And so when there's a problem, they just throw up their hands like, Well, that was too hard.
Tim Bourguignon 41:06
It sounds as if they've been doing the moves, but never really understood the philosophy behind it and understood why yes, I mean, I liked that you push back on that question and saying, No, I wouldn't tell them a OB, I would reflect on them. What does it mean to answer this question in the first place? And I really like that, thank you. What kind of customers come to you nowadays? So you you're you have a consultancy, you know, what kind of customers come to, you know, customers. I'm sorry about that.
Lisa Crispin 41:37
I blame the economy. I just went out on my own last year. And I did, I did a couple I did a couple of things. I, one of the most fun things I did was a company that had come together by acquisitions. So they had seven development teams that each probably each came from a different company, originally, and they had this Frankenstein website, that was all these applications Cluj together. And their CTO was somebody I'd met at a DevOps days conference that remembered me like 18 months later. And he, he really believes in the whole team approach to quality, the whole team's got to take ownership of quality and testing. That's how it works. And he told, you know, he and their managers told the team's app, but they were like, well, that sounds great. We have no idea how to do that. They have some testers. But the testers again, they had never worked in an agile context. So they, you know, they just didn't know how to deal with it. And so what I ended up doing for them was a quality practices assessment. Because the leadership, just want to know, where are we? You know, what's our baseline? Where are we in quality? Where do we need to go. And I use a model developed by Janet Gregory and Sylvia Leesy, quality practices, agile quality practices assessment model. And there's 10 aspects of quality that they figured out are the most important ones. And basically, I had process retrospectives with I didn't do all the teams, I think, two or three of their teams, and interviewed the managers and the testers and the, you know, some key people, even the even the CIO, to find out, you know, in a, doing two week iteration, so what do they do from start to finish? You know, who has the story ideas? Who turns those into stories? Who, who does a testing? Are they doing what practices are they doing it? So, you know, it's obviously hard to schedule that with a busy company is, over the course of like, three weeks, I did these retrospectives and interviews with them. And, and then I use the model to write where they were. So there are four dimensions for each quality aspect. And then I can say, you know, here's where you are in each one. And it's up to you to decide what's most important to you, because you can't fix everything at once. So this will help you decide where to focus. And then after a while you can you can go back and assess where you are now and what you want to what you want to work on next. And they found that really helpful, because it kind of just gave him a baseline for you know, we're doing pretty well here. We need a lot of work over here. I think that's a good thing for people to do, because it gives you some guidance of you know, where do we want to focus our experiments on improvements? And how will we measure them?
Tim Bourguignon 44:37
Is it something that a company can do on their own? Or do they need some some?
Lisa Crispin 44:41
Yeah, you can certainly do it on your own. There's a book Janet and certainly may have written on the model and they're also working on a book on how to how to actually conduct the assessment. So it can't be done internally. So either way, and I just think it's a great That's a little investment of time to do it. But otherwise, you're just kind of punched in the air and like, Oh, I think this will make it better, I think that would make it better. It's really important to have, I learned from Linda rising, that it's really important to do small frugal experiments that don't take a lot of time or resources and that you can measure and have a hypothesis, obviously, not really scientific, because you probably don't have a control group or anything. But, you know, like, what was my example of mapping? Okay, let's we believe that if we try example, mapping, that within two weeks, we will see our cycle time go down by 20%. You know, we can we can set goals and really measure them. And when you get the big picture of what's your, how do your processes look now with regard to quality, because your, your process quality affects your product quality. I think that's I think that's a good though. Lots of ways to go about it. But I think that's a good way to go about it. So I had a lot of fun doing that. And, and, you know, I do training, we have our agile testing fellowship, we have a couple of training courses. But I find it really, yeah, I, I wish I miss working in person, but I have to do things remotely because I live in Vermont. But but we've we've worked out these courses, so they can be done very well remotely. They're very hands on people actually practicing what they're learning. So I enjoy facilitating those. You have to try things to learn it was not just somebody talking it Yeah.
Tim Bourguignon 46:36
Oh, yeah. Oh, yeah. getting hands on and and really facing the wall and really hitting your face on the wall saying why is it not working? And at some point, realizing why and how is it? That's that's really part of learning experience. I'm struggling with the the advice I want to ask you, because I think you answered it already. I wanted to for the whole conversation, I wanted to ask you, if somebody is not happy with the quality of their their software right now where they should start. But I think the answer is going to be the same. Forgive me already. So is there an advice that you want to give to to newcomers who haven't seen this, this 30 years of change in the way we develop software? And the way we test nowadays? Is there any advice that sticks
Lisa Crispin 47:26
still? Yeah, I mean, I think it's really important now to think holistically, the whole development lifecycle and all the testing activities that happen all the way around it, including on after even after we release to production and the importance of monitoring and observability. And they're just so much the quality. It isn't just what you do to build the software, but also how you take care of it in production and decide what to change next. And in like I say, I've been lucky just to like meet the right people and learn from them. And my main advice to people starting a job or starting, you know, next stage in their career is build relationships. Go out of your comfort zone, like I say I'm a shy person. But like, a few years ago, I really got interested in DevOps and continuous delivery and monitoring and observability. And I really wanted to get more on that side of things. And I got an opportunity to join a company and help them build an observability practice, which I knew very little about. I just wanted to do it. And so like, well, you know, I was on the quality team, and everybody was embedded in teams. But mainly I'm working with these monitoring and observability site reliability engineers, platform engineers, I just, you know, I realized I had to say, hey, you know, can we have like a 30? minute one on one. So it's somebody outside my team so I can get to know you? Or can we maybe do this every couple of weeks. So me people are talking to people on the front lines that people who are you know, the engineers taking the support calls, talking to them and find out what the problems are and, and I just realized how valuable it is because then it's like, oh, we're gonna switch our continuous our deployment pipeline to this new, you know, this different platform and different tool? Can you develop a testing strategy for that? Like, I don't know. Let me talk to this person that that I already know is working with that tool. And, and I can I can help you. And just that's so important. There's a book, Practical Guide to testing and DevOps by Katrina cloaky, available on lean pub. And she devotes a lot of her book to building relationships within your team and outside of your team. And that really, I read that book quite a few years ago now and it really struck me and it's such good advice and it's so all important. You know what's important to us is communication and collaboration. The you know, your story about trying to interview good people to get on a team, it's not about what skills they can take off the list is their ability is their mindset is their attitude is their ability to communicate is your willingness to take on new challenges and, and these are the skills we really need to work on. And you can do that by building relationships with other people and learning their language. You know, if you want to work in DevOps, learn the terminology of DevOps, those kinds of things. And so that's, that's my advice.
Tim Bourguignon 50:38
And it's a fantastic one. Thank you very much for that. Amen to all this. Lisa, it's been a it's been a fantastic 30 years of how testing became what we know today. Thank you so much. Where would be the best place to continue the discussion with you?
Lisa Crispin 50:56
Well, I [email protected] is my website and all my other information, the Darren my agile testing and fellow.com website, you can link there from that and our book website, agile tester dossier, but I'm on Twitter and LinkedIn and you know, Lisa Crispin, this, I don't try to get fancy with my, my handle and Macedon and blue sky. So reach out to me, I love I love to meet the people and talk to people. And obviously, I love to talk about testing. So
Tim Bourguignon 51:30
anything else on your plate, anything you want to plug in? Well, I'll put a
Lisa Crispin 51:34
plug in for agile testing days in Germany, in Potsdam in November, and also be at that targeting Quality Conference in Ontario, Canada in September. And agile on the beach in July. I'm kind of working backwards in time. early July, but I know this will come out maybe too late for that. But
Tim Bourguignon 51:54
what was awesome. He does say you so much.
Lisa Crispin 51:59
Thank you. It's been it's been a great pleasure to chat with you.
Tim Bourguignon 52:03
And this has been another episode of that first journey. And we see each other next week. Bye.
Lisa Crispin 52:07
Bye.
Tim Bourguignon 52:08
Thanks a lot for tuning in. I hope you have enjoyed this week's episode. If you like the show, please share, rate and review. It helps more listeners discover stories. You can find the links to all the platforms to show appears on on our website, Dev journey dot info, slash subscribe. Creating the show every week takes a lot of time, energy, and of course money. Will you please help me continue bringing out those inspiring stories every week by pledging a small monthly donation, you'll find our patreon link at Dev journey dot info slash donate. And finally don't hesitate to reach out and tell me how this week story is shaping your future. You can find me on Twitter at @timothep ti m o t h e p porker email info pet dev journey dot info