Agile development is a funny thing: Its goals are laudable and easy to understand, but its implementation often leaves much to be desired. Teams can follow the agile manifesto to a T, but still end up spinning their wheels or, maybe worse, getting traction and investing resources on the wrong projects. However, there is hope.
On this episode of the Cloud & Culture podcast, VMware Pivotal Labs’ Heddy Stern shares some of her thoughts on and experiences with agile programming, stemming from years of helping large clients kickstart their software development efforts. Specifically, she focuses on the need for communication among business leaders, product managers, and developers so that everyone understands what they’re building, why they’re building it, and what good enough looks like. Because while developer autonomy is important, ROI is still the measure of success.
You can listen to the entire episode below, or keep reading for highlights and an audio excerpt of Stern explaining the importance of cultivating champions across the organization.
Keep an eye open for diminishing returns
“[A big retail client was] trying to increase people that completed their checkout process. And so the end-user of that software is the person that's buying something from this retailer. But the customer of our product . . . 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 there's a diminishing return in every move we make there.’ And for that, 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. So what we need to make sure leaders are doing is communicating what the business needs and communicating the trade-offs and why a team might grow in size or shrink in size or go into maintenance mode.”
The magic of agile is being able to change
“What does iteration mean at a company like Spotify or Facebook versus a government project that really only has a hundred users that will ever touch it in any way, or an internal financial services tool that . . . 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. I think the challenge for a lot of our clients 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. And I think one of the things that we look for in all of our teams, in 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.”
Transparency leads to psychological safety
“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 the help, they want the support.
“Some members of the team might be more resistant, but I think we are so highly collaborative and so 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. [Or] on what the software looks like today, because you can just open up an acceptance environment. You don't need to wait until the week and look at a scheduled release. There's transparency into when something is going to happen, because you could just open up the backlog and look at where it is and the level of priority, and recommend it be higher or lower.
“So that level of transparency also creates a level of 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 [or] the quality of our tests is not just our super power, but our comfort in transparency, I think, is what makes it so appealing to work with the Pivotal Labs team.”
More agile resources
About the AuthorMore Content by Derrick Harris