Episode 75: Elisabeth Hendrickson on How to Do Agile Development the Right Way

Brian Dawson: Hello. This is Brian Dawson with another episode of DevOps Radio. It's my pleasure today to have Elisabeth Hendrickson, most recently of Pivotal Labs, here to talk to us about some of her lessons, learnings, and her journey prior to and at Pivotal Software, as well as sharing some of her wisdom and expertise that she has lent to the larger community around agile and modern software development practices. Elisabeth, hello.

Elisabeth Hendrickson: Hey, Brian. Thank you so much for having me.

Brian Dawson: Thank you for joining, and I won't try to pretend like we didn't have a bunch of great conversations before we started. We did. So I'm really happy to now hit the record button and get everybody else involved in the conversation. 

Elisabeth, I could try to review your background for the audience, but I probably won't do it justice. So what I'm gonna ask you to do as a start, can you give our listeners a brief overview of your role, kind of what you do and your career background? 

Elisabeth Hendrickson: Sure. The super-high-level view, most recently, I was VP of R&D at Pivotal, as you said. Probably the biggest thing that I did there was being responsible for the data organization that created databases like Greenplum and GemFire/Apache Geode.

Prior to joining Pivotal – I was there for seven years. So I joined Pivotal Labs, as you said, prior to Pivotal being spun out. Pivotal was more than Pivotal Labs. It was an enterprise software company. It was very recently acquired by VMware. So I was there prior to it being spun out, and I was there all the way up until the point of acquisition. 

Brian Dawson: That was a journey I'm sure.

Elisabeth Hendrickson: Oh, yeah. It was an amazing, awesome journey. I'm so grateful that I got to be part of it. 

And prior to that, I was running a tiny, little boutique consulting company, where my job was to get on airplanes and go help people make better software. Before that, I kicked around the industry for a while, because I'm kind of old. I wrote my first line of code in 1980. 

I have been working in the tech industry in some capacity or another full-time since 1988. I've been a developer, a technical writer, a leader, test automation, QA. I've done a bunch of stuff. So, hopefully, that's enough to work with.    

Brian Dawson: Oh, I can do all kinds of things with that. First, I'll call out a couple of things that I find really interesting. Technical writer, QA, leader, developer, you've worked in a range of roles in software development. What I'm gonna do is I'm gonna go on a series of questions and ask about how some of those experiences have informed your most recent work.  

We talked a bit about how QA informed that, but I'm curious to find out do you find that there is value in serving in a range of roles in IT? I know a lot of people come in. There's a heavy focus on specialists, "I am the best Go programmer that you are ever going to find, and I focus on writing cloud applications using Go," which is very different to what the span of your career looks like. 

What's your thought on that? Do you feel that that has offered you a unique perspective, value? Is that something people should consider? 

Elisabeth Hendrickson: Yeah, absolutely. As I say that though, I want to make sure that I emphasize my first role in 1988. Most people listening probably weren't even – may not have even been born in 1988.

Brian Dawson: Oh, you're young. 

Elisabeth Hendrickson: [Laughs] oh, you are so sweet. So I value specialization tremendously, because I think that there is something really important about being able to go super-deep on a topic, whether it's get amazing at CSS or get amazing at test automation, or get amazing at Go or whatever. But, at the same time, when you have a career that spans multiple decades, at some point, unless you go so deep that you are like the one world expert on, like, optimizers for relational databases or something, there is a high probability that you will end up tackling a new challenge, and that new challenge may end up being adjacent, a little further adjacent than you might have thought.

The way I ended up in QA was actually because I had worked at Sybase as a technical writer, but my emphasis was on technical as opposed to the writer part. So I was also writing a bunch of samples. So I had gotten to know how to work with the database relatively well. 

Then I ended up taking a contract with the QA department at a small software vendor, where they were really struggling with how to reset environments so that QA could do testing. This was a really long time ago, before it was typical to have things super-automated, and they were spending so many hours every single week just tearing down environments, so that they could reestablish them, and then put all of the data back in. They were doing all of this in a very manual kind of way, and they wanted somebody who understood to bulk copy out and bulk copy data back in, so that they could reset. 

So I ended up in a role that I – I didn't even know what QA really was. I knew that Sybase had a QA department and I kind of knew what they did, but when I took the contract, I really didn't understand what QA was. It was just – you know, it was a natural adjacency.

So to come back to your original question, though, has it been valuable for me to see the world of software development from all these different perspectives? Oh my goodness, yes, because it gives me that holistic systems-level view of the whole arc, from inception through the entire lifecycle, and the way that people then have to deal with the consequences of the decisions that we make, and it gives me so much more empathy for every step along the way. 

Brian Dawson: Oh, I'm so glad you hit the word empathy. That was spinning around in my head. It's funny. When I saw a technical writer – you remember I was thinking about – early on, I worked on the PlayStation. 

Elisabeth Hendrickson: Yeah.

Brian Dawson: And the technical writing team was in the team that I was in, some awesome people. I remember our manuals. I have them somewhere in the room. We used to have manuals for development for the PlayStation, that when you stacked them up were like this tall. People can't see, but you're talking about 20-plus inches and probably 50-plus pounds of … So technical writing has changed since that time, wouldn't you say?

Elisabeth Hendrickson: Yes. I definitely would. 

Brian Dawson: Okay. So another question is QA, you talked about this holistic perspective. It's very interesting to note that you went, after that journey at Sybase, kind of stepping in and helping the quality assurance team for a long period. You built a career out of QA. You went really deep into quality assurance. Then your focus on continuous integration, XP, extreme programming, et cetera, that took place at Pivotal or Pivotal Labs. How was that informed by the time that you spent in quality assurance and engineering?

Elisabeth Hendrickson: The way I ended up at Pivotal Labs, I met Pivotal Labs as a company in about 2004 or 2005. I forget the exact year. But I had met Rob Mee, who founded Pivotal Labs, at a small, little peer conference. We had gotten to talking. I had been learning about agile. I had been learning about extreme programming. And I was absolutely intrigued by everything that he said. The way I refer to it is I weaseled my way onto a Pivotal Labs project at the time. 

So at the time, my job was to get on airplanes, go help people. I was running my tiny, little consulting company, but I carved out three months to just be with a team and be a member of the team for Rob's company. I refer to it as ruining me for working any other way.

Now, the thing to be aware of though, like why did I want to do that? Because I knew from all of the time that I had spent in QA that what we had been doing as an industry was not working. It just flat out wasn't working. I was on a quest to go figure out a better way. 

I had most recently, prior to starting my company, worked for a vendor where I was the director of quality engineering. It's a role I swore I would never take again. The way that we divided, it drew that line between development and quality in such a way that it not only absolved the developers from having to think about those gnarly problems with testing, and I had seen this over and over again, but this was the most egregious example of it.

I actually heard cases where managers would be chastising programmers for spending too much time testing, "What are you doing? What are you doing still testing that thing? We are behind on the schedule. There's an entire group over there whose job it is to test that thing. You need to set that down and let them go test it, while you go work on the next thing." 

We had severe quality problems, and I actually ended up writing a paper that came out of that experience, plus a bunch of other observations and conversations with other people called, "Better Testing, Worse Quality." It was a Best Paper at SQE conference.

The core of the paper is around a diagram of effects that shows what happens. The theory is that if you have perceptions of low quality, if you put more emphasis on independent testing, you'll find more bugs. You'll fix the bugs and you'll get better quality. 

But the side effects that people don't realize is likely to happen is that developers, who may have been doing testing before, are now gonna be doing less testing. So you've got a more target rich environment in which to be doing testing. So it looks like QA is doing an amazing job. They're finding all these bugs and you're fixing the bugs, but they're actually finding the bugs so late in the cycle – the feedback cycle is really, really long – it's too late to fix them all.

It is the lowering of all of the quality activities earlier in the cycle that results in worse quality, even though you're theoretically investing more in testing. So that's the TLDR on the paper. 

So coming back to your question about how these things are related, recognizing that what we were doing as an industry was not working and seeking a better way. That led to my entire agile journey, and Rob Mee and his team at Pivotal Labs totally ruined me for working any other way and I was never gonna go back. 

Brian Dawson: I heard that aside from process and practices that Pivotal is a really special, really different place to work, or at least at a certain point in this lifecycle it was. I do wonder if – I talk a lot or I believe and tend to find consensus with people, saying that at the end of the day, tools, technology, process and practices ultimately are there to support people and culture. I wonder if the way that Pivotal spoiled you is probably also how it ended up having a really unique kind of people and culture.

Would you comment real quick? I know I have something else I want to dig into, but do you have any comments on that interplay between process and practice and people and culture, and what you guys built there at Pivotal?

Elisabeth Hendrickson: Sure. I think that's absolutely true. Part of my observation about the way that Pivotal worked – I should also explain. So that first contract in 2005 or whatever it was, led to my coming back periodically, while still running my little consulting company. I would come back periodically to do another contract with Pivotal Labs. It never made sense for me to join full-time at that point, but I always felt like I needed to come back and remember, "What is software development supposed to feel like?" 

Each time I did, I would be reminded of how the entire point of all of the practices was to make it so that there was as little friction as possible between getting ideas in your head into the code base, in a way that was shippable. It's not enough to get the ideas into the code base if you can't ship it, because it's this giant mess and, yes, that's a lovely little method right there, but the rest of it doesn't work at all.

So all of the practices around pairing and test-driven development and continuous integration, all of the incredibly disciplined engineering practices that we had ultimately were in support of human creativity. It wasn't about process for process' sake.

Whereas what I had seen in the industry before, where you had these stages and sign offs and, okay, we're in the analysis phase until we get sign off that we've got the right requirements, that is nothing but a series of roadblocks to get ideas into software. So this concept of every practice that we do is about smoothing the path, and making it so there is less friction to go from innovation to delivery. That was absolutely astonishing to me and you are correct, one of the reasons why it broke me for working any other way.

Brian Dawson: I'm gonna pivot real quick because we are – 

Elisabeth Hendrickson: I see what you did there.

Brian Dawson: Pun intended – and my wife says I'm not clever. So I want to go back to process and practices, but we can't ignore the fact that right now, this week as we're recording this episode, we are in a really special time in terms of this country, right, which also happens to align with – and we're talking about some of the Black Lives Matter activity, some of the awakening around racism and the system. That's being paired with this really almost once in history experience with Covid, which then, interestingly enough, is all wrapped in a period of extreme technical innovation and digital transformation across industries. 

So I do really want to dig in at kind of this intersection with you of diversity and tech. We can go as deep in as we want, but in particular, I really want to call out for our listeners that Elisabeth was last a vice president of R&D at Pivotal Software, ran her own company on the way there, has been in technology and coding, if I recall correctly, since about ten years old I believe it was. You can correct me. Is that right, when you wrote your first line of code?

Elisabeth Hendrickson: I was 13 when I wrote my first line of code.    

Brian Dawson: Okay. And I hate saying it, but similar in some sense as to being brown and black and my role here in the industry, you're, unfortunately, a bit of a unicorn. You don't see many female or people that identify as female as VPs of research and development, and really leading the charge in the industry. Now, there are many out there doing a great job and having a great impact. I guess what I would say is not enough, right.

So I'm really curious, if you could just spend a minute telling me about how you got to where you're at. How did you end up in tech? Then you could even, if you're so inclined, tell me a bit about your thoughts on diversity in tech. 

Elisabeth Hendrickson: Sure. Well, I think the story of how I got to tech is fairly short. My dad came home with a TRS-80 in 1980. 

Brian Dawson: You're a poet and you didn't know it. 

Elisabeth Hendrickson: Yeah.

Brian Dawson: Sorry.

Elisabeth Hendrickson: So the TRS-80 was – I mean the one that he brought home had 4K. I'm not misspeaking, 4K of memory, no disk drive. The way you saved your work was you saved it to a tape drive, and it was a cassette tape drive, like the same kind of thing that – well, many people listening to this might not even know what a cassette tape is. Let's just say it's a form of media that you probably will never see in real life anymore. But it was quite the thing in its day though.

My dad basically said, "Hey, kid, computers. Computers are the future. Here is one. You're gonna learn how to code with me." He brought it home because his work was computerizing at the time, and he decided that I was going to learn how to code. Fortunately, I really loved it. I absolutely loved being able to make the machine do what I wanted it to do. So that's how I got into it. Yes!

I did have several years where I got out of it again, because I got frustrated and – I'm gonna skip all of the stories, but I'll just say that I left technology for a while. Then I went back into it and ultimately ended up forming my career there. So for my very first full-time job I was in tech. I worked as a technical writer at a chip manufacturer, documenting the pin diagrams and et cetera. That was in 1988.

So now let's talk about diversity in tech and some of the things that can happen.

Elisabeth Hendrickson: I don't know if you would have had or seen similar kinds of stories, but I decided to leave school for a variety of reasons that don't matter. In my first attempt through, I did not graduate. I did later finish my Bachelors, but at this point, I was a dropout. 

There was another friend who dropped out at the same time that I did. I got a job as a tech writer. He got a job as an engineer. We were in the same school, in the same program. Now to be fair, he's brilliant and he absolutely deserved what he achieved. 

Brian Dawson: You're not discounting – right. 

Elisabeth Hendrickson: I'm not at all discounting. In fact, I can look at the situation and our respective backgrounds and understand why maybe he got that opportunity and I didn't, but I saw that same thing happen a fair bit. And I think it very much still happens today, of gently pushing the people who don't quite fit the mental model that some people have of what a programmer looks like, gently pushing them into other areas that feel like they're maybe a little bit more soft skilled oriented or maybe a little bit more – and it's not to say that there is anything wrong with those professions, nothing whatsoever. They are fabulous professions.

If you're passionate about whatever that thing is, I don't want to take anything away and say, "Oh, but you shouldn't be there." It's just the gentle and relentless push that I got towards things that were not hardcore engineering that, in hindsight, I find fascinating. 

So when we look at diversity, yes, absolutely I am passionate about diversity in tech and representation is so critically important. If you look around and you don't see anybody who looks like you, you don't have a mental model of what it looks like to be a woman, because that's the life experience that I've had. So I don't know what it's like to be black, and look around and be the only black person in the room. I can't even begin to imagine, other than through my experience of looking around and realizing I'm the only woman in the room. 

Brian Dawson: Well, I think it's interesting and I'll risk commenting. It is so passionate. I'm very passionate about it. But look, I think human psychology is human psychology, right. I always talk about that we are constantly building a perception of ourselves, by almost the equivalent of sending sonar pings out to the world, seeing what looks like us and reflects back. How do people react to us and reflect back? And over that, we're constantly forming, trying to identify who we are. 

It's funny you use the word model. I use that a lot as well in work that I do with high school athletes of color. It's just so very important at showing the art of possible within our career. When I see a rock star coder that looks like me, subconsciously I'm going, "I can be that person, too," but also feeling welcome when you come into an environment.

I won't dig into it, but I'll say there are a lot of similarities in what you covered, and I'd like to thank you just for being you, and achieving what you've achieved in this space, coming on and talking here. Because as easy as it sounds, Elisabeth, sometimes just being that mental model for somebody else helps immensely, providing that reflection. 

Great. Thank you for sharing that. I know I kind of cheated on Elisabeth, because none of these were prepared questions. So I completely made her go impromptu. 

A lot of your work, as we've talked about, really going all the way back to going into the QA department, to your consulting business, to what you've done at Pivotal and Pivotal Labs has been focused on working with organizations to transform their software development and delivery practices. What are some key components that are there in implementing or facilitating those transformations? 

Elisabeth Hendrickson: To talk about that, I have to step back a little bit and say what I mean when I say agile. Ultimately, I did learn this through my experiences, plural, at Pivotal Labs and with other organizations that were on their journey for transformation. I ended up distilling it down to what I referred to as the Agile Acid Test. So when I talk about agile, what I mean is delivering a continuous stream of value, at a sustainable pace, while adapting to the changing needs of the business. 

Ultimately, it turns out that's not terribly original. It is a distillation of the 12 points behind the Agile Manifesto. But the reason that I distilled it down to those three things is that at that point you can talk about the key components of a transformation. 

Delivering a continuous stream of value. I talked about how the phased development approach, the waterfall boogeyman, nobody actually does waterfall anymore, but that very phased approach is the antithesis of delivering a continuous stream of value. You're doing big bang delivery, so getting to the point where you can deliver monthly.   

This is one of those things that we worked really hard on with the database products while I was at Pivotal, moving from a model where we would GA, general availability, releases. There were some of our products that we would GA like every 18 months or something, and getting to the point where we could have GA releases every month. 

That doesn't mean that we went faster. That means that we delivered capabilities sooner, so that we could get the capabilities into the hands of our customers in smaller increments. So that continuous stream of value is all about finding the right way to incrementally deliver sooner to your customer base, so that you can get that feedback faster. 

That second piece of at a sustainable pace, well, it turns out that just delivering monthly doesn't work if you get to the point where either it's not sustainable for the humans, because every month you're doing a death march. That doesn't work. Or it's not sustainable for the code base.

We did have some interesting challenges, where we started running faster than our legs could carry us, and we were accumulating technical debt even though we were trying very, very hard to have incredibly disciplined coding practices. It is still all too easy to fool yourself into believing that you're doing that and you're actually not at a sustainable pace, and eventually it becomes apparent, when several months down the line you realize that you have less faith in releases than you did, say, six months ago.  

So that sustainable pace piece, it's about the humans. It's also about the software and working in a way that allows you to continually clean as you go.

Then finally, adapting to the changing needs of the business. You can deliver a continuous stream of value and you can deliver is sustainably, but once upon a time, when I was a consultant, I was working with an organization that was adopting scrum. I talked to one of their former project managers, who had been turned into a scrum master, and they were so proud of their sprint plans. He said, "Do you want to see them?" "Them, plural, huh, what?" 

They said, "Yes, here's the sprint plans," and they rolled out – I'm serious – multiple sheets of 8.5x11 sheets of paper taped together to show the plan for, "Okay, this is this sprint that we're working on now, and we're working on this set of capabilities, and so on. It was a Gantt chart, basically, but they were doing – 

Brian Dawson: In two-week increments. It was like a two week Gantt chart.

Elisabeth Hendrickson: Right, exactly. They were doing scrummerfall, and here's the problem with that. First of all, you just don't know what you don't know. So that plan is gonna be irrelevant as reality starts to show what is gonna be.

But the second problem with that is part of the way that Agile gets rid of waste is by making it so that you don't build the things that it turns out nobody would have valued anyway. So that feedback, the fact that you're delivering continuously and at a sustainable pace enables you to get the feedback, so you can steer toward value. 

Brian Dawson: Right.

Elisabeth Hendrickson: So that's why adapting to the changing needs of the business is so absolutely critical, because as the world shifts – and oh my goodness, 2020, have we seen the world shift so many times. This year feels like it's at least three decades long. 

Brian Dawson: Yes. 

Elisabeth Hendrickson: As the world shifts, you have to be able to adapt your organization. As I think you kind of alluded to this at the beginning, every company is a software company now. It's not just about being a software vendor. It doesn't matter what you do. And that's even more true now, when we're all working out of our homes, doing all of our meetings online, ordering everything that – e-commerce had already exploded, but you can't go shopping anymore, right. 

Brian Dawson: Right. 

Elisabeth Hendrickson: So every company is a software company, even if they thought they weren't. 

Brian Dawson: Yeah. Gosh much, yeah. It's fun just to riff on that a bit with you. It's starting to sound cliché. All the vendors go out. We put a slide up. Every software is a software business. People have started to fade away from Andreessen, "Software is eating the world." 

You know what? As cliché as it may be and as tired as people may be of hearing it, it becomes ever more true and ever more apparent. I love to share the story of a buddy at work asked me to – he said his cousin was looking for a job. He wanted to talk a bit about agile, CI/CD.  

I think I'm calling into Canada. I dial this number. Little do I know, I'm actually dialling Jamaica, and I'm on the phone with a guy that works at a poultry processing plant in Jamaica. And he's telling me about how he uses Jenkins, about how they're rolling out agile practices, and they're using continuous integration and continuous delivery.

Now look, they're not Uber. They're not Instacart. They're processing poultry in Jamaica, but software is at the core of their business to help them deliver more. There's few things I could think of more extreme, as examples of software helping.

Then I'm gonna shift to feedback, but I think one of the things that you hit upon, if we look at what we experienced with Covid-19 and how rapidly people had to respond to changing business needs, how rapidly some people did respond, whether that was from just UX, UI or rolling out completely new features, it was impressive. 

That takes me to the argument that some people will say. Certain businesses just don't need to deliver that frequently. Iterative development for somebody that has like financial services, a customer with a stale product, our customers can't bear a new update every month. Or they can't bear a new update even every three months.

What do you have to say about that, especially in consideration with what people have achieved during Covid?

Elisabeth Hendrickson: For that, I'm gonna lean into my experience leading the data organization at Pivotal. Because certainly databases, you do not want to be updating your database "just 'cause." You don't. So I totally get that there are circumstances where as the customer from the software vendor, you don't want to be updating that frequently. But a couple things. 

One is except when they did want it. So if they had found a problem of some kind with the database, then they wanted to be able to update immediately. So nobody wanted to update until they wanted it, and then they wanted it immediately. And if you are a software company delivering to – if you're an enterprise software company delivering to enterprises, you've got hundreds, if not thousands, of customers who all want different changes, which means you better be able to shift very, very frequently. 

You also need to be investing and ensuring that upgrades are safe, and that customers can skip upgrades if they need to, because they have blackout periods where they can't update during a given period of time. But as a vendor, you absolutely need to be able to deliver very high quality software on a regular basis.

As an enterprise, if you're not thinking about being able to update frequently, oh goodness gracious, are you going to have problems with security, because the reality is that we live in a different world than we used to live in, and security vulnerabilities are being exposed constantly. I think we've all seen that in the last several years, which means that even if you think, "Well, we are a financial services firm and we have an entire process for qualification before we roll out this update," yeah, the hackers don't respect that process.

So if you have an old version of, say – what was it? Was it Struts? Was that what was at the core of the Equifax breach? I can't remember. 

Brian Dawson: I don't recall correctly. 

Elisabeth Hendrickson: I may or may not have the details right on that, but the fact was that several of the biggest breaches have been traced to software that had not been patched recently. So that's what I would say to that. You think you don't need to, but it turns out the world is moving faster than you are, and so you actually do. 

Brian Dawson: I love that quote, yeah. I think a lot of us are familiar, at least a certain age are familiar with emergency change request processes or ECR processes. Why not just make your process as fast as what would be an emergency change request process? You can respond quickly.  

And feedback. Actually, let me put this in a higher-level way, first from my opinion and experience. I feel like agile for a number of years was mis-implemented, mis-framed. People attached to the concept, but really didn't embed the definition of done. I.e., it's not just about how we plan things, but it's also about how we deliver things. 

Then as well as that, somewhere along the line, as agile, CI/CD wrapped in a DevOps concept really got caught up, the core tenet of all of those practices being focused on fast feedback seems to have gotten lost. I hear a lot of people just talk about fast. The speed, in my opinion – and correct me, add in, pontificate – the speed is not there just to be faster. There are benefits to it. But feedback is a critical part, right? 

Elisabeth Hendrickson: Absolutely, and what people couldn't see was the face that I was making. 

Brian Dawson: Yeah, that's it.

Elisabeth Hendrickson: Just the face of, "Ow, ow, ow, that hurt." Really, agile done badly is dangerous, just flat out dangerous. 

Brian Dawson: Really? How? 

Elisabeth Hendrickson: Well, because if you don't have any form of feedback and you're just focusing on fast, you will end up shipping stuff that doesn't work. The thing that makes agile work are the disciplined engineering practices that CI/CD is a super-critical part of.

So feedback is absolutely essential because going – my focus was always deliver sooner, not faster. Everything that we deliver, we're going to do well. So everything that we deliver, we're going to deliver safely. 

I'm not sure, because I'm still focused on wincing from the – 

Brian Dawson: Yeah. Just really the journey. People started to implement it and roll it out, brought in agile coaches, but at times it didn't involve the QA teams. Operations wasn't involved. It didn't involve retraining of the developers. It was like something project managers adopted. 

Elisabeth Hendrickson: Yeah. 

Brian Dawson: Yeah. Then we were talking about then as that grew, people not building in feedback loops and thoughts on that, right. 

Elisabeth Hendrickson: Yeah. I want to touch on that. There was a long period of time when the focus for agile was all on developers. Honestly, since I had such a background in QA, as I got more involved in the agile community, people would reach out to me to say things like, "I don't even know what to do with this QA group. Then there were other people who were saying, "Well, that's okay because it's really about development."

You asked at the beginning about my perspective, because I have this sort of holistic, been around the block 17 times view on the industry and how important it is to involve everyone. So I'd like to tell a story that happened a really long time ago, and it may have happened in multiple organizations. So this may be one of those cases where people hear it and think, "Oh, she's telling our story." Whoever you are, I'm not telling your story. I'm telling someone else's.      

Brian Dawson: It's not you, right. 

Elisabeth Hendrickson: Because it's happened in so many places. I got involved with an organization that was adopting agile. In this case, it wasn't about QA being separated out, because they had integrated QA in development into happy cross-functioned teams. But ops sat all the way on the other side of the building and was not involved at all.

There was this group that had a web thing that they were ready to put live on the website. The business stakeholders who wanted it were super-excited to get it out there, and the developers were sure that they were ready. The overall development team, they were ready and super-excited to get it out there.

I entered the scene just at the point where they had started the conversation with the operations team to say, "Okay. So we go live Thursday. Yes?" And the operations team said, "Well, hold up there. Here is a three-page checklist. You fill all of this stuff out and we'll talk." 

In hindsight, as I look at that experience, I realize that certainly there were challenges on the operations side. They were gonna have to manually provision DMs. They were manually managing their environment. They didn't have a lot of the kinds of structures in place that we consider today to be the way that you would normally manage this kind of environment. It was not configuration as code at all. It was configuration as Sally in the corner goes and configures things. 

But the developers also had zero awareness of the implications of what they were trying to put into production and how it might possibly, in some way, interfere with other things that were in production, like zero awareness on the impact with respect to network configurations and whatever else. 

So you're absolutely right I think, in the early days, but I also think that persists today, that there is a desire to say, "Okay, draw a little boundary and say within this we get to be agile, and we're just not gonna worry about those other people." 

Brian Dawson: Yes.

Elisabeth Hendrickson: I think as an industry what we're seeing is that we keep having to – and I'm taking my hands and expanding out the circle. 

Brian Dawson: Expanding them out in increments. 

Elisabeth Hendrickson: You have to expand it out. Ultimately, and this is coming back to a continuous stream of value at a sustainable pace, while adapting to the changing needs of the business. It turns out that applies throughout the entire business, all the way out to HR. If the only time people get feedback is once a year at the performance review stage, they can't adapt to the changing needs of the business. So it has to push its way all the way out and encompass the entire mindset of how we operate.   

Brian Dawson: That is – a couple of comments and that's a perfect segue. It's funny. I have a lot of friends in QA and my career started early in QA. I remember five, ten years ago them coming to me, "Brian, what's this agile thing? Dev just implemented agile." They just implemented CI/CD and no one ever talked to us. I had people saying, "So now we're expected to do an entire set of regression tests in two-week increments." So to them, all it was was they just need to test everything more often. 

But I do have a colleague of mine, Viktor Facic, that very boldly states that you can't do DevOps – kind of an extension of what we're talking about here – truly do DevOps without a reorganization, without kind of turning your organization upside-down. So I think that resonates with that. 

What also resonates is in your blog you pretty extensively cover motivation. So we talk about HR and reviews. You also earlier mentioned that people are working remotely now, which could also affect motivation. In context of where we're going as an industry, also in context of current time, do you have any suggestions as to how leaders and peers can help teams stay motivated?

Elisabeth Hendrickson: Yeah. It boils down to celebrate the good stuff. One of the things that I realized as I got farther into my leadership journey is the extent to which it is – it seems to be human nature to kind of focus on extinguishing that which we don't want, so cutting out the things that we don't want, punishing the things that we don't want.

I, both in transforming organizations, but also just in running at stable state, what I came to learn was that you want to feed that which you want to see grow. Celebrate the good stuff. Highlight the good stuff. That is a much more powerful force than attempting to extinguish that which you don't want. 

I think that applies to so many things, from amplifying voices that we need to hear more of, and creating visibility for the people who are frankly already there, but they're not visible. Oh my goodness. If I see another all white man panel, I'm just gonna lose it, because there are so many people out there with so much to contribute. So that would be my general advice. Celebrate the good stuff, and feed that which you want to see grow.   

Brian Dawson: Interesting, very, very interesting. I was getting ready to make the tie to current things. I'm just kind of gathering myself for a moment. 

Do you have specific examples that maybe you've practiced or you've seen others practice, examples of feeding that which you want to see grow in any domain? Is there anything that you can share that our listeners might be able to go attempt to apply today?

Elisabeth Hendrickson: Sure. Let's talk about what feeding is first. Feeding, if you happen to be in a leadership position where you have power, authority, and budget, you can do a different kind of feeding than if you are an individual. But that doesn't mean individuals can't amplify that which they want to see grow.

My friend and colleague, Dale Emery, had this wonderful tweet recently on his feed about how somebody had thanked him, expressed appreciation for writing really good commit messages, and how that encouraged him to continue focusing on writing really good commit messages. So just expressing appreciation can totally feed something that you want to see grow. 

Now, if you happen to have some budget and the ability to therefore put some money behind that appreciation, you really can accelerate the feeding of that which you want to see grow. I'll pull the example from fairly early on in my work, at an executive level at Pivotal. 

I was working with an organization that historically had valued individual contributions, so the sort of hero worship, individual contributions, celebrating individuals. And we were struggling with collaboration. People had historically only been rewarded for pushing their own features all the way through, and if they collaborated with other people, it was sort of suspect, like, "But what did you really do," and that was affecting our ability to deliver. 

But there were some people who really loved it, because they loved working on their own and they loved being the hero, and they loved having everybody looking up to them. So it was very well entrenched. But I knew that if we were going to succeed as a whole organization that we were gonna have to shift that culture. 

So it never happens, but the finance people came to me and said, "By the way, you've got $5,000.00 leftover in your budget that you didn't think you had. How would you like to spend it?" That almost never happens. Nobody ever says, "Congratulations. Here's more money," but it happened in this case just at the right juncture in time, when I was able to say, "Huh. I know what we're gonna do." So I decided we were gonna celebrate collaboration. 

I put out an open call. Anybody could nominate anybody. You could nominate yourself. You could nominate your friends. Anyone can nominate anyone for an award that was gonna have money tied to it for radical active collaboration and going above and beyond. 

But the submission wasn't just, "Give me a name." It was, "And tell me a story." So we got all these phenomenal stories of people actively working for the good of the group, collaborating with other people, and we celebrated. Not only did people get their award in public, but we also celebrated all the stories. 

So that notion of stories as examples to follow I think was a really important part of helping people see not only what I as a relatively new leader in their organization valued, because I needed to telegraph, "How do you succeed in this organization?" But they also heard heartwarming stories that were just by themselves intrinsically positive examples. 

Brian Dawson: Right, positive examples. I'd say they do a couple of things. We talked earlier about mental models, which you just alluded to. Provide the model for how we thrive and function as a team. That would seem like sharing around some of those positive, sort of emotional expressions just naturally builds this connection and it starts to bond the team together. 

Elisabeth Hendrickson: It did, yes.

Brian Dawson: That is awesome. All right. This would actually be a good segue. I think you've heard of we've talked about this concept of DevOoops, D-E-V-O-O-O-P, a software challenge, or mistake that you've made or a challenge that you've faced during your career that you've learned from that has benefitted you as you've gone forward. So could you share a DevOoops moment with us that you've experienced? 

Elisabeth Hendrickson: You bet. I'm gonna share an entire category, but I'm gonna give you a personal example of it.

Brian Dawson: Okay.

Elisabeth Hendrickson: And I love the name DevOoops, just love it. The category is when a team believes comforting lies over objective reality, because lies can be so incredibly comfortable. My personal example of that, I was working for a startup. We had software that would run on PCs. We had gotten some reports that when our software ran on the PCs that the PCs performed more slowly, that basically our software was causing performance problems on these PCs. 

We had done a lot of work to try to ensure our software had a teeny tiny little footprint, very low memory, very low CPU. Because we had done so much work on that, we didn't want to believe it. So we would hear these occasional reports and we'd sort of collectively, including me, totally internally go, "Oh, well it couldn't possibly be us. They don't have any proof it was us. It must be that they're running something else on their machine." 

No, it was totally us, but I wanted to believe the comforting lies. I've seen this over and over again.

Another example that relates a little bit more closely to CI/CD is a team that I ended up coming in, so I was working actively with the team, but at the time that I joined, they were claiming that they were doing continuous delivery. Then they would say, "Well, not exactly continuous because we deliver every Tuesday and Thursday." I'm like, "Okay, well fine." 

But it turns out they had been working on a big rewrite of some stuff, and it turns out that what they – they were absolutely deploying all the code, but they weren't running the new processes. All of the new stuff that they were writing would run in its own process and none of that code was turned on. So it wasn't even feature flagged off. The processes literally were not running. It was only the old code that was running, but they were telling themselves, "Look how amazing we are. We're doing continuous delivery." 

So DevOoops, believing comforting lies that you want to tell yourself over objective reality. 

Brian Dawson: Those are great stories. Thank you for those. You guys can't see my face. I'm certain Elisabeth can. I'm just dying to jump in and – 

Brian Dawson: Those are great. You had your wincing moment. I had my lean back in my chair tense moment. So as we start to get ready to head out of here, one of the questions I'd like to ask before we go is one of the – a couple – what is a resource, a book, a podcast, a learning resource that helped you that you absolutely encourage our listeners to pick up, read, download, what have you? 

Elisabeth Hendrickson: I have three, so I'm gonna _____. Angie Jones is absolutely amazing and she has so much incredible content at AngieJones.tech. She is also the head of Test Automation University at TestAutomationU.applitools.com. There are all these incredible free resources there for education, and she is such a cheerleader in the industry, just in general. Follow her on Twitter. She is amazing. 

Through her, I found out about CodeNewbie hosted by Saron Yitbarek. CodeNewbie is so much fun. It's a podcast about people's journeys in software development. Saron has interviewed all these amazing, really interesting people with interesting stories. So CodeNewbie podcast.

Then last, Jeffrey Fredrick and Douglas Squirrel just published a book called Agile Conversations with IT Revolution. It is a fabulous book about how to have really difficult conversations, but particularly in the context of software development. So their work is really interesting. 

Brian Dawson: So, so far, and no offence to previous guests, I think you win the award for some of the best references. These are all intriguing to me, new. I have not read or heard of any prior, but I'm encouraged to go out and read all of these. And that's not to discount previous recommendations. At this point, a lot of people are leveraging Accelerate to Be Successful, The Phoenix Project, speaking of IT Revolution, and Gene Kim and team. A lot of that stuff has been very helpful, but this is a great new take. I appreciate that.   

Elisabeth, this has been a fantastic conversation. Before I let you go, I'm gonna ask you 3,000 other questions. No. Before I let you go, do you have any final thoughts that you'd like to share with your listeners?

Elisabeth Hendrickson: I guess I actually do. One question that we talked about covering, and then I think we probably ran out of time. So if this ends up on the cutting room floor as you're editing the podcast, I completely understand.  

Brian Dawson: Oh, no, hit it, yes.      

Elisabeth Hendrickson: One of the questions that you had asked me was about innovation and the future. One of the things that I want to highlight, you talk about what an amazing week this is, and this is absolutely like highs and lows this week in terms of what's going on in our society. 

For me, one of the highs was seeing IBM write the letter to – I believe it was a letter to Congress. I've got notes here. Yes, a letter to Congress on racial justice reform, and pledge that they are not going to continue to pursue facial recognition technology because of the risk of misuse. For a company like IBM, which by itself does have a troubled history with respect to the use of technology in the past, for them to call out that they will no longer pursue this line of research I think is huge, and I think they deserve to be commended for it.

Other organizations I won't name have attempted to make similar statements, but said things like, "But we won't pursue it for a year." That's just until people are not paying attention.

IBM is pledging – and I don't know about you, but I'm gonna be watching them, to make sure that this isn't just one of those temporary things – but they're pledging that they're not gonna do this anymore at all. I think that it highlights how important it is for all of us who are technologists to think about how our creations are being used and the role that we want technology to play in society, because while it's true that every single business is a software business, that does not mean that just because we can we should.

I think that with the rise of machine learning and the capabilities that we have, that there is a tremendous possibility of misuse and baking incredibly biased algorithms into now mysterious software that we don't understand how it functions.

And there's tremendous risk to security. I am watching with horror what's going on with Georgia and the voting and the voting machines that aren't working. There has historically been a huge issue around voting machines and security.

So I guess the last thing I would like to say is I hope that all of us as technologists can really reflect on how our technology is used, how it might be abused, and what our personal responsibility is to contribute positively to society as we go forward. 

Brian Dawson: Thank you so much. Nothing else that I can add to that. It's the perfect point to end.

Elisabeth, thank you for a great interview. Thank you for your knowledge, your time, your references. I very much enjoyed it and I look forward to us hopefully speaking again in the future. 

Elisabeth Hendrickson: Brian, thank you so much. I look forward to talking with your soon.

Brian Dawson: You have a great day. Bye-bye.

Elisabeth Hendrickson: Thanks. You too.