How Agile is "Agile Enough?"

Debbie Madden
Stride Founder & Chairwoman, Stride Consulting

Debbie Madden is a serial tech entrepreneur, the founder & Chair of Stride Consulting, Advisor at Docker, author of Hire Women, and two time Inc 500 CEO. She is a mother, wife, and breast cancer survivor. Debbie has built and scaled 5 tech companies from the ground up and has been CEO of three of them. She is passionate about building teams that individuals truly enjoy being part of. Due to her reputation as a passionate woman executive in technology, Debbie is a sought after speaker and writer, having appeared in Harvard Business Review, Inc. Magazine, Forbes, CNBC, Huffington Post, Varney&Co TV and more.

Awesome.

Thank you.

First of all, this is the last individual talk of the conference. So give yourselves a round of applause because you did it. Congratulations. You guys are doing great.

So… Is your leadership team Agile enough? Well, I think that's a great question. Let's find out.

My name is Debbie Madden, and today, right now, we get to talk about, How Agile is 'Agile Enough' For Leadership Teams because business agility starts at the top. A quick bit about myself.

I am the founder and chair of a company called Stride. We are a non-dogmatic collaborative software development shop. We build software that's transformative with you, not for you. And we sit uniquely at the intersection of building custom code, coaching on technical engineering best practices, and non-dogmatic consulting. And me, I've done a couple of things. I appreciate the shout out to the book. I am a five-time tech entrepreneur. I've been scaling tech companies for a while, 25 years. I have written a book and I am also a podcast host of Scaling Tech, which comes out in about a week. And I am an advisor for a company that we probably all know called Docker.

What does it mean for a leadership team to be 'Agile enough'? That's the question. Does it mean the same thing that it means for a technology team, for a marketing team, for a product team? In my mind, it doesn't, but there is a definition and there is a bottom line. So what happens when the leadership team falls below that bottom line? And what can every single one of us in this room do about it, whether or not you, yourself, are on that team? That's what we're going to talk about.

We're going to break it into four chunks. We're going to talk about two words that people confuse, and they're not the same, the word team and the word individual. Those are not the same thing. Then we're going to talk about my leadership team's Agile journey and what has been Agile enough over the last 10 years. We're going to define how I identify what 'Agile enough' is for Stride's' leadership team, and then we're going to talk about what we do when our leadership team falls below this bottom line.

So team versus individual. These two words are not the same. Many of us know this. I hope everybody knows this, but it bears repeating. Individual agility is a precursor to team agility. It is not the same thing. Individuals can have skills, knowledge, capacity, but when you bring a whole team of us together, that's when we can do things like have predictable outcomes, provide business value. So when I'm talking about how Agile is 'Agile enough" for a leadership team, we want folks on that team to understand the basics and then come together to do the work in a visible, repeatable way. Starts with the shared vocabulary like we just did today. What does the word "team" mean? That leads to that predictability and reliable outcomes. Where we're going to focus the bulk of our time, and we're going to get real comfortable for several minutes here, this talk is not about a theoretical how to. This is about the pain that I've suffered along with my coworkers for the last nine years. This is where we're going to hang out. Many of us in the room are familiar with Diana Larsen and James Shore's 'Agile Fluency model'. If you have not heard about this model, I see some nods. Please go read about this. It has been for me, life changing.

And so this is how I measure Stride's leadership team with a CEO and a CFO, and a Chief People Officer and a CTO. That is our team today. Now, the idea of an Agile fluency journey is that there is no one spot for everybody, but everybody has their moment in time where they need to be. And so, like we said, the precursor is a Pre Agile, ICs, as individual contributor, right? We need that. And that is actually a very interesting point to start with the leadership team. I heard a CFO in 2019. He wasn't Agile. He didn't have that precursor. We had to teach him how to do Agile. He knew how to do finance. We had to teach him Agile. You get the focusing, delivering, optimizing, the strengthening. I want to explain to you what this picture... This was the biggest light bulb moment I've had.

2014, we started Stride. And you might say, "You're full of it, how can a new team possibly be optimizing?" Well, I'll tell you, we kind of cheated because the initial leadership team was myself and my husband, and we had the very specific advantage of having run an Agile team together for the past 10 years. So we came in with it. There's two very important things that allowed us to hit the ground running here. We both had been practicing Agile for many, many years, about 10 years, and we had been on the same team before. So that allowed us to come in and hit the ground running and do these things like minimize cross team handoffs. And plus the company was small, right? We increased our agility a little bit. And then this big dip in 2016 was the first time in our company's history where we hired generalists onto the leadership team.

We took a dip. It was okay. We went to focusing. And then over the next three years, we actually worked with external Agile coaches, external business coaches that were not Agile, and our Agile engineers. Because remember, Stride is in the business of helping other companies increase their agility. And so we had our employees, our engineers, our product managers help us. And so over three years, we slowly climbed back up, not yet to the level we were at the start. And then, 2019, we hired our first specialists. And I want you guys to think about your leadership teams. Do you work for an enterprise company? Do you work for a scaling company? Do you work for a small company? There's a lifetime in every company's journey where they go from hiring generalists to hiring specialists. And that is a point when agility just takes a nosedive. Because we're hiring people from outside our community to do the things that they've been doing successfully without Agile for decades.

Think about it. And they're coming in and they're like, "What is this visible work? I'm not going to make my financial forecast for the year visible. I'm going to give it two and three months. When it's done, you're going to like it." And so we had to teach these specialists what Agile meant, and we took a dip. And then in 2020, as we were in the middle of that dip, as we were talking about, we had to work remotely. We were such a small team at that time, then our agility was based on we were one team in one room. Our work was visible. Stickies on a whiteboard in our office. We had in-person standups, we had in-person demos, and then all of a sudden, our leadership team had to learn how to work remotely. And this was the lowest point in our agility as a team, and ever since, we've been climbing up. Now, why does this matter?

I told you we were going to spend the bulk of the time on this screen. Why do we care about this? Look at this. Revenue. This is why we care. Leadership agility leads to measurable business outcomes. I've seen it. I've seen it. This is it. Two things to note. Before 2019 and after 2019, right?

Before 2019, when we were such a small company, such a new team, that agility hit because we were bringing on a generalist that had that Agile understanding. And because we came in at such a high level, our revenue was able to keep going. And then once we got to the point where we were a more mature organization, we hired specialists in their craft. Ever since then, you see our revenue is literally mirroring the agility of the leadership team. How fascinating is that? So what does that tell me?

Let's say in a year or two or three from now, I need to hire another specialist from outside our community. I should expect an Agile fluency dip. I also should expect a revenue dip. That's weird. I might not be changing the way I do the work. I might not be doing the way I change the work. But I am going to tell you, I've seen this with my own eyes, and this is really the take away. When you hire one new person onto an executive team, onto a leadership team, any team that you might be at, your agility dips and that impacts your business outcome. So what do we do about it?

Well, the way I plotted this graph, the way I look at 'Agile enough' for leadership teams? How did I make that graph? A little art, a little science? Sure. Here are the things… for me, if you want to be on a leadership team at Stride, these are table stakes, whether you come from the HR world, the legal world, the finance world, the back office world, or the Agile delivery world. I don't care what your discipline is. If you want to be on our leadership team, these five or six things that I list, this is what Agile enough means for us. Then where we are as a fluency is about how we educate those team members together. Because remember, it trickles down.

We had lots of talks today about how... Sangeeta just mentioned it. We had these leaders that told you to do it and walked away. To me, that's not Agile enough. And so these are table stakes. Number one, tight back loops become habit. It's not one person's accountability to tell all the other people on a leadership team that tight feedback loops are a habit. So we can do that through standups. My leadership team has standups. My leadership team has sprints. My leadership team has a backlog. We have all the things. We're Agile. We hold each other accountable, and we make progress towards our outcomes visible. My head of people is working on switching our PEO. I'm not going to ask her to give me all the details. No one has time for all that. But I am going to ask her to make her outcomes visible, and I'm going to make sure that every single person's outcomes are visible and ladder up to our OKRs.

Whether or not you're using annual goals, OKRs doesn't matter. Your leadership team's outcomes should be visible to the entire company. Any single employee at Stride, my bookkeeper, my junior software engineer, my product manager, my marketing team can go in right now today… We track stuff in Trello, we track stuff in Lattice. It's lightweight. It's not complicated. We don't use Jira. Our leadership team is not using Jira, people. We're not. That's too much for us. That's more than we can handle. We have a lightweight tool that is visible digitally to everybody.

Everybody has to value continuous improvement. I have met, over my career, I've been working in tech, 25 years, many seasoned executives that are good at the craft that don't value continuous improvement because they don't understand it. I didn't understand it when I was starting out in my career. I didn't understand what it meant to continuously improve. This is, if I had a nickel, you come at Stride, you have to understand theory of constraints. You don't understand theory of constraints, I will give you, no joke aside, you have to read a book, you have to read the Phoenix Project, you have to read the goal, you have to Google theory of constraints. And then once you tell me you understand it, then I want to see that you're minimizing your work in progress. Table stakes, table stakes. This is if you look inside the company, underneath the hood, this is what I consider for my team 'Agile enough'. If you have a leadership team in your company and they are not doing any of these, how many you got here?

Five? Five things? And you understand these things and you understand the importance. And I think as a group, we do. The out-of-the-community, I think, really gets these things. What can you do to influence their capacity to understand and really value the importance of this? And the way I like to talk to leadership teams is don't do it because it's the right thing to do. Don't do it because someone told you to do it. Do it because in your heart you believe these behaviors will impact your business. Increase your top line, increase your bottom line. Increase your culture, increase your employee engagement. These things. I missed one. Understand the root value that Agile brings an organization. I mean, yes, that's like the summation of all of these things. Now, the question then becomes, can you be too Agile? No. I mean, come on. Who knows one that's too Agile? Raise your hand. Anyone? If you do, I really do want to hear about it.

I do not believe a leadership team can be too Agile. I believe they can't be Agile enough. This Pre Agile bit, that word strengthening on my slide was on the right. So don't see what you see, see what I wrote, and it's on the other side. That word dogmatic also belongs on the other side on the right. This right. You can't be too Agile. You absolutely can be too dogmatic. Thank you. This word non-dogmatic, it's very near and dear to me. Who are we to tell people what they should do? Oh, just do that. You should do that. No, it's not about everyone doing all the things the same exact way all the time. It's about embracing the tenets of Agile because we understand their value. And as a leadership team, it is our responsibility to our organizations to not be too dogmatic. And I feel very passionately about this.

Last, we're going to end. What do we do about it? What happens when our leadership team falls below the bottom line? And we're on the team. What happens if we're not on the team? We're like, "These guys are messing it up." I see it. What can we do about it? These are the things… These are not all the things, of course. We're only here for a few minutes together. These are the things that have worked for me over the last 20 years of practicing Agile on Teams. Number one, define what it looks like. Go back to that fluency model. Have everyone on the leadership team, including your head of finance, including your head of security, including your head of people, HR, legal, all the things, have them go and read it. There's a three-minute video that explains it. It's a really good video where Diana and James are narrating this. Have them go, "Hey, can you take three minutes and listen to this?" Where on this do you think we want to be? Get alignment on where they think good enough is. This is the thing that leadership people as a group, we don't like to do. Break tasks into smaller chunks until the outcomes are predictable.

I'm going back to my Chief People Officer. She created an employee handbook. Employee handbook is something that every... She has a legal obligation of fiduciary responsibility to our organization to make sure that that thing is accurate, that everyone reads it. And I done told her, "Don't redo the whole thing, just do one policy." And she was like, "You are not making any sense. This does not make any sense to me." Because I said to her, "How long is it going to take?" She said, "I don't know, a month, two months, I don't know." I said, "How long would it take you to update our PTO policy?" "Oh, a day." "Great." "Do that." It is possible. It's possible. It's uncomfortable. It's totally possible. And then, any one of us in the room have seen firsthand the value of breaking things into smaller chunks. And this is the thing that a lot of leaders hate it. It's uncomfortable. They don't like it. They've been successful not doing this for 30 years. That's another thing. If it ain't broke, don't fix it. This is hard. And if there's still problems, I take work and progress down to one task a person. Very uncomfortable. People don't like it. But we have a backlog. It's prioritized.

Again, we all know what our annual goal is, we have our OKRs, we have our quarterly outcomes. And remember, we're having weekly meetings, we're having daily standups. So what are you going to do? What's the number one most important thing that you're committing to this team and to this organization? Because remember, it's visible to do. And once you're done with that, put it in the done column and go ahead and pull something else. This has worked for me really, really well over the last 20 years.

Please raise your hand and do this for your teams. A lot of times we're very busy as leaders and people that don't understand the value of Agile don't take the time or believe they don't have the time to learn it. But if we have an Agile coach, or an Agile engineer, or an Agile project manager, or a product owner say, Hey, I'm going to come by just for fun. I'm going to facilitate an Agile meeting. I'm going to show you what good looks like. I'm going to show you what I do all day long. Make sure the topics to discuss aren't sensitive, etc. This goes a long way.

And the very last thing that has worked for us is to have a book club. And yes, even people have read the book, read it again, because again, team agility starts with shared vocabulary, which I went over that slide quickly at the beginning, but it really does start with the shared vocabulary. And so if folks don't understand these concepts, then you're going to be speaking different languages and everyone's going to get frustrated. Blame Agile. We've all seen that before. And then we're going to be in bad place. Book clubs are great. Leaders love to read. So this one you might have an easier time with. And that's really it. right? There's lots that we can do. These are the things that have been most impactful for my leadership team over the last nine years. That being said, this is the tip of the iceberg.

This is what we went over today. If you have questions, I really mean this, and this is true. If you email me, I will email you back. I'm going to get the email. It doesn't go into the ether. People don't believe me. I always email them back. If you have questions, which I'm assuming you do, you can ask them now. My email, debbiet Stride. Build. Email me and we'll talk. Thank you.