Scrum isn't the secret ingredient. Adapt the recipe.
Large scale transformations come in many flavors, but teams get burned by delivering more process than value. While the methodology is a key ingredient, it should be carefully balanced with other inputs to get the best result. This talk will cover ways teams can focus on delivering results by leveraging scrum techniques while also embracing empathy, urgency, and user experience to deliver measurable outcomes.
Hear from Devbridge Managing Director, Laura Graves.
Watch the talk:
Transcript:
This series is called Full Stack Fridays. It's a monthly series that we do here at DevBridge to share our thoughts on product delivery, product management, basically all things product. Today's talk is called Scrum Isn't the Secret Ingredient: Adapt the Recipe. My name is Laura Graves. I'm a managing director here in our Chicago office, and I'm excited to talk to you all today about scrum and also about the other things that are really important when it comes to building great teams, who in turn build great products. Here we go.
Why are we even talking about scrum? Why does anybody want to talk about scrum? I think it really comes down to the fact that everyone is trying to produce results. Enterprises crave results, and in particular, right now, everybody is trying to do more with less. Even if you weren't thinking about agile before or thinking about scrum before, now's the time to say, how can we bring a scrappy band of people together to get the things done that we need to get out the door?
Well, what happens at the enterprise? I think they're looking around them and they're realizing that they're playing from this old playbook or old recipe book, if you will. The things that those recipes are producing are not really all that appetizing to anyone, and that goes a couple of different directions. They're not all that appetizing to the consumer, right? These enterprises found product market fit a long time ago, but now they're super vulnerable to disruptors and new players in the market. They're also vulnerable when it comes to attracting talent. You look at this picture and I don't see very many people jumping to say, "Hey, I want a part of that."
So what's happening? Enterprises are all out there looking for a new cookbook. This new cookbook is shiny, it's interesting, it produces really great food and it gets people excited, right? Here in Chicago, we have Stephanie Izard, our local top chef, and we all want to follow her recipes and make food just like her. But what happens when we follow her recipe and we try to make her food? Usually it's one of two things, at least for me. You follow the recipe step by step, but at the end, you end up with this epic food fail, something like burnt meatloaf on the table that doesn't look anything like what you set out to do when you were following her recipe. The other alternative is maybe it does turn out great and you're actually able to produce that delicious plate of food that looks awesome, tastes awesome and everybody's excited about, but in order to get there, you bought a million gadgets, a million new ingredients. It totally took over your entire kitchen, it took forever, and by the time it's actually done, you find yourself wondering, was it worth it?
I think the same thing is happening in enterprises who are trying to cook from the scrum cookbook, right? Either it's not coming out the way that they expected or it does, but by the time they get there, they look around and wonder, was it worth it? So was it? Probably not, because the same recipe that works for Stephanie Izard isn't necessarily the one that works best in your kitchen. The same is true at your office. The same recipe that you read in an article somewhere isn't necessarily going to play within your environment. What we all really need to learn is how to adapt the recipe for our own teams and our own organizations and figure out how do we use these tools and use these techniques to build great products and build great teams.
It sounds a little scary, right? How could you possibly adapt a recipe when you haven't even figured out how to cook the recipe? Let's think about that for a second. We're going to talk about one of my favorite topics in order to do so, which is tacos. These tacos that you see on the screen right now are amazing tacos. They come from a little grocery store on Division, and they're absolutely delicious. These tacos come from down the street, a Big Star, and they're also awesome, but they don't follow the same recipe. What they do do is employ the same technique, and that's really what is important to infuse into your teams and organizations. That's what we're going to talk about today.
When it comes to food, it really doesn't matter what you're making. There are actually four key ingredients, and the technique of how you use them in balance with each other is what makes great food. That's why both of those tacos taste great, because in both cases, there's a careful balance and careful timing of salt, fat, acid, and heat. You don't have to believe me, I'm certainly not the expert when it comes to cooking, but this lady, Samin Nosrat, is and you can check out the full details on the food part of this on Netflix for your next quarantine binge. But today we're going to talk about the four elements and the techniques of how you use them to make great products with awesome teams.
The first one, the salt, if you will, is all about working agreements. before anybody gets too excited, this is not a scrum is garbage or kanban is better talk. We'll talk a little bit about how you can use working agreements effectively. The next is that balance between the fat and the acid. In the product world, that's about that balance between user value and business value. Last, heat. When you're cooking, you're always managing your heat, and sometimes you're harnessing that heat to put the finishing touch on whatever you're cooking. In the world of product, that's about both managing urgency and harnessing that urgency to make sure that you are making the most delicious end product. If you can get all of these things right, that's when you'll really have a team who avoids these big food flops or situations where you've over-invested in compare to the return on the end result. Let's dive in a little deeper.
I mentioned that I think about salt as working agreements. You may or may not know, when you salt food, it's actually getting sucked into the meat or the tomato or whatever you've salted. When that happens, it releases the bloat in the food, it lets go of all the water. At the same time, it brings out all the natural flavors. I think that's a really nice way to think about working agreements, right? When you have a scrum team, it's not really about the team itself, it's about bringing focus to the work that they're doing. The backlog is about bringing visibility. Story points are really about driving accountability within the team.
All right, fair enough, but what happens when we oversalt our food, or oversalt our product delivery, I guess I should say. Rather than talking about focus, all of a sudden the concept of a scrum team has become about certifications. Do you have a scrum master on your team? Are you a certified scrum product owner? The answer is, I'm not really sure that matters, and I don't really think that that's the place that we need to place all of our attention.
Similarly, when it comes to the backlog, when we go a little bit too overboard in implementing these new working agreements, we try and shove all teams into a one-size-fits-all process and teams spend a lot more time managing the process than they do thinking about and talking about building great products. Lastly, story points can get weaponized. If we start only incentivizing velocity and over focusing on how many points the team can deliver, we're really missing the point and we run the risk of driving bad behaviors, where people start gaming the system. It really is a lot like over-salting your food. The fries are delicious, salt on fries are delicious, but if you go too far, you end up throwing out the plate because you really have to start over.
So what's the answer? If you're finding yourself rolling out new working agreements to the team or working with teams to build them, rather than getting hung up on what the textbook says and making sure you follow it to the letter of the law, ask yourself, are you protecting the team and allowing them to focus? Are you instituting processes which drive transparency so everybody knows what we're working on? And rather than focusing on velocity and some arbitrary metric of how many points you deliver, are you getting the team in a place where they can consistently estimate how much they're able to deliver in a certain period of time? That's why volatility is really a much healthier metric, are the teams delivering consistently within themselves?
Now, it is true that the same process that works for a large organization and a startup at a software company, they're all going to be a little bit different, but I can tell you about some work we did with Grainger, which is a fairly large organization here in Chicago focused on industrial parts supply. In this situation, we had multiple teams running in parallel, each working on a different work stream. The team makeup wasn't exactly the same from team to team and the way that they do their work wasn't exactly the same, but they did have a core structure in place to really bring the best out of the team by supporting them with the tools they needed and making sure that communication was flowing. At the end of the day, that's really the magic of these working agreements, is trying to bring out the best in the team.
All right, so what's next? I mentioned, it's not all about scrum and it's not all about working agreements. You have to have more in order to have really high-functioning teams. The next piece is about this balance between the fat and the acid, or the balance between the business value and the user value. Really, what's important is that your teams understand that balance because that way they're going to be able to make their own decisions and not be bottle necked all the time by a rigid management hierarchy, where they're always looking up for the decision.
We're going to go back to food for a minute and hear from the expert here. Samin Nosrat says that fat is nothing short of a miracle, it's flavor. What you might not think about is fat in food is also texture. It makes things crispy, it makes things creamy. Think about what's the fat in your business, what really makes your business work? It's important that you share that with the teams. The whole team needs to understand why the business is investing in this particular initiative, because when they do, they can internalize that and help inform decisions that they make along the way. Talk to your teams. Are you building something to drive more acquisition? Are you building something in hopes of retaining new users? Are you building it in hopes of moving them to a new premium tier where you're able to actually collect higher margins or more revenue? All of those important inputs, the more the team understands about it, the better decisions that they could make.
Now, there is a risk here. If the team gets over-focused on the business value, or goes a little overboard on the fat, you end up with the doughnut burger. Nobody really wants to eat the doughnut burger because it makes you feel a little sick afterwards. The same thing is true if you guide your product strategy by only thinking about what brings value to you as a business, because you're missing that other half, that acidic, bright flavor that grounds you, which is what your users really need. How do we get that part of the equation right when we're thinking about building teams?
Well, let's take a step back. The traditional model, quote, unquote, are the siloed organizations where you have the IT team, the business team, and the business team really has the customer locked down and nobody else is going to get in front of them. When we move to these models, we are all about breaking down those walls and making sure that IT and business starts to blend into a cross-functional team. The idea of the cross-functional team is now we've got all of the skillsets that we need working together and that we can bring that whole group closer to the customer.
But what happens a lot of times when organizations go to roll out this new way of working? Well, we just repeat the same patterns that we used to follow with different labels. Engineering very much still sits behind a wall and the product managers and product designers hold the key to talking to the customers. But if you're doing it this way, you're really losing out on getting a lot of great input from your engineers and having them really embrace that mindset of the customer and understanding what the customer's needs are when they're thinking about how they're going to implement a particular solution.
How do we change that? How do we make that shift, which in a lot of cases is actually much harder than shifting from waterfall to scrum, but shifting this mindset amongst the whole team, the engineers, that they really do have a place getting to know the customer? Well, the answer is you actually have to bring them to the customer. This is a shot of a warehouse visit that our team did. We work with a company called Capstone Logistics. For those of you who have been hoarding toilet paper, you don't have to raise your hand, but you really gave a boost to capstone here because they manage loading and unloading trucks at warehouses across the country.
They came to us with a challenge having to do with their team that's located in the warehouses, and we wanted to really make sure that we understood not just what the needs of the business were, but what the needs of their customer were. We went out and went to their warehouses to observe their day-to-day, and not even observe them using an app that we were going to build, but just understand what the context was, where was that solution going to be used and what are the types of things that the folks working in the warehouse really cared about?
In today's world, thinking about doing onsite visits and traveling is really challenging for people and there's certainly not a lot of that going on, but that doesn't mean that you can't bring the team closer to the customer, because there are ways to do observational research remotely, watching people through some sort of screen sharing, testing out prototypes remotely, all of that can be done. There are also other paths. You might consider actually using resources that you have internally, your sales team, your customer success team, your support team. If you can bring those teams a little bit closer to the product delivery team, then they can really pass along some key insights. There are a lot of companies that actually have their product teams ride along with their support teams on a fairly regular rotating basis so they always stay up to date on the kinds of things that are coming through and where users are getting frustrated.
Lastly, it's really important that you capture and share these findings from each of these events where you do get the team closer to the customer. There's really great tools out there. Empathy maps will help you capture what are your users feeling, where are they frustrated, what are their goals, what are they trying to do? A user journey map will help you take that experience that you observed when you did go onsite and visit, or as it's been described to you by subject matter experts, and understand end-to-end what's going on in your user's life and how does this tool fit within it.
All right, that was kind of a mouthful, but we've talked a little bit about the business value, making sure you've communicated to the teams the why, and how to get the user value. What happens when we get this right? We're going to go back to our Capstone example. I mentioned that we built an app for them. Essentially what happened is Capstone has this distributed workforce that works across the country in different warehouses. Their corporate office is down in Atlanta and a big challenge that they had was actually creating a community amongst their associates that work in this distributed fashion. It meant that they weren't always getting feedback that they were looking for from their team and they weren't always able to send out really important messaging. So we set out to build an app that would actually allow them to facilitate this communication. The metric that we were looking for was adoption. the key missing piece here, the business value that we were really looking to achieve for Capstone was actually getting that connection and that engagement from their distributed workforce.
How did we do that? You can really capture this whole conversation and the team can demonstrate their understanding of balancing these two things by laying things out on a two-by-two grid. As you're thinking about what you might build, think about what delivers both business value and user value, what doesn't deliver either and probably isn't worth a lot of investment, and what are the features or work streams you're planning on working on that deliver value for the business but not so much for the user and vice versa, and how are you going to balance those things? If you've empowered your team and they understand what drives business value and what drives user value, they can use a simple exercise like this to keep the momentum moving and work efficiently as a team. At the end of the day, that's really how great products are built and what we're looking to achieve.
We've covered the first two techniques. We've got one more to go, and that last one is heat. I think heat, or urgency, is really just as scary in both situations, but when you learn to manage it, you can really harness it to finish that end result. When you're cooking, and back to my taco metaphor here, the best way to heat up your tortillas for tacos is just to put it right over your burner on the stove, but you don't want to end up in this situation, right? Because if things get too hot, then you're constantly firefighting and that's not going to drive great behaviors.
What it comes down to is actually, again, looking to the experts like Marty Cagan here, how do we harness that urgency? What Marty talks about a lot is the risk of working in a situation where there's no urgency because people can just cycle. Teams can start falling back into their particular practice area and thinking about how do I design the perfect solution, how do I architect the purpose solution, what are all of the possible requirements that I might need to have, and you can end up in these endless loops.
If you understand the urgency of getting something out the door, and in fact there is true urgency, then it forces some pretty ruthless prioritization to make sure that we're not letting the perfect be the enemy of the good and that we're focusing on getting working software in the hands of users. This is why when we have these epic roadmaps that stretch over years before there's some kind of deliverable, the teams can get de-motivated and lost along the way. If we can create focused by harnessing that urgency, the teams can focus on something that can get out the door faster and we can start iterating on while providing value to our users.
Another important thing about urgency is it's not just about the team learning how to use it, but it's about creating focus for the business. If you've picked the right initiatives for the team to work on, there'll be enough urgency within the business that you can get the right people in the room. Here's an example of the working session that we did when building out that app for Capstone. You'll notice that this mission of creating community for their associates was so important that we have the CIO in the room and the CPO in the room. They were both willing to invest their time in making sure that the team understood the business value and the user value that they were looking to drive that they threw their weight and their investment behind getting this out the door, and they kept up the momentum because there was a responsibility and an accountability to deliver not just for the associates, but also for the senior leaders of the business to make sure that this app was a success.
All right, I started with tacos, I'm going to end with tacos too. This is a recipe for steak tacos. The truth is, there's lots of recipes out there, but it's not really about the recipe. It's about learning to balance the technique of those fundamental ingredients that we talked about. I hope you'll take this away and go back and think about how you're working with your product teams. As you set off to build your next great product, think about how you're bringing these techniques to bear and you'll be up and running. Thanks for joining me today. Hopefully, you took a little something new, and not just tacos.
Next month, we're going to have another great Full Stack Friday. This one's with Chris Wilkinson. If you haven't seen him before, he's a super engaging speaker, even through this remote format. He's going to be talking about accelerating through ambiguity. Of course, the last couple months have thrown everybody for a little bit of a curve ball here, but there's always some ambiguity when you're talking about building the next great product and you're not going to know everything upfront. Come meet with Chris, and let's all think about how we get through this together.
Thanks so much for your time. I am super interested in talking more about this and understanding where you've seen some of these challenges in your own organization. If you want to workshop ways to try something new, please do reach out. Hopefully, you'll join us again next week. Thanks, everybody.
About the event:
Full Stack Friday is a monthly meet up hosted by Devbridge where we share insights on product development, design, and process. The talks focus on issues relevant to product people and full stack teams. For more information about the next event, contact us directly.