Welcome, listeners, to the Cloud and Culture podcast. Here is the quick background on the show. I am Derek Harris from VMware. And I am Danielle Burrow from VMware. And this podcast is focused on VMware Pivotal Labs and the work done by our team of experts to help organizations ranging from startups to the Fortune 500 shift their software development into high gear. As the title suggests, that entails modernizing and sometimes just kickstarting software development and tooling, as well as helping clients create a culture that will allow them to run efficient, self-sufficient software development teams for the long term. And our guest this week is Hedy Stern, a manager at VMware Pivotal Labs in Boston. She's helped a lot of organizations implement and excel at agile software development and has a strong sense of what good looks like. And sometimes, as you'll hear in the discussion, doing agile well means putting aside some strongly held assumptions. Yeah, and one of the major things we discuss is the importance of clear communication around goals, business value, and when a project can be considered done. This is especially important as organizations grow and there's more opportunity for information to fall through the cracks. Sometimes good enough is good enough and there is such a thing as too much autonomy. So listen to the episode to hear Hedy's views on the state of agile development and organizations. If you're intrigued, visit tanzu.vmware.com slash labs to learn more about how we can help. All right, Hedy, so just to kick things off, can you give listeners a quick intro on yourself, what you do at VMware? Yeah, absolutely. Thanks for having me. So my role at VMware is really leading product teams and helping make sure that we are meeting the software delivery needs of our teams and our clients. So it's leading teams of product managers, designers, and software engineers as we work towards important milestones and goals.
2:02And I know that agile is a big part of the way we work and the way we help our customers build software. And one of the things we wanted to discuss is kind of the struggle to do agile effectively. You know, I think there's a lot of folks who think they're doing agile, but it's not really working out for them. And we find that, you know, maybe they're not really doing agile. And I wondered if you could just explain, like, what does good agile look like? And maybe too, like, what are some areas where things get off track? Yeah, that is a wonderful, broad question. And I'm going to take it in this direction here, which is, I think the biggest threat to agile these days is around the difference between planning enough and planning too much. So the biggest conflict that I see with our clients that have so deeply embraced agile is that they are being so agile that they're unable to actually plan. And that is really frustrating their champions, their leadership and their champions that believe that agile can make high quality software and they believe in autonomous teams and psychologically safe teams. But at the highest level, they're also operating a business. And so where agile right now is failing the most is when people are using agile as a reason not to plan into the future, are using agile as a reason not to define done, actually. And that definition between MVP to done is where we really need to refocus our practices and make sure we're supporting our customers. Can you walk a little bit more clearly through, like, or elaborate, I guess, on that point? Like, so what is that gap between MVP and done? Because I often hear it said, and I'm no agile expert, okay, but I often hear it said that, you know, this is never done. It's always ongoing. I hear that language a lot.
4:03So I'm like, what is done as far as you're concerned? Yeah. I do think I tend to take scandalous opinions and this might be one of my scandalous opinions that are not necessarily going according to everyone else. But there are the different users and consumers of the software we build, right? There's the end user, that is the person that's going to be using the software to do something. Then there's the customer, the person that is paying for this software. So for example, like, for example, I'm going to talk about a big retail client that we worked with essentially, right? They were trying to increase people that went from checkout to, like, that completed their checkout process, right? And so the end user of that software is, like, the, it is the person that's, like, buying something from this retailer, right? But the customer of our product of the software is actually, you're saying, oh, a customer, obviously it's the end user. Like, no, the customer of the software is the retailer that's making an investment in the checkout flow. And they don't want to just invest in the checkout flow endlessly. They have lots of other priorities that they're balancing. And so it is and was frustrating to them to figure out the transition between understanding, hey, we are working on this checkout flow and we're experimenting over three months about making sure we're actually improving the rate of checkout with our usability changes. That's great, but, like, there's a diminishing returns in every move we make there. And for that, the, the VP or SVP of that retail organization, they really need to think about an entire portfolio. And so one of the things that's so limiting about Agile is you don't get that higher level view because you're so close to the user. And, and so what we need to make sure leaders are doing is communicating what the business needs and communicating with the trade-offs
6:04and why a team might grow in size or shrink in size or go into maintenance mode, which is a scandalous thing to be. I think, you know, I also think about our federal customers and you've probably heard stories, but let me repeat this one. It's pretty amazing. You know, if you look at some of the work we've, that we've done with the Air Force, essentially, working in an Agile way has replaced $10 billion programs. So, essentially, the way the Air Force traditionally bought software, they bought everything up front and now we have replaced that program with airmen themselves actually being part of building the software themselves, figuring out what the users want and deploying first releases early within 60 days, 100 days, 120 days and creating a new system for the Air Force to use and essentially replacing a $10 billion program. that's amazing. But while we are replacing that program, the Air Force is still, you know, sometimes using the old program as well and they need a sense from us of like, hey, when can we turn off the old version that we're using? So, when are we getting to this is enough, this is done and turning off the old version that we're using? Who's responsible for driving that? because it seems kind of like, you know, if I spent a big part of my career covering as a reporter like the, I guess what I'm now called the Fang companies, but back then they were just the big web companies, but they seem to always optimize for that extra tenth of a degree of or tenth of a percent of performance. but it sounds like what you're saying is, for most businesses, especially like a retailer, a tenth of a degree or a tenth of a percentage of performance increase on your checkout flow or however you're measuring that, yeah, like it's at some point the effort to do that is not worth it, right? So is that the business? Is that the product manager? Like who has to communicate to the developers, hey, back off, this thing is done, who actually owns that?
8:04Yeah. We have started a new practice among our product management teams which is essentially around product valuation. We're calling it PMonomics. One of our team members, Cara May, and another one, Susie, have really led this. I believe they might have, they've not done a webinar on this just yet, but it should be our next webinar. It's really awesome. It's a practice around how can we help product managers communicate the value of the software they're building both to their teams and the return on the investment of what they're building both to their teams and to their leadership. So this is something that we believe autonomous teams should be thinking about. At the same time, an autonomous team can't be left to do this on their own. And I really like the point you started to speak about with like the traditional FANG companies versus everyone else, right? Those are like consumer-facing companies with hundreds of millions of users, right? Billions of users. I don't know the exact numbers, but it's got to be up there, right? And I was just on a walk right before this with a friend of mine, Adam, who is a product manager at Spotify, an x-labs pivot. Totally awesome. And we were talking about the differences in our experience around how to iterate. What does iteration mean at a company like Spotify versus Dick's Sporting Goods, right? What does iteration mean at a company like Spotify or Facebook versus a government project that really only has 100 users that will ever touch it anyway or an internal financial services tool that is really important to 20 people and runs a huge book of business but only 20 people are going to use it. And how do you experiment and how do you iterate and how do you user test when you can run an experiment with 10 million people versus running an experiment with one or two? And I think the challenge for a lot of our
10:04clients is hearing the excitement of big data and the ability to test and iterate but struggling to figure out how to apply it to smaller user bases. And I think in a lot of ways that comparison isn't really fair. It ultimately is setting up the average software development team to feel frustrated to try to look for data where there isn't enough to make decisions, right? And I think one of the things that we look for in all of our teams and all of our hiring processes is someone that is able to make a decision with limited information, just make a decision and kind of move forward because the magic of Agile is not in making the right decision, it is in changing the decision you've made. But we have to do more around making that initial decision. We have to do more around describing what good looks like, describing what great looks like, describing what done looks like, even if it's wrong and changing our work along the way rather than getting stuck trying to get it right or not planning because we don't know. Oh, and only if we had known. Oh, if only we defer the decision, then it'll be better. Then we'll get a better outcome. I think we've gone a little too far and our clients need us to help them balance planning and collection of data and thinking about return on investment. But also, our clients need help thinking about when is it time to stop something? When is it time to rethink? Maybe you're not going to get enough information around if this is still worth the investment. Yeah, that makes a lot of sense. And, you know, thinking about the kind of medical or the health crisis that we're in now with the pandemic and, you know, being able to change on the fly is one of the most wonderful things about being agile. But you're right, like, if you can't plan or you can't define what done is, then it's
12:05definitely, it definitely sounds like you're kind of walking a tightrope. So what is that balance? Like, what does that look like? Do you have, have you seen any teams that have been able to pull this off and that are doing this well? I've seen quite a few teams, actually, that have really done an excellent job with this. And I think it really comes down to strong leadership. Strong leadership that can support autonomous teams with clear business goals. So, for example, we have a story with a government client that was working to replace a legacy system. A true refactor, rebuild, modernization story. It was a combination of all of those pieces of modernizing software and creating a new user experience. One of the things that they did, they did traditional planning, they did some, they did user research, all of the pieces that you would expect. One of the magical things that I really felt like they did was they were directing in their weekly demos. So, the head lead on the project, the person ultimately responsible for its success or failure, joined the software demos, which were held regularly, provided a script ahead of time about expected behavior and what was supposed to work where and how, and helped, didn't prescribe exactly how to get there, but the activities someone needs to be able to do to replace or turn off an old system that might be costing someone a lot of money. So, that is like a small thing, but it's exemplary around a leader that understands the high-level details around what a team needs to do to be able to declare success. And they're ready to declare that success when it happens, but they're not
14:05leaving a lot to chance. they're actively engaged in making sure that it's happening all the time. So, I think leaders that can bring in that active engagement but not telling a team necessarily how to do it or what colors to use or what field goes on what screen, that is the wrong level of participation from leadership. Rather, giving the guidelines, giving the goals, and letting people get there, that's a better way. A lot of our teams actually experiment with growth boards which are essentially trying to model the startup experience. So, a growth board might be held quarterly or semi-annually or biannually, essentially asking each stream or team to come with, to make a case for why they should continue to get funded. And that can also be a really great way to make sure we're measuring that ROI and comparing teams. They also get to ask for additional resources or make certain recommendations. But I think that falls a little short when you have different levels of product management capabilities across the different teams because not every individual team is going to understand their relative importance in the larger picture. And so, ultimately, again, it's up to leaders to really gather the best information they can and make some of those harder business decisions and spread those more explicitly as loudly as we can. And one thing that I found with teams as a leader is telling teams things once is just the beginning. So, for example, a lot of our clients are using OKRs around their business objectives, objective and key results. So, ultimately, our objective is to be able to complete this mission. And the key results that, you know, this type of person can, you know, let's use the example of writing a book report,
16:05ultimately, right? So, the objective is that the whole class hears your summary of the book report. And I'm using the book report because that's a lot of what our teams are trying to do, right? They're trying to share data. And that data is not always constructed in a really clear way. So, I like the example of a book report because a lot of what we're trying to do in the enterprise is sharing unstructured data that you're getting from a couple different places. Maybe it's more of like a research paper, but you're trying to take information and consolidate it in a way where larger groups can learn from it without having to get all the same information. So, you're collecting all this information and you write up this book report. So, can the person that's read the book consolidate the information and read the book report? That would be like an outcome you're aiming towards. Can the whole class read the book report this person has written? Can the whole class access the book report later on if they need to learn more about that book? These are like the kind of outcomes that are going to drive important features and then, you know, once a book report can be written, then like maybe, you know, we don't need to keep all of those book reports on this server that we're paying hundreds of thousands of dollars for a year. We can actually put it all in the cloud and more people are going to get more insights about book reports and like all of a sudden we're recording all of our video recordings of book reports and people are getting lots of different ways to consume the book reports and everyone is getting smarter and faster and getting better information. Those are like the kinds of outcomes we're trying to get teams towards. And so having to like not just engage around the day-to-day of like what the features are but really like making it the outcomes and the business focused outcomes and getting to that what is the dollar impact of that outcome that is like something only a leadership team can provide and maybe a super awesome expert product manager but we can't
18:06expect all of our teams to just naturally come to that because if they're so focused on that big picture then they might not be focused enough on their actual end user or their part of the stream. Yeah that makes perfect sense and I think it's something that we heard I mean I mean honestly as I think of it right like yes in any situation there are the people who absolutely have to be focused on the ground level because that is their job right and to some degree those little optimizations those little whatevers those are that's what they're there for that's what they're there to know and then yes like as you go up the up the line I guess right that that's where you expect to have this broader business or bigger picture view. What levels of leadership or when we talk about leadership right I I think what levels as that line of business is that CIO or IT leadership like when we say leadership what does what does that mean because the one thing I will say like the one thing I also we also hear a lot with digital transformation particularly is like the CIO is now the chief digital officer you hear all these things thrown around and it's okay so who's actually in charge like who bears responsibility I guess for what in that type of organization. that is not really an answerable question in that I think you know we work in a way these days which is highly collaborative and success is not tied to one person necessarily. In software what that means is we have to keep creating champions and more and more of our work is about storytelling and making sure everyone understands the story than just building the right software. So there's a book Google Design Sprint and it outlines basically a the design sprint the concept behind a design sprint is get enough user insight and subject matter expert insight to make a decision on a product direction and start to mock that up and test it and do
20:06all of that within a week. So it is like a super hyper focused what we might have traditionally called a framing concept. It's part of the design thinking methodology but really consolidated focused with high level executives everyone together for one week. One of the daily activities of the design sprint that gets forgotten is the product manager tells the story of the product every single day. And then like I don't remember if this is actually from the book or iterations on the book but the concept being then that like everyone would take a turn telling the story of the product. So it's most important that like a product manager be able to tell the story of the product but we also believe that like everyone needs to understand the story of the product and why this is and why this matters. And so I think like we are under focused on telling making our case telling our story explaining the ROI and hoping that building building the right thing will just make the users come but ultimately what we've seen over and over again is you can build the best software but if you don't have the right relationships you can build the best software for a soldier but they're not going to use it if their commander doesn't think they should. Same thing in the financial industry. You can build the best software for an analyst but they're not going to use it until their boss says to use it. So it's one thing to build something awesome but the world we live in is around building consensus and building teams and being collaborative. So there's just no one person that can really make it happen. It's so much more about building the right relationships and telling the right case. So when you're talking about you know building a champion building those relationships it sounds like that's a really important piece of you know
22:06bridging the gap between these agile teams and and the business goals or the business objectives but how do you like how do you identify who that champion is and how do you go about actually you know putting into place certain practices that promote that level of communication because that's that requires quite an investment on the part of leadership and whoever that champion is. Yeah. I think we can't rely on one champion and that we constantly have to build more and more champions and again if if they don't have the time to champion this product then that's a signal that maybe it's not as important as we thought it was and we should take that back and check in like are we making these ROI calculations right. Just because something's not the most important doesn't mean it shouldn't get worked on right. we still have to motivate a team even when they're working on something that's not the most important but we have to constantly be building those relationships for our team be building those relationships across the business unit across IT across users across champions across our users bosses bosses boss towards the board that reviews our success. that is like a never-ending challenge for a great software team. I'm curious because that idea of right if someone says they don't have the time to do this it is a pretty good indicator that maybe it's not that important. On the other hand you said but like even not important things need to be worked on probably. Do you find is it typically like I mean is there a person within a lot of orgs like that jack of all trades or that do you just have to find that so not as a champion but like who's this reliable person who's just going to take this thing by the horns and get it done and then probably move on to the next thing but like is there I don't know if that's called that person a champion is what you call them a work
24:06horse or something. I'm just curious when you say like right when you run into that issue presumably you have to motivate someone to handle that. Yeah but I think like it's I think it just can't be one person right we have to motivate these larger teams we have to motivate these larger groups and so I think thinking about software as just the act of building software that is kind of like what is the most risky for teams and it's easy for us in a consulting lens to think about that right because we're consulting all the time and so we understand that we need to build alliances within the organizations we're working with and help them champion the work they're doing that makes the case for consulting but you know when I talk to Adam at Spotify or you know other friends at other software organizations they're doing that all the time internally too and so it's just not something you can kind of like leave and forget it's like just a constant a constant part of building great software just like the great CEO is like fundraising from the right people and from the right investors not just any investor and they are building the right partnerships and alliances right like all of us with the pieces of software that we build are not just building but ultimately like making a case for a change and making a case for a change is really hard and it is an uphill battle always and even even when you get 100% of traffic even when you get 100% of people on board you're back at the bottom of the hill with your next challenge have you seen have you seen this improve over the years I mean as as we talk more about as software becomes more important I mean the again like Danielle mentioned earlier the COVID situation was just like a very stark and recent wake-up call but just over the last however many years that let's say decade give or take that
26:06software has really gone come to the forefront have you seen these skills improve and you as you go into clients or is it every time a okay start from start from scratch and you know build up these from the ground I think it depends on the organization right because you're like different organizations support different levels of collaboration and decision making I definitely see culture and organizations being focused on consensus and employee happiness and that being important to organizations and that's always a pleasure to work with and so then it's really around helping the individuals or the team figure out how to work get to the right people and craft the story I think it is I definitely think it is trending positively upwards I think software is where the ROI is so more eyes are on it and it's more and more important and it's more and more exciting so I definitely see it trending upward I've kind of a self-serving maybe hopefully not too self-serving question but I'm kind of curious about you know when you come into an organization and you know there's this need to build consensus and build relationships do you find that as an outside consultant like it's it's easier for you to do that and to kind of help your the team you're working with make those connections that they might not otherwise be able to make or not necessarily because you are an outsider maybe it depends yeah I think it goes both ways I definitely find that there are lots of advantages to just being a set of fresh eyes but oftentimes when clients are bringing us in it's because they know they need help with something even if they're not sure what it is so they're open to it they want they want the help they want the support some members of the team might be more resistant but I think we we are so highly collaborative and
28:06so highly transparent in the software that we build together and that's one of the really special things about working with pivotal labs you get such a high level as a leader or a member of the team of transparency on what everyone's doing all day because you could just hop into the zoom and listen to them pair on like what the software looks like today because you can just open up an acceptance environment you don't need to wait till the week and look at like a scheduled release there's transparency into when something is going to happen because you could just open up the backlog and look at the where it is in the level of priority and recommend it be higher or lower so that level of transparency also creates like a level of like psychological safety and support and positive intent that I think a lot of people really feel excited about and so the quality of our software the quality of our test is not just our superpower but our like comfort in transparency I think is like what makes it so appealing to work with a people labs teams so hear me out you might say what a stupid question Derek basically it's how do you weigh the importance of communication and and leadership and executive buy-in and all these things you're talking about and psychological safety and everything versus the other thing you hear which is we just need to be able to hire better developers or we just need better tools for developers and everything will be better because that's the other thing that seems to go hand in hand with getting better at that software don't you need both probably I'm asking are you with them no I think like as in yes I think you need both you need the quality of the team hiring the right people hiring the right balance of people hiring the people that are going to collaborate and coordinate arming them with the right tools so they're not spinning their wheels working on things that are not their highest value and creating space for teams to experiment so that they really can think outside the
30:06box and you can harvest that thinking for greater good for your customers all right so very insightful Hattie all of this like especially as someone who personally who who who see I've you know I've been with VMware what for Pivotal I guess slash VMware for like two years and I some of the lab stuff I'm just finally they're finally starting to distill down to me so I always love having these discussions um but like so if you're if you had to say for like a new client right I mean obviously before and definitely engage with Pivotal Labs but but you know if you had a couple or one or two pieces of this is the thing you need to do first just like number one you're going down this journey something's broken like like what are those first steps that everyone can take to kind of to just get headed in the right direction at least to the leaders the first piece of advice that I like to recommend is protect your teams a little less I think so many leaders in software get there because they've protected teams they've executed they've they've helped a team perform and meet a difficult moment meet a difficult deadline but I think we are struggling between giving teams autonomy and giving them transparency and clarity into the real business value they're they're providing so in an attempt to give them autonomy to let them be agile we are not giving them enough information about why they're building what they're building so protect the teams a little bit less but I say to I recommend to do that especially in this time of COVID where everyone is working in a dispersed way it's a combination of giving the teams clear outcomes once and then again and again but then having those one-on-one connections with members of the team and listening listening for those moments of creativity that can change perspective giving the team space to change direction when they learn something
32:06listening to the learnings and encouraging that so there is actually like a higher touch involvement in this moment where you can't overhear something over coffee or check in with a person or read their body language and we don't really know what's happening to someone behind the screen beyond the screen where we just need to listen a little bit more closely and also be more transparent thank you so much Hetty it's been really great hearing all of your thoughts and hearing all about your experience working with these teams and thanks for joining us thank you Thank you.