Lindsay Velecina: 0:03

Welcome to the scrum.org community podcast, a podcast from the home of Scrum. In this podcast we feature professional scrum trainers and other scrum practitioners sharing their stories and experiences to help learn from the experience of others. We hope you enjoy this episode.

Leslie Morse: 0:19

Hello, listeners. Thanks for tuning into this episode of the scrum.org community podcast. I'm your host Lesley Morse. It's exciting to be with you as a guest host for this discussion. I am joined by Jo Geske. He is a professional scrum trainer and works as the chief product officer and Managing Director of amazing outcomes in Germany. In today's chat, we're going to be exploring the story of how the amazing outcomes plug and play scrum team was able to help one of their clients get a mobile app into their customers hand in just three Sprint's Joe, thanks for being with me today. I'm really excited to talk to you more about this.

Johannes Geske: 0:56

I left me thanks for having me.

Leslie Morse: 0:58

You're welcome. You're welcome. Before we dig into the content and in the in the information that we've got in the supporting case study, just tell us a little bit more about you your journey as a scrum professional. What got you here to this conversation today? Sure.

Johannes Geske: 1:16

I started as a programmer back in the 90s. And then after university, I got a job at a digital consultancy helping clients build their products and services for their customers. It's in 2005 when I discovered Scrum, and I found it immensely helpful in helping our clients build better products faster. And then later I did an MBA and I started my own company amazing outcomes. Where we help businesses, mostly, mostly international mid sized companies create better products that create more business value sooner. In 2015, I tried to route a crisis project using Scrum and Nexus. And in fact, I think it's one of the first Nexus implementations in Germany. And 2019 scrum.org invited me to join their PSD community. In 2022, I started to shift my focus from leading teams as a scrum master, to leading products as a product owner for our clients. And that's how we started to think about how can we improve things on the team side. And in 2023, we created our own scrum team at amazing outcomes, mainly as a response to people and organizations saying scrum doesn't work for us, or you need at least x month before you can deliver an increment because we said no, that's not the idea of Scrum by that's, that's not how you will get a lot of benefits from it. And we knew that we could make use of Scrum in a way that we will be able to create better products that make more money faster. And that's how we created the plug and play scrum team and I am the Product Owner of that. And today I'm here to share what I think is an exciting story how we help the client. Yeah, I

Leslie Morse: 3:07

think it's gonna be an exciting story. Everybody will be jazzed about as well. There's, um, you touched on it there at the end of like, really like using this way of working to help people create more value and success in their business. Was that the hook for you back in kind of the early 2000s when you learned about Scrum, like what? Like, because when you tell that story, it sounds like Well, yeah, I learned about this, and I'd never went back. What was it that that was that was the hook that kept you in this this universe. I never

Johannes Geske: 3:40

went back. Indeed. I was a technical consultant and a project manager before. And I had this recurring experience of coming back with an updated plan to my team and the client, as a project manager. And then they told me Yeah, but that was yesterday. So there is a new thing that change, right? Sorry about that. But seems you have to go back and update your plan again. And I thought, okay, I can do that. But it's not how I add a lot of value to the product. Right. So when I when I heard about Scrum, I immediately thought that sounds like the solution to the problem I have. And I think our clients have, because it's not about the project. It's not about the plan. But it's about the resulting product. Right. So I never went back. Yeah,

Leslie Morse: 4:35

yeah. When it's like you think about like you go to the gym when you see the results that keeps you going to the gym, you know? Oh, yeah. Yeah, it's it makes a difference.

Johannes Geske: 4:45

It is in a in a positive way. It's addictive. Absolutely. Yeah. Yeah.

Leslie Morse: 4:50

The the story of what the amazing outcomes plug and play scrum team did with your client sto I think is a great illustration of like really achieving outcomes very quickly. And as someone who has been in and around Scrum teams for more than a decade, I've never been on a team that's been this successful. So it's kind of astonishing, like, this is what it's really about, like, this is what you're going for. So how did you know that this approach was going to be successful within the sto environment? And share with us a little more about like, who sto is? And what is going on in their context? And kind of the groundwork for this case study?

Johannes Geske: 5:37

Yep, sure. Stowe is a manufacturer of products and systems for building coatings. They're headquartered in Germany, but they sell their products worldwide. And while bigger customers of theirs procure their products through SAP, there is a web based online store for smaller companies to procure their materials, and still wanted to increase the use of that online store. They had some ideas how they could do this. And they wanted our help to validate their ideas and create the right product quickly. So when they asked us for help, and we knew they had a complex problem at hand, right, they made a lot of assumptions about the cause of the problem. And their solution to that. And they told us, they didn't feel like prudent to it didn't feel prudent to them to invest a lot of time and money in building something that might or might not solve their problem, which might put it off money at risk. And that's not how they do business, right. So this called for a way to test their assumptions real quickly to learn what's right, what's wrong and build the right product quickly, while at the same time managing the complex risk coming from not knowing is this really a good idea? So that's, that's why we why we use Scrum, right? It's a tool, a means to an end that helps us do exactly that. discover what's valuable, deliver a valuable product to their customers and their business soon. And when when they ask us, we told them right from the start, we give you answers to your assumptions, we give you insights into what your customers really need. And we give you an E version of your product at least once every two weeks, maybe even faster, right? So we told them, we will we will use Scrum for that. And your people in your organization are welcome to join our team or collaborate with us. But we're not going to discuss whether or not we do Scrum. So we set the expectation right at the start, and they were happy with that.

Leslie Morse: 7:47

And was there any pushback or like uncertainty for them? Because it sounds like you were holding pretty true like this is if you want to work with us. This is how we're going to do it, because of all these reasons. But I imagine they didn't just like Sure. Okay, like were there any interesting learning moments in those discussions?

Johannes Geske: 8:08

Not at that point. Okay. They had previous Chrome experience. So they knew it was supposed to help them get more benefits sooner. They were a little skeptical about us saying we can do that and we delivery deliver you a new product every two weeks. Right. But they said yeah, okay. I think we knew we know what you mean. So go for it. I mean, they they called us in as experts. So they trusted us to get the job done. Yeah.

Leslie Morse: 8:38

When I think that that skepticism about delivery is something lots of organizations face when they're new to Scrum and all of that. And that idea of getting to done at the end of a sprint in the rigorous discipline around that is one of those differentiators is we think about professional Scrum, right and the way we talk about it within the scrum.org community. So what is unique or important for the amazing outcomes plug and play scrum team that actually enables them to achieve that level of discipline and success and professionalism with how they execute the scrum framework?

Johannes Geske: 9:22

Well, when we hired the plug and play scrum team, we told everyone we're going to do Scrum. And that's non negotiable, right? We wanted to create a team that spends their energy in creating the best product for the customer. And not a team that would spin in circles debating Scrum and not getting anywhere. Again, so we set expectations right from the start. And I think that's essential to be really good at delivering a new version of the product many times during the sprint for sure it was even daily sometimes. And that made us really far. Last in delivering value and responding to new insights that we learned while talking to their customers, right? So we were also fast in adding features, which we learned were necessary. And we were fast to decide not to add features that weren't necessary the same time. And what's what might make us unique? I don't think I think there's, there's not it's not a rocket science, there's no magic stuff going on, right. But we're really good at focusing on the goal. And we do have one piece flow in the team, meaning the whole team, all developers together, they work on one product backlog item at a time, they get that two done. When they get it to done, there is a new increment. And only then they start working on the next product backlog item. Right? There's a bit of automation going on. It's software, you can automate bits and pieces of the built in delivery process. Of course, we do that. But most importantly, we are good at finding ways to deliver solutions that aren't feature uploaded, that have just the right features at the right time. So when you're fast, you can go a long way with building only little features. Because if you learn that you need more, you can add them fast, right? So you don't get into the habit of stuffing your your releases, with lots of features, which delay releases make them complicated, right and error prone. We don't have that. Yeah. And

Leslie Morse: 11:35

what are the what are the methods that you use spurred that decision making on what is and isn't important? Because we see a lot of emotion based decision making around features. And I know this is going to tie in to kind of evidence and evidence based management maybe that we'll talk about more later. But if you really focus in on the deciding what feature is or isn't necessary, what does that look like on a day to day conversational level?

Johannes Geske: 12:07

Sure. It's all started with talking about the assumptions, right? But at some point, rather sooner than later, you need to get empirical about it. And scrum as a framework gives you all the right feedback loops to do that, right. But it just doesn't tell you exactly how. So it's kind of easy to get lost in Sprint's and being all busy without really knowing if you deliver value or not. Right. So which is why we, as a team, we can't afford that, right? Our value proposition is that we give a new version to a client at least once every sprint. And we can't afford not to because our clients pay US per sprint, right. So if we, if they don't see value, they might not ask us back, right. And that's why that's why we like to add a bit of governance around Scrum, to help us keep track of where we are to be more transparent with stakeholders about why we do this, and how we measure progress and value. And when you do add governance around Scrum, it's important that you that you choose governance that doesn't impede your fast feedback loops and fast delivery and empiricism. And to us the answer and doing this is evidence based management. Right? It's it's a it's a cool concept to add. And with store, we did it in a way that we agreed on a strategic goal that make clear how the intended solution would align with their business goals. And then we had an intermediate goal, the product owner and Scrum that gave us a clear direction for a series of sprints and allowed us to measure progress and value more quickly. And we also added some key value measures that we tracked by directly talking to their customers or even better observing their behavior and how their behavior actually impacted our our protocol. So that's how we how we turned conversation and delivery from working with assumptions to working with the data we got by by giving their customers the product that we build a lot of times really already throughout the process.

Leslie Morse: 14:19

It also sounds like you had the direct access to their customers, which is not necessarily something that all of our listeners have the privilege of having like a lot of times we've got Scrum teams that are have customers and I'm using quotation fingers with my boys who were really just internal stakeholders that are still two or three steps removed from actual end customers. So was was natural customer collaboration already part of Stokes culture, or was that sort of a shift you had to work with them on?

Johannes Geske: 14:53

I don't know if they were used to to do that. But we made it clear that in order to deliver value quickly, we need a direct customer access. And I know it's a touchy topic for many organizations, right? They are not used to they don't feel comfortable giving direct customer access to their external partners. But we told them, If you want to avoid wasting money on something that might turn out as a Not, not as a great idea, we need direct customer access. And I think we were just lucky to work with it with their head of ecommerce. Who saw that on it who helped us do that, right. So they made it, they made it happen, right? It's rare, but they just made it happen. And as a result of that, the head of E commerce and me we were traveling a lot select customers, many times throughout each sprint, having the latest version of the app with us. And we asked their customers to use it right. And we asked them to use it in their office, in their workshops or on their construction sites, basically, wherever they were to get their job done, because we wanted to observe how they would use it. And then we talked to them. We asked them to think out loud. And that was really helpful to see how in some areas we were right. And in other other areas of the application, we were wrong. And we were just quick, quick to correct this.

Leslie Morse: 16:24

That's, and that only happens from that direct observation and conversation with the customer. So like, I want to segue away from the actual case, study a little bit and just get some of your perspectives and thought leadership here around. You're honest, like somebody's on a scrum team, they don't have that access. Any suggestions for what they can do to get it maybe part of me just like, we'll just do it ask for forgiveness, not permission. But that sounds that's easier said than done. So if you're working in an organizational structure where that direct customer access is challenged, how, what tips or tricks might you suggest for somebody?

Johannes Geske: 17:05

Hmm, great question. Well, if that's not the habit of the organization, it will be part of the Scrum Masters job to cause that change, right? Because if you do not have that direct customer access, parts of your empirical feedback loop will just break down, right, you might still be able to create an increment regularly and often right, fine. So that kind of manages your risk. Your visibility risk, right? It tells you whether you are able to build something real quick. But you still don't know is that the right thing to do. And you cannot replace that through surveys. Or just by talking about a product right or giving the marketing material. That's all nice. And that will be things we do like early on, right staying under the truth curve. But as soon as you start building something, there is only one empirical way of validating whether it's useful. And you need to give that product to your customers early. And of course, we had the conversation with Stuart about is it? Is it too early? Is it going to be embarrassing? Are we going to hurt our brand? So we told them, Look, we can tell them right? This is a product made by the plug and play scrum team. It's not necessarily a product made by you. Right. So if they don't like it, it's probably our name that would stick with them. Right? So no worries about that. Well, we don't we're not worried about this, this this problem, right. And I guess when they when they saw this, and they saw how giving a an incomplete product to some of their very skeptical customers. I mean, we're talking about trades people, right. Some of them were a little older, not used to use technology or mobile applications. And when they saw what they could do right on the construction site, right, finishing that job at hand running out of materials, and at the push of one or two buttons, they could order rib resupply being delivered to them right on the construction site next day. Right. So that's when they started to, to smile and ask when can I get this? And I think as soon as you see that, all your anxiety about delivering an incomplete product or giving direct access to customers. It goes away. Right it becomes less of a problem. Yeah, so to answer your question, no, there is no there is no shortcut. There is no there is no good alternative to not having direct customer access.

Leslie Morse: 19:52

Yeah, and I think you do a good job of calling out an aspect of Scrum Master accountabilities that are often marginalized and organizations and that is scrum master service to the organization in working through with leaders and other key stakeholders, those impediments that diminish the success of Scrum. And in this instance, that example is the team's direct access to customers to fuel that empirical process. Absolutely. Yeah. Yeah. The it's hard to imagine that this wasn't a transformative experience for sto because I make up based on what I've read in the case study, and in talking to you that they weren't already necessarily using agile ways of working in any method, right or not, you're already using Scrum. So how did their experience engaging with the amazing outcomes Plug and Play team really shaped their overall approach to agility in, you know, rapidly delivering value to customers?

Johannes Geske: 20:59

Well, they realized that there was a difference in how we use Scrum effectively versus how they were used to use it. Okay, we were using the same process, right, but we create an increment every day, allowing us to deliver value and discover new insights really fast. And that gave them ideas how they could further increase their own effectiveness by using Scrum less mechanically. And like using it more Scrum, is intended to use. And as giving that example of what's possible it, it convinced some other senior stakeholders who were skeptical to set up their own product focused Scrum teams within their organization. So in that regard, it was actually transformative because they could start to think about product oriented Product Center teams, and not project oriented teams. Right. So that's, that's a change currently going on in their organization. That's great.

Leslie Morse: 22:05

It's just sometimes having the opportunity to experience scrum done well. That is the thing that can help unlock that art of the possible. And I don't, I don't want to miss out on an opportunity to touch just a little bit more on this difference between mechanical Scrum and professional Scrum, like I've alluded to it, and you've alluded to it, but you kind of you mentioned it very specifically, in that last response. What for you are those key differentiators that 10 of take scrum from that mechanical to professional lens?

Johannes Geske: 22:46

Number one, you need to deliver an increment regularly and often at least once per sprint even more often, if you can. If you don't, you don't even know if you can build it. Okay, so that's step number one, when you are there. The next step would be to release that increment early enough, because if you don't, you still don't know whether or not it's useful. Right? And you still don't know whether or not it's good business for you. Right, so those two things are key differentiators between going through the motions, or using Scrum as a means to an end, not the end.

Leslie Morse: 23:31

Does that make sense? It does, it does. And it just makes me think about how often Scrum teams are rapidly delivering the wrong stuff. Because we're focused on the delivery and not actually the empiricism that comes from observing and watching and experiencing how customers are using that product or service in the market to then inform the future decisions we make. Not only kind of in that moment at the increments delivery, because they might like it in the moment, but then six months later, it's not working anymore. So like those disciplines of the feedback loops, and how it's easy for organizations to shortcut that part of the process. And things in it. Because you were only engaged with sto for three Sprint's around this app, then what are the practices you would hope they would be using or you would be using if you were still in control of it, because I think that would be interesting to kind of clue people into.

Johannes Geske: 24:33

I have four pieces of advice but just to steal but to any company that wants to deliver more business value sooner. One is use any tool or framework as a means to an end and not the end. Right? It's never about the tool or the framework right. The second piece of it was device is what we've already been talking about have direct access access to your car customers, right. And then measure how each new version that you deliver changes their behavior, and how that change and behavior supports your goals. Right? If it supports your goals, great, right? If it doesn't, then then pivot and change your product. And then have a product owner who is not just a market expert, but also an expert in the strategies and tactics to build a product really quickly. Because that's most important. If you learn to deliver fast, like every week, maybe or even faster, you won't feel like you have to put a lot of features into every release, right? Because if you put a lot of features into every release, it's going to negatively affect your time to market, right? If you don't have to do that, if you can deliver really fast, you can afford to build less. Knowing that if you need to build something else, you can do this really quickly again, right. And that's how we get really fast. And I think that's, that's probably be the magic part of of using Scrum, right?

Leslie Morse: 26:10

Yeah, yeah, the, there were so much I want to unpack in there. But we've got limited time together. So I'm going to manage that curiosity of myself. But I do think there's, there's something that you're alluding to, because there's, at least for me, and I don't know if it's going on for our listeners, some parallel processing happening, right. This is a story of you working with sto to deliver a mobile app that improve their e commerce, sales interactions with their customers, it was also a story of amazing outcomes, using their product of a plug and play scrum team to deliver value. So what is the product owner of this product? That is a scrum team? What What was your empiricism and your learning around that product? In this interactions that helped you improve its ability to deliver value, we need

Johannes Geske: 27:13

to be true to our value proposition, right? If we promise we give you a new product version, every sprint, we need to set the constraints really well. And part of that is saying, We'll do Scrum. And that's non negotiable to us, right. And you as a customer, you shouldn't really care what we use, because you want the end result. So that's one thing. The other thing is, I was surprised how much a small team can deliver. It's a very small team. Right, and yet they deliver a new version every day if need be, right. And I was also surprised how I as a product owner, I thought I had great ideas about what to build on next. And then my developers, they had ideas how we could achieve the same outcome, right, validate the same assumption, or help a user get the same job done by building less. And that's super cool. So that's one of my my biggest personal, biggest learnings, that if I, as a product owner, just stuff, my ideas or my stakeholder input into a product backlog, and I don't really talk about that with my team, then we're going to miss a lot of opportunities in delivering more business value even sooner, right? So I take care in talking about those ideas with the developers. And then they challenged me a lot, sometimes it can, it takes a lot of energy, right? Going through that. You think, Alright, I've got it all figured out. Right? It's all been like in the product backlog. Let's just quickly talk about and then start doing it. But that's when it's really good to be patient and listen to them. Because many times they have the better the better, better idea, you know, and then we follow that idea. And that's how I learned well, I don't have to be the smartest person in the room as a product owner write better and smarter decisions may come from anyone on the team, and there's nothing that can replace that. So you need to have that conversation.

Leslie Morse: 29:26

Yeah, I one of my favorite things about recording podcasts is that there is always a very salient moment where it's like I needed to hear this. This for me Joe was that moment and so I hope other listeners are feeling that same emotional resonance with what you just described as you're learning as a product owner going through these Sprint's with sto before we wrap up any final thoughts any final wisdom you want to share with listeners but

Johannes Geske: 30:01

not really. So follow, follow use the four tips, right? See, see how well they work when you just run an experiment on them. And you don't need to buy this face value, right? Just just give it a try. And then see what comes out with that.

Leslie Morse: 30:20

Excellent. Excellent. Thank you, Jo for your time. Thank you for sharing the story of how this has been me. Yeah, you're welcome. You're welcome. Thank you for sharing this story. And we hope everybody goes and reads the corresponding case study. All right. Thank you again. You're welcome. Thanks, listeners.