Lisa Crispin: How to Transform Your Workplace Into a Safe Place?

Richard:

Our guest today is Lisa Crispin. Hi, Lisa, how’s it going?

Lisa:
It’s going great. Thank you, Richard, for inviting me on your podcast. I’m really honored.

Richard:
My pleasure. I am, too. I’m so glad you’re here. I’m so glad I could talk to you. I’m so glad I get the pleasure of seeing you through video today. We’re talking about … We both happened to be in new England at the same time, although in different states. I can see a window to your right shoulder, and a little view of the outside with looks like a to-do, doing, done list, which is cool.

Lisa:
Yes, a little personal combine board there.

Richard:
Could you introduce yourself to our listeners?

Lisa:
Absolutely. I’ve been a hands-on tester on agile teams for a couple of decades now. So my big focus right now is continuous delivery DevOps. How does testing fit in with that? How can teams feel confident to deliver frequent changes to production? Because that seems scary from a testing perspective. And so I curate a community site called testingindevops.org, where we just put up a bunch of links to great resources, like podcasts and webinars and blogs and articles and classes related to testing with DevOps, continuous, everything. And also a bunch of awesome guest blog posts.

Lisa:
So we’re just trying to help everybody learn, because to me, this is the future. And testers are needed, especially on the operability and operation side of things. They need us testers to get in there and start asking questions about production and things that are happening in production, and looking for unusual patterns. And learning where to focus our testing better, learning how our customers are behaving or misbehaving. No, how our application is behaving and misbehaving, really. That’s really what I get to do, is I just get to create a lot of content about that, put together webinars and classes and things like that. So it’s a pretty exciting opportunity. And I still try to get in as much hands-on testing as I can help on the team.

Richard:
Right. We were talking before we started recording, you found a bug today. Yay.

Lisa:
I did, I did. I also am starting something new. I’ve always wanted to give back to the open source community, because I’ve been using open source tools these many years. And so I just started contributing to the Cucumber open-source project, to their documentation. I had my first pull request merged during the holidays. So I was very excited about that. And it’s a really great way to learn new skills, too. So I’m learning things about GitHub I didn’t know before. I’m getting back into learning more about using IntelliJ. I hadn’t used that in a long time. So I have to be able to run Docker on my laptop so that I can run the site locally. So all kinds of exciting things. And I do these things, and then try to share them with other people.

Richard:
Cool. And you said that website is testingindevops.org?

Lisa:
testingindevops.org.

Richard:
All right, we’ll put a link to that in the podcast description.

Lisa:
Awesome.

Richard:
Okay, so this is the podcast about teams. And I love to ask people about their life experience, the best team they’ve ever had in their life. Oftentimes people sort of default to a work team. But this could be anything, any group of two or more people that you’ve been a part of. What’s the best team that you’ve been a member of in your entire life?

Lisa:
Gosh, when you widen that outside of work, there are lots and lots of teams. And I’ve been lucky to work on a lot of really great teams. I work on a great team right now. But I have to say from 2003 to 2012, I had the opportunity to work on a team that, for me, was my utopia, because we made the journey from complete chaos and dysfunction to becoming a truly high-performing agile team doing continuous delivery successfully. And we were a very small team, but we achieved huge things. So it was a great opportunity. I learned so much. And it’s a lot of what I’ve shared in the books I’ve written with Janet, and courses and stuff like that. So yeah, that was a wonderful opportunity. And that was at a company called ePlan Services, back in Denver.

Richard:
And this team, I want you to take yourself back to it and sort of re-experience it, re-experience the people you were with, the activities you were doing together, and how it felt within your body to be with them doing those things. Could you summarize how that felt in one word?

Lisa:
Yeah, the one word … I mean, there are many words I could use, but the one word I think is maybe the most important way to describe it is trusting. Everybody on that team felt safe. And we’ve learned from scientific studies that psychological safety is a prerequisite to team success. And we definitely had that on that team. Anybody could express any idea or opinion, and it could be contrary to what other people had expressed, without fear that they would be disrespected or made fun of or damaged in some way. People might disagree with you, but it was not on a personal level, it was just objectively discussing the ideas. And that’s pretty rare.

Richard:
Yeah. And so subjectively, when you go back to this team, or objectively, what are some of the things that went into it that let you know that this was the best team of your life? What were the things that you felt subjectively, qualitatively? What are things that people from the outside could have observed?

Lisa:
Like I say, I think the safety aspect of, we would have meetings or just informally be sitting around discussing something together. And our brainstorming sessions, everybody could feel free to throw out ideas, and there was no, “Oh, no, I disagree with that idea.” It was just like, “Yes. And let me add to that idea.” And anyone could have an idea. And so one exciting thing for me about this team was the focus on quality and the fact that we generally had as many testers on the team as developers. And so it was a tiny team. So usually three testers, three developers, sys admin or two, a DBA.

Lisa:
And often, I can remember a meeting where we’re really struggling with this algorithm. This was a financial services application. And the algorithms around it were really difficult both to … It was about managing 401k plans. And so omni-bussing trays of mutual funds and then redistributing money back into people’s accounts to six decimal places, and also regulatory requirements. There was just so much that was super complicated. And there was an algorithm we just could not figure out how to implement the code. And one of the testers piped up, got up, started drawing on the whiteboard and said, “What if we did this?” And the developers listened and said, “That is the right way to do it. That’s what we’re going to do.” Because they couldn’t come up with that themselves.

Lisa:
Were on a lot of teams I’ve been on … Well, not a lot I’ve been on, but some teams I’ve been on, and a lot of other teams I’ve learned about, the testers wouldn’t even be in the room, because this is a design meeting. You know? Sometimes they can be very patronizing of, “Well, you’re not quite technical enough to be in this meeting.” So I really appreciated that ability for anybody to raise ideas, or issues. People could point out problems without fear of, “You called my baby ugly, so now I’m mad at you.”

Lisa:
But it was all done in an atmosphere of respect. And this extended to the business. It was a small company, but we really were part of the business. They included us in discussions about, “Well, what feature should we do next? What do you think?” We were not just over in a corner with requirements being thrown at us. So it’s a great feeling to be part of something that you really believe in, you want to make the company successful, you want to really help the customers. I mean, we weren’t curing cancer or anything, but helping people save money is good. And just knowing that everybody in the company was dedicated to solving the customer problems and giving them a great experience.

Richard:
Now, you shared a couple of the examples of behaviors that you engaged in together. Like somebody shares an idea, they get “yes and” instead of told to shut up. Or even just going from everybody was invited, right?

Lisa:
Right.

Richard:
What were some other concrete behaviors that you engaged in together as a team?

Lisa:
I think the fact that we were … It took us a couple of years to get there, but the fact that we always had a deliverable release candidate ready to go.

Richard:
Always?

Lisa:
Always. I mean, our build might fail sometimes, but every day it was going to be green at least once. We did not release every day, because that would have been too disruptive for our customers. We could have done it. We were using feature flags and things like that, but it wasn’t necessary. So we released every two weeks, or deployed every two weeks. But the fact that we could continually deliver business value that way. We were super good at slicing themes and epics not only down into stories, but into thin slices and end-to-end techniques like Jeff Patton’s story mapping, impact mapping from GEICO. We used techniques like that.

Lisa:
I’m just drawing on the whiteboard. We called it steel threads. We had this technique we called steel threads. And other people have said, “That wasn’t steel threads. That was thin slices or something.” I was like, “Whatever.” But it’s like, “Okay, we need to do a new feature to upload information into the database from CSV files. And there’s a five-step UI process that’s needed to do this.” And at first we did what lots of other teams do is, “Okay, well here, let’s work on the first screen. Okay, that’s done. Now, let’s work on the second page of this UI.” We realized that was silly because we’d get to the end of the sprint and we’d have four out of the five pages done and we could release nothing. So then we, “Let’s slice it down. Okay, we’re just going to do the navigation between these five pages.”

Lisa:
And that’s something we can show our customers, our internal customers and say, “Hey, does this look like the right flow to you? Do you need to go from page five back to page two? How does this look?” And then automate the test for that. And then gradually build onto that steel thread of, “Okay, now let’s add the ability to choose the file and upload it. Now let’s add some validation. Now let’s persist it to the database. Now let’s display to the user.” So we just built onto that. And it was so magical for us when we mastered that ability. Because, yeah, maybe we didn’t have all the final touches on it at the end of a sprint, but it was good enough to start with. People could use it. So those of kind things.

Lisa:
Teams really struggle slicing things down. And I’ve heard so many times, “Well, no, we can’t slice it down any smaller. We can’t make this story any smaller.” I mean, in my experience, a story should be something you can finish in a day or two, including all the testing and all the test automation. And most teams really struggle to do that. I’m trying to think of any other … Well, the other thing was mastering the core practices of … We were a self-organizing scrum team, and we decided to adopt the extreme programming practices because they had been shown … This was back in 2003, 2004. They had already been shown to be effective. We wanted really high quality. We committed to that, and those were ways to deliver quality. But it’s like, “Ah, tester in development. Oh, that turns out to be really hard to learn.” Which I knew, because I’d worked on other teams who’d had to learn it. And that takes a lot of time.

Lisa:
Well, fortunately we had enlightened business executives who hired us to develop software and left us to it, supported us. Like, “You do what you need to do. Oh, you can’t deliver a big ton of stuff right away because you have to stop and learn these techniques? That’s okay, because we want to do it right. So let’s slow down to go fast, and go fast later.” Focus on quality, not on speed. And so we mastered these core practices. We mastered continuous integration right away. It took a long time to master test-driven development, but we did it. Refactoring, test automation … I’m trying to think of all the practices off the top of my head. But we had the chance to do that and make that investment.

Lisa:
And then the fact that it was a whole team approach to quality, in real life. And one of my favorite stories is … This was after several years. We had a really thin client. It was a Java application. And all the business logic was on the backend on the server side. But as people got more sophisticated after 2010, users wanted a nicer user experience, they wanted a faster response time. It’s like, “Oh, we should probably start putting some of the validation into the UI level itself, put some of the business rules there.” Well, the test tool that we were using for our UI level test automation didn’t support that. It had done a really good job for us over like eight years. We had a minimal set of smoke tests, but they were quite effective. But we realized that we needed something new.

Lisa:
And so we’re sitting around, all the developers and the testers are sitting around thinking about, “Okay, well, we have all these different open source tools and vendor tools. What do we want to use?” And we had neglected to invite the system administrator to our meeting. He was also a developer and very interested in testing. But he was just on the other side of the cube wall. So he pops up over the cube wall and he said, “You know what? I think that WebDriver, Selenium WebDriver will solve our problem. And I volunteer to do a proof of concept and see if that’s the case.”

Richard:
Beautiful.

Lisa:
“Thank you. We’re so sorry we didn’t invite you.”

Richard:
And he was attending the whole time, just on the other side of the soft wall.

Lisa:
Yeah, he was listening. And everybody was willing to jump in on whatever was needed. And conversely, I was willing to jump in and configure [Hudson 00:15:14] or [Jenkins 00:15:14] or whatever, work on the pipeline. Or I was happy to jump in and help the DBA with something. So that whole team approach, it really works.

Richard:
Yeah. I want to go back to one of the jargon words you used, make sure I understand it the right way, and listeners understand it. You said steel threads. I’ve definitely thrown this phrase around, and I’ve worked with people who used it. Will you describe what that means?

Lisa:
Well, the way we saw it is, we’re going to do something end-to-end, but a very thin slice of it. My dad was in the steel business. And that’s like one little cable, one little end-to-end wire. Now we’re going to add something to it, so we’re going to wrap another wire around it. And now we’re going to add something to it, and we’re going to wrap another wire. So we saw it as kind of building a cable. Apparently, people use that to mean something else that, and I’m not sure what it is, honestly. But people might call it tracer bullets. I think some people call it tracer bullets.

Richard:
I know that phrase, yeah. This is what you meant. I love this idea of a steel thread versus a tracer bullet, because, like you said, you’re going to coil another thread around and keep adding on. Yeah.

Lisa:
Make it stronger, more useful.

Richard:
Yeah. Cool. How about some advice for listeners? If somebody asked you for advice on how to reproduce an awesomely successful team like this one, what would you tell them?

Lisa:
Well, unfortunately, there’s no shortcut. You have to make a big investment. First of all, I always tell people, and this is what my teams have always done too, is start by everybody get together. And what level of quality do you want? It’s like mom and apple pie. Everybody says, “Oh, with the very best quality.” And I’ll ask the executives this too, and, “Oh, it’s the very best quality.” But they don’t know and understand what that means. And things are going to get in your way, and you need a really strong commitment, so that you have the discipline to keep working at it, and work on that obstacle, find some way around it, some way to make it smaller. Do the experiments to see how you can overcome them. And it has to mean something. The commitment has to mean something. And so when your team has that, then you’re going to figure out the problems.

Lisa:
But you also need the support of management. So if management is just snapping the whip and saying, “Okay, we need this feature by this deadline, get her done. And don’t waste any time on those tests. You can do those later.” First of all, they’re telling us how to develop software, which is not okay, because that’s our job. They can tell us their business priorities, and we can tell them what we can do about it. One of the things that my team at ePlan did so well was, we invested a lot of time in learning the business domain, which was extremely difficult. We actually budgeted story points during sprints to sit down, work alongside the accountant, the customer support rep, the sales person, so we could really understand what they needed. Because guess what? Our product owner, who was the company lawyer, did not understand finance or accounting or …

Lisa:
And once we knew the domain, they’d ask us for something and we’d say, “Why do you want this? What business problem are you solving? What’s the purpose? And they’d explain it and I’d say, “Okay, here’s what we could do. It’s about 80% of what you say you want, but it’ll cost half of doing the whole thing.” Oh. And then we looked brilliant and fast. We weren’t doing anything faster. We were cutting down what needed to be done. And you need the domain knowledge and expertise to be able to do that.

Lisa:
I’ll never forget, one time our product owner came to a meeting and said, “Do you remember that feature you did a while back to provide discounts to new customers?” We’re like, “Yeah.” And he said, “Well, what we need is a negative discount. We need the ability to have negative discounts.” We’re like, “What? Can you explain what you want?” And they said, “Well, we want to add some services that cost more, so we want to charge a surcharge for these things. So if you have a negative discount, that’ll be a surcharge.” And we’re like, “No. No, we’re not doing negative discounts, but we could do surcharges for you.”

Lisa:
The business people, especially product owners that get used to how you work, they come to you with the implementation because they think they know. And they want to get it done fast, so they think that if they’ve already solved the problem for you it’ll go fast. So I think I got really … I digressed a lot there. But it’s the investment. Investing time to learn the domain, investing time to learn how to do test-driven development, investing time to learn how to automate tests at the API level or the UI level, or do behavior-driven development, are all these good practices that we know.

Lisa:
We have things like the State of DevOps survey and other scientific studies that show these things really do work. Why doesn’t everybody adopt them? I don’t know, because change is hard. And because business executives don’t understand the need for the investment and how it will pay off. And people are really focused on short-term results. I was with that team for almost nine years. And it was so exciting, first of all, to see what we could accomplish. But second of all, this team, we always ran into new problems. We never ran out of problems to solve. So you have to build up those muscles and be able to keep addressing those problems. And if you’re really focused on quality, and everybody is really thinking how to build that quality, and that’s the secret sauce. But it’s not magic, it’s just a lot of discipline and hard work.

Richard:
I love it. I hear this from a lot of other guests as well. The XP practices. A lot of my guests are people from the software development field, so the XP practices for a lot of people. And then investing time into learning the domain, learning the techniques and the tools, and focusing on quality. Cool. So I know you’re busy with mabl, your new company, you’re writing books. Is there anything else you’d like to add that you want to make sure listeners hear about?

Lisa:
Well, just one thing I wanted to add, we talk about work and, make it sound like work, but we need to enjoy our work, too. Back when we had those four XP values as well, which the values and principles were more important than the practices even, but people used to say, “Well, the fifth value is enjoyment or joy.” And we do need to enjoy our work. That’s why I do this. I enjoy making a contribution. I enjoy helping the customers have a better day. And also as part of that, I went to a workshop at ConTEST, New York City. It’s a really great testing conference. And one of the workshops I went to was not by software people, it was by these training company that I can’t even remember what the workshop was about.

Lisa:
But one of the things that they said is, that most people don’t like their job. And the number one reason is they don’t feel appreciated. So let’s start appreciating each other. Tell somebody, “Hey, that thing you did there was awesome. Or you helped me when you did this.” Specific appreciations. People might think I’m just too Pollyannish, but I think it’s important. I want to feel appreciated. At first I thought, “Well, that’s … ” I’m kind of hard on myself because I’m definitely an approval junkie. I really want other people to acknowledge that I did something good. And that doesn’t seem healthy. But you know what? Appreciation, why is that bad?

Richard:
I love it. I love it. I love it. I’ve just realized in the last couple of days that my focus in life right now is joy.

Lisa:
Awesome.

Richard:
How do I maximize that in my life, my work, my relationships with everybody? And I love this idea of specific appreciations, and what a beautiful web that would connect between people.

Lisa:
Right. Yeah.

Richard:
All right. And if listeners would like to get in touch with you, is there a way they can do that?

Lisa:
Absolutely. It’s probably easiest to get my attention on Twitter. I’m @lisacrispin on Twitter. I’m also @testingindevops on Twitter, because that’s our testing and DevOps account. But I’m Lisa Crispin on all the LinkedIn, and lisacrispin.com is my website. So that’s pretty easy to find. And lisa@lisacrispin.com email. The problem is that my inbox is a horrible, horrifying place, and I miss a lot of emails. So if I don’t respond to your email, tweet at me. I’m on a number of Slack channels as well. It’s getting harder and harder to keep up with all those. But I really value the social media. I have met so many wonderful people and learned so much thanks to Twitter and other social media outlets like Slack, Slack workspaces. And I know they can be a big time suck and stuff, but they also can pay off, as people can help you solve your problems, even total strangers. So it’s awesome.

Richard:
All right, Lisa Crispin at all these different places, and Lisa Crispin in real life. Lisa, thanks so much for joining me today. Really appreciate your time. I loved this conversation. Thank you.

Lisa:
Thank you.

Richard:
Hi, friends, thanks again for listening. And remember, to support this podcast, visit my website, kasperowski.com.