← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
BONUS Unifying Strategy, Discovery, and Delivery in Product Development | Roman Pichler
00:38:05
Global Agile Summit Preview: Unifying Strategy, Discovery, and Delivery in Product Development With Roman Pichler In this BONUS , we explore a crucial topic that's shaping how we approach product development—sometimes in ways that serve us well...
Loading summary
Transcript41 lines
- [00:07]
Vasco
Have you ever wondered what it really takes to make Agile work well? At the Global Agile Summit, we're bringing you real life first person stories of Agile succeeding out there in the real world that will inspire you to take action. Whether you're a leader, a product innovator, a developer, you'll hear practical insights from.
- [00:30]
Roman Pichler
Those who've done it.
- [00:31]
Vasco
They'll be telling their own stories from the stage.
- [00:35]
Roman Pichler
I'll tell you more about this at.
- [00:37]
Vasco
The end of this episode. So stay back and listen to the full detailed description of what we have in store for you at the Global Agile Summit. But if you can't wait, you can go right now to globalagilesummit.com and check out our full schedule for now onto the episode. But I'll see you at the end of this episode with more details on the Global Agile Summit. Talk to you soon.
- [01:04]
Roman Pichler
Hello, everybody. Welcome to a very special bonus episode. And joining us in this bonus episode to talk about strategy, discovery and delivery of software products is Roman Pichler. Hey, Roman, welcome to the show.
- [01:20]
Thank you, Vaskos. Thank you for having me.
- [01:22]
Absolutely. So Roman has been in several of our summits, but I just checked, it's the first time he's officially on the podcast. So welcome to the podcast for the first time, Roman.
- [01:35]
It's great to be here.
- [01:37]
Roman is a leading product management expert specializing in product strategy, leadership and agility. With nearly 20 years of experience, he has coached product managers, authored four books and developed popular frameworks. You can of course find all of that in his website, the link is in the show notes and he shares insights through his blog, podcast and YouTube channel. So make sure to check all of those out. So, Roman, today we're going to talk about a specific topic that you and I have discussed offline, as it were, although it was online because you are in London and I'm in Helsinki, so we're quite far from each other. And it's this, the topic is this growing trend by some in our industry that want to explicitly separate product strategy from product discovery, and of course also eventually product delivery. And on the surface this seems quite logical. I mean, strategy is about deciding the right things to do. Discovery is about figuring out, okay, you know, what are the details of how that gets done, the experience and so on. And delivery is about getting it done. Just do it as it were. In Finnish we have a song. Here's the spec why aren't you coding? And I guess that would discover what.
- [02:57]
Vasco
That would define what many call delivery.
- [03:01]
Roman Pichler
When it comes to software. But is this Division really helping us or is it creating barriers that make great product development harder? Let's start there. Roman, what do you think about this?
- [03:18]
Yeah, I think it's a bit of, a, bit of both to be honest. Maybe. Maybe it helps briefly to reflect on, maybe it helps to briefly reflect on, I should say, where sort of the notion distinguishing between product discovery and deliveries come from. I think it's partly based, at least on Marty Kagan's work and his insight that many teams are very much focused traditionally on delivering outputs, on writing code. And I think his original intention was to say like, let's not worry about creating outputs. Let's also make sure that what we creating makes sense. And so you know, that we do sufficient, what he calls then product discovery. So determining how a business goal should be achieved, which specific user needs should be addressed and you've already mentioned at which features should be offered and what kind of user experience should be designed, should be created. And I think generally distinguishing between product strategy and product strategy related work, or strategizing as I like to call it, and then discovery and delivery can be helpful from a conceptual perspective. It's just a way to take different pieces of work, different activities, tasks, and lump them together a little bit like, you know, organizing our various clothes into different sections of the wardrobe or different boxes and containers. But in reality, I think you've already started to allude to it, of course, these different activities or these different, you know, we could look at them maybe as work streams or workflows. They have to be connected, they have to inform each other and they have to guide each other.
- [05:05]
I think it's very important to recognize that these three conceptual areas of thought and action, right? Because strategy is of course mostly thought, but it's some action, we're making some decisions. Discovery is a lot more action, but also a lot of thought and ultimately then delivery, which if you want to kind of categorize it in this spectrum, is a lot more towards the just do it perspective. And I'm sure you have seen, and I have heard many times teams complain, you know, endlessly about, oh, but this product people, they're always changing what should be developed. And this is so disturbing. Why can't we have the product all set up and defined already before the requirements come to us, right? Like it's, I guess a little bit of self inflicted pain on the part of the software development community when it comes to separating discovery and delivery, for example. Now I don't claim to have all the answers, I guess Roman, you don't claim to have all the answers either. But it's really interesting to reflect on this split, right, like, you know, the goal, just like at the Global Agile Summit, where we'll be discussing some of these questions more publicly, if you will. The goal is not to come up with all of the answers, but really doing, you know, discover, to use the word discover, maybe some different insights. And I think for this we need to investigate what is really happening out there. Like when you, when you work with teams, when you work with product people that are, so to speak, putting this separation in practice, you know, how does it work for them? What challenges are they facing when they clearly separate these three things?
- [06:54]
Yeah, I think you're touching on a very important point. So conceptually forming those, using those concepts can be very helpful. But then if we have a group of people who takes care of strategic decisions and carries out the strategy related work, we've got a different group of people. We might call that group of people the trio or the product team, who primarily focuses on product discovery. Not saying that necessarily. Theresa Torres, who coined the term product trio, intended it that way. Then we've got another group of people, the tech team, the engineering team, the development team, whichever term we want to use, who focuses on product delivery. And those groups of people maybe don't talk as much and don't work as much with each other as they could and should do. Then suddenly we have a sequential process and we have handoffs and we know that this will slow the value creation down. We know that this will lead to loss of knowledge and it'll lead to the likelihood that mistakes are being introduced. So I think that's something we really, really want to avoid. And the different techniques that we can use, we can think about discovery and delivery as more closely joined up. And we can think about, rather than doing the discovery and then doing delivery, doing it in parallel, or even doing it in a single iteration or in every iteration, every sprint, I should maybe say a little bit of discovery and a little bit of delivery, which I think was the way that Scrum was originally intended to be applied. Another technique we can do is that we form a big product team, a product team that is empowered to make strategic decisions and consists not only of the person in charge of the product and maybe a UX designer and a software developer, but also key business stakeholders, maybe somebody from marketing, maybe somebody from sales, maybe a support team member. And so that this bigger product team then takes care of the strategy work, at least some of the product team members take care of the discovery and delivery work. And again, there is a continuity and there is a strong element of collaboration.
- [09:07]
Yeah, absolutely. So you already touched on it. Right? Like, we can look at this separation and the risks that it brings. Like, a very obvious one that you already mentioned is the handoffs. And many of us who've been in the industry for at least, let's say, 15 years have probably worked in software development organizations where there were a lot of handoffs. And perhaps we understand the risks of that. And therefore, maybe it's why, at least on my part, I'm having a bit of an allergic reaction to this idea of separating product strategy, product discovery, and product delivery completely. There's always some separation. Right, but why do we need to separate it too much? And when I started thinking about this, okay, so. But why does it happen? Like, why do people want to intentionally. Intentionally or unintentionally separate these three things? And one of the things that came to mind is that there's this. Well, first of all, that they are different concepts. I'm not sure they are, and maybe we'll investigate that in a second. But we are schooled, trained in defining processes as linear, sequential steps. But in software, we've learned that this is not a good idea. In fact, one of the key contributions of Scrum to the cultural reality of our current software industry is this idea of the loop. Now, SCRUM didn't invent the loop, but Scrum made it popular. It kind of institutionalized the idea that there's a whole iteration in one sprint. You have the whole iteration. Right. Like you have a Sprint planning at the start, you have some refinement for the next Sprint happening, you have the actual implementation of the current Sprint happening, and then you have the review. So you get, you gather feedback from stakeholders, potentially customers at the end. So we're kind of trying to break free of this linear and sequential thinking. But in product, I get the impression, and you know that better than I, because you're, of course, completely in that community, the product community, when it comes to product development. It sounds to me that in the product community, we're still very much believing and following this idea that you can sequentialize any process separating steps, and therefore have a whole coherent view of the.
- [11:40]
Vasco
Product at the end.
- [11:41]
Roman Pichler
Is that what you think is happening? Why do you think that there's this need to separate and sequentialize these steps?
- [11:50]
Yeah, it's a great question, and I'm not sure that I've got the one right answer. I think to a certain extent, certainly when you look at the rise of or how popular product discovery has become in the product management space. I think one of the reasons is that it gives a product people a clear focus and says like, you know, here is an important piece of work and it is an important piece of work or area of work that you should really attend to, that you should take care of. Of course, it's not the only thing that a product manager or Scrum product owner should do. And so, you know, maybe to a certain extent at least some product people have focused a little bit too much on that specific area. And you know, some product people are more comfortable working with development teams than others. And so if I can focus more on figuring out how to meet a business goal, which specific user customer needs I should now try and meet, and you know, what features need to be provided and which user experience needs to be created, then, you know, that maybe frees me to a certain extent from having to engage too much with the development teams. And maybe it's not only that I don't like it so much, but maybe it's a lot of work and I don't want to get dragged into having to refine user stories and talk about the details of user stories with the team and be a product backlog manager. That's not really what my job is. And I think I'd agree with that. Again, you know, it's the problem then is if we kind of start combining an area of work and a focus with process and a timeline and assume that all the discovery has to be done, or the vast majority of the discovery has to be done before development or the delivery related work can start. And as you've already said, that's not necessarily the idea that we need to do maybe a little bit of pre thinking and a little bit of prep work. I think that's okay. And that may well be the case. But then the majority of figuring out how, how do we address specific customer and user needs and achieve a specific business goal and what functionality should be provided in detail and how exactly, what exactly should the user experience look like? I think that's something that should be then part of an iterative agile development process. But again that assumes that product people and development engineering technology teams work closely together, which again, I think has been one of the aspirations of Agile methods. I mean, you look at extreme programming and you've got the on site customer. Well, you know, the clue is in the on site customer. It is extreme. Hey, or Instagram, you've got the product owner, but again, you know, the person who's meant to own the product on behalf of the company and be sufficiently empowered and respected to make decisions and move the product forward together with the tech team. So I think for me, you know, that's a very, very important idea. Bringing product people who have the knowledge about customer user needs, have the knowledge about how the company works, have the knowledge about the business model that is used to monetize the product if it's a commercial revenue generating product, and maybe not maybe have the connections to the business stakeholders, bring those individuals together again with the tech teams in order to create innovation and foster innovation, enable innovation and create value. So yeah, it's about bringing people together. But again, many product people I do meet are being pushed into a corner where they end up being user story writers and product backlog managers. And you know, I can, I really sympathize with anybody who's trying to get out of that corner because again, that's not what product people are there for. And so if you turn this around, then product discovery and focusing on that specific area has given product people again, something to own, but also something to use in conversations with the boss and senior stakeholders saying, look, you know, my job is not to write the detailed requirements primarily my job is really to make these type of decisions and in fact I should be empowered to make those decisions. I should be empowered to decide which specific user customer needs should be addressed. I should be empowered to decide which features should be implemented. And I don't want to be pushed around by the development teams and I don't want to be pushed around by senior stakeholders. But often again, product people find themselves in that situation. And so then product discovery can be something really valuable, something really valuable to hold on to.
- [16:15]
And you've talked about discovery in your expert position that you just conveyed. But there's the same argument can be made about this strategy, right? Like we can also say that product people should focus on the strategy of the product, not only on the detailed user stories of every day and going into what might be, you know, several meetings every week to do the refinement, to do the planning, to do the review, and so on. And this brings up another aspect which we've already tackled to some extent on the actual software coding and testing side of the business, which is that we've brought people together, we've shared the responsibility and we've created this idea that the whole team owns the, let's call it delivery. Now for the sake of argument, since that's what, what we are discussing. But somebody, and even Scrum says somebody needs to own the strategy and the discovery. Scrum says that it is the product owner. We all know that one person cannot own all of that. Which then raises the question, okay, other than in very trivial software development efforts like, you know, a team of two developers and a product owner, for example, other than that type of efforts, we also need to understand that strategy and discovery, when it comes to the product side of the equation, cannot be done by one person alone. And maybe the product owner in those contexts should be more of a Scrum master of a product team, right? You know, gathering the input, doing the research, getting research done by other people. For example, the market department might need to do some research interviewing salespeople. If that's the case, for example, in B2B scenarios, that would be a very simple way to get started with the research and so on. So what we are discovering, maybe I'm just questioning here, not, not sure what the answer is, but maybe we are discovering that the product role in software development, especially in larger software development efforts, needs to also be a team sport. What do you think about that?
- [18:15]
Yeah, absolutely. I think it's called product management. But it's all about people, right? It's all about creating value for users, customers, it's creating value for the organization. The organization is a group, a collection of individuals at the end of the day. And it's about interacting with stakeholders. It's about interacting with developmental tech teams. I think I'd like to sort of take it in a way a little bit further and see the product owner, the Scrum product owner, product manager, not only as a facilitator, but really somebody who leads a product team, who leads a cross functional product team. And a product team that I would suggest consists not only of a few people, including a designer and a software engineer, but also key business stakeholders. So those are stakeholders who might be from marketing. So it might be a marketeer, might be a sales rep. Those are stakeholders whose expertise is required to make the right strategic decisions and whose support is also required in order to progress the product and who may actively have to do some work. So for instance, a marketeer might have to create or update the marketing strategy and create some marketing collateral. So, you know, actively actively help progress the product. Now the reason that quite often organizations in my mind use small product team. So the good thing is I think that there has been a change in the industry and for me that's a positive thing that more organizations have started to use, at least that's my impression, have started to use product teams. But often These product teams seem to be small teams. And the number of reasons for this one is these teams are comparatively easy to staff. But the drawback then is these teams are focused on discovery. They lack typically the expertise to make effective strategic product decisions. And then another reason is that often the head of products, you know, chief product Officer, Director of Product management, VP of Product management, or you know, what other, you know, what other title that the person might have, often then owns the product strategy and makes the strategic product decisions. And so for me, again, it's nice to empower a product team, form a bigger product team and then empower that product team to collectively own the product strategy and thereby have a holistic ownership of the product and not just the delivery part or not just the discovery part. I mean, in fact, if somebody owns only the delivery, then that person I guess will be a project manager. That wouldn't really be a product person.
- [20:58]
Strictly speaking, more like a project micromanager than a project manager also.
- [21:05]
That's right, yeah.
- [21:06]
So one of the models that I've been toying with in my mind when thinking about this strategy, delivery, discovery, is this idea of a three dimensional space where one dimension is strategy, the other is discovery and the other is delivery. And when I think about that, it helps me to realize that we can't actually move in any one single direction in a three dimensional space, right? Like for example, when you move the strategy in some direction, you're necessarily affecting discovery and delivery. Maybe more discovery, less delivery and so on. That's a possibility. But they are all interlinked. And what I find useful with this mental model is that we need to create that product team that you were describing a moment ago. We need to create that product team with the necessary skills and understanding to be able to assess the impact of certain decisions. Otherwise we go back to the waterfall thinking, right? Like where strategy is defined here and then next is discovery and next is delivery. And then we, we start finding out that there are missing loops, right? And then we start building the loops. Maybe we end up with a V model of product management, right? Where you have the activity of strategy being compensated by some kind of strategy validation and so on and kind of going through the V model that way. But when we think about this as a three dimensional space, we can then reason about the consequences of making strategic decisions without delivery and discovery impact. And one of the things that I work with, the teams that I consult is this idea that everything is an experiment, right? Like a strategy isn't a statement, it's a question that needs to be answered.
- [22:54]
Right.
- [22:55]
It might be even several questions. Right. You can't say this is the strategy. You usually say, would this strategy give us the outcome that we want? And then you might want to run a very quick experiment in order to validate that. That could be done with delivery, that could be done with discovery, or it could be done with a mix. And then when it comes to discovery, we have the even more obvious example, which is if you can run a few paper prototypes, user interview questions, together with the delivery aspect, like doing an a B test or whatever, you're gathering much more relevant and applicable information than if you are doing discovery without any delivery. So that's how I'm starting to think about it, about these three things. Strategy, discovery, delivery as kind of an entangled, if you will, three dimensional space. When you explain to the people you work with the need to consider these three aspects, what kind of metaphors do you use?
- [23:58]
Yeah, so first of all, I think it's a nice image. I think generally speaking, it's a very helpful image that you've, that you've suggested. What I usually use as a visualization tool is three work streams. So a strategy work stream, a delivery work stream, and sorry, a discovery strategy work stream, a discovery work stream and a delivery work stream. Too many streams. And so the strategy stream guides and directs to a certain extent, the discovery stream, the discovery stream guides the delivery stream, and then the delivery stream informs the discovery stream, and the discovery stream informs the strategy stream. So these are your feedback loops then. So those three streams, those different areas of activities have to be joined up. The reason that I like the image of a stream is because I find that traditionally when people think about strategy, they think about a stage or a phase. And some strategy books, some books on product strategy still portray it that way, and there's some truth in it. And that is when we build a brand new product, when we carry out new product development, we initially need to do some strategizing and we may want to do some upfront strategy validation just to make sure that we've explored the different strategic options and those that we've captured are likely to be meaningful, they're likely to be helpful, and we've got some form of empirical evidence that supports the strategic decisions that we've taken so far. But generally speaking, for most parts of the product life cycle, the strategy runs in a way, you know, the strategy work. So I should say the strategy work doesn't go away. So, you know, we've launched a new product and, you know, the Strategy doesn't go work, it doesn't go away. But now we need to rework our strategy in order to achieve product market fit. And once we've achieved product market fit again, we have to adapt our strategy to ensure that our product grows and continues to grow and so forth, so the strategy work doesn't go away. And hence it's best understood as a workflow, a stream, rather than a stage or a phase. And so, yeah, that's why I like the stream image. I find that helpful. But at the end of the day, I think the ideas that you've shared and what I've shared are very closely related. The important thing is to make sure that the different areas of work are not disjointed, but they are interlinked. And a key element to make that work is to use collaboration and teamwork and ensure that there aren't any handoffs or avoid handoffs as much as possible, but rather involve a group of people, a product team, to get the various pieces of work done.
- [26:44]
Yeah, and I would say that if we have to have handoffs, pardon me, at least we should have handoffs that do not increase the risk of failure. And here's a concrete example. If we have a handoff that is the whole strategy, right? Like the handoff is the whole strategy, then there's a lot of assumptions, a lot of things that are implicit and not explicitly stated that are going to be transferred to someone else. That's a handoff. But all of that implicit knowledge does not come with that document or artifact that is being transferred. Right? Like many, many years ago, I already used this idea that information is not conveyed in documents. It's conveyed in dialogue or conversation through Q and A questions and answers. The document becomes a shared repository of that knowledge and needs to be updated, and so on and so forth. And in the actual coding and testing part of the software development, we have already understood that. Right. Like, for example, you talked about work streams. A product architecture is continuously being updated, even if some of it was done up front, it is continuously being updated. And many products actually go through several architectural generations. Right. They start with one architecture, they evolve that architecture, and so on and so forth. And the same thing with software design. We've learned to incorporate architecture design and coding and testing into the same loop. And I think that the work stream might be a great way to inform that concept, that they actually are working together in parallel and they need to inform each other when this has worked successfully in your experience, Roman, what have been the key aspects? Right. We've talked about having product teams. Maybe that's one key aspect. We've talked about collaboration. Right, like instituting collaboration spaces like regular syncs or design reviews or whatever that might be. What else do you think needs to be there for this three streams and therefore our understanding of the holistic software development process to work.
- [28:57]
Well, yeah, I think you've already mentioned two really key aspects. Using teamwork and forming a big product team. What I would call a big or an extended product team. Obviously staffing that team with the right people, attracting the right people, giving those individuals the necessary time and focus to work on the team and carry out the necessary work, have regular meetings. So a specific recommendation that I like to make is to have quarterly strategy workshops as a rule of thumb, where the current product strategy is reviewed and adjusted, but also the current product roadmap is reviewed and adapted. And so these plans are kept in sync. And, you know, and part of that is to see are there any bigger product backlog changes and are there any bigger insights from the development work, the. You could say the delivery work that inform any changes to the roadmap and possibly to the strategy, but then also use the strategy and particularly the roadmap changes to direct the product backlog and inform any necessary changes in the product backlog. So I think that is really important. And then, yeah, I think that's it.
- [30:13]
And that's a concise and very clear set of ideas to put in practice. These are all ideas though, everybody. So don't take this as the orthodoxy of product development going forward, but rather insights and maybe perhaps even inspiration to action, which is really what we are on about when it comes to this podcast episode and also the Global Agile Summit. We want to create knowledge that helps you experiment, to try different things out, and then of course, hopefully also come back and share what you've learned so that we all can grow and learn as a community. We call this learning out loud. Right. We don't always need to have all the answers. We can have the questions, discuss them, and therefore learning together.
- [30:59]
Absolutely, absolutely. And I think, you know, from, from a Scrum perspective, you know, there's a very interesting, in my mind, a very interesting change there, and that is to move away from having a product owner and then developers or development team and a Scrum master to saying, actually we need another role in a way, we need a product team. And that's also then a great way to integrate the business stakeholders and bring them together with the developers, the development team and the Scrum product owner. Yeah, absolutely.
- [31:30]
Vasco
All right.
- [31:31]
Roman Pichler
So Roman, people have heard you. They hear some of your ideas, which I'm sure they will want to explore further. If they do, where should they go?
- [31:40]
Yeah, that's a nice question. So the best place to go is my website, Romanpichler.com and you'll find my blog on there. Vaskos already mentioned it. Podcast videos, little tools and frameworks that you can download, and a link to my books if you're interested in exploring my ideas further. So yeah, check it out. Hopefully you'll find something that is useful for you.
- [32:07]
Absolutely. And definitely check out Roman's podcast. There's a lot of great insights and also episodes on this very topic of product strategy that we've approached as one of the three areas, or I like to call them the three dimensions of product management in software. At least I don't claim to talk or speak for any other industry. So let me just be very clear about that. Roman, it's been a pleasure. Thank you very much for being here with us, for sharing your insights and your knowledge with the wider community.
- [32:42]
Thank you for having me. It was a pleasure. It's really nice talking to you. I hope it was useful to everyone who was watching and listening. And yeah, good luck to everyone with aligning strategy, discovery and delivery for your products.
- [32:57]
Reach out if you do have questions. Roman's website has all the necessary contact information to reach out. Roman, it's been a pleasure. Thank you for your generosity with your time and your knowledge.
- [33:09]
My pleasure. Thanks for having me. Vasco. Bye.
- [33:15]
Vasco
Hey friend. Thank you for staying here. Is all you need to know about the Global Agile Summit. If you've ever suffered or know people who are suffering from from agile fatigue, this event is for you. Agile fatigue is that feeling that settles in when we can't really see a light at the end of the tunnel. We get discouraged, especially when conversations revolve around the same old frameworks, the same old buzzwords and theories. We don't feel that energy anymore. Well, the Global Agile Summit is a different kind of event. We're bringing you real life first person stories of agile succeeding out there in the real world that will inspire you to take action and transform the way you work. The Global Agile Summit will happen In Tallinn, Estonia, May 18th. That's the workshop day. Then 19th and 20th, the conference day. And Tallinn, Estonia is one of the most innovative tech hubs in Europe. The Global Agile Summit is hosted together with Latitude 59, which is kind of a citywide celebration of software startups and groundbreaking ideas. And we'll have A shared ticket for you to attend those events as well. So who will be speaking? Well, we've got an incredible lineup of thought leaders in software and agile. For example, Clinton Keith, the person who wrote, literally wrote the book on game development with Scrum and is busy bringing Agile to the world of game development. You must check his session. The very famous and well known Jurgen Apello, author of Management 3.0, will be talking and exploring about AI's impact on leadership. We also have Goiko Adsic, who's taking.
- [35:06]
Roman Pichler
An unconventional look at the product growth.
- [35:09]
Vasco
With his Lizard Optimization keynote. Other speakers include, e.g. sig Sven Dietz, who's challenging everything we know about software development by ditching, literally ditching contracts and estimates. Can you imagine his teams deliver software before their competitors are even done with a contract negotiation? How Agile is that? But there's more. We'll cover engineering practices in our development developer track with talks on, for example AI assisted test driven development, developing products in minutes with a different approach to how we develop, configure, deploy platforms, and much more. We also have a product track where we cover cutting edge ideas around product discovery, delighting customers with product delight frameworks. We'll have a talk about that. And we also have an Agile business track where we will talk about, for example, Open strategy, a very agile approach to managing organizations and delivering software faster to clients faster than you can even write a contract. Literally. I mean, I already told you about Svendit's story is amazing. It definitely is amazing. A must see. I'm sure you'll be inspired and get a lot of ideas for your own software projects and software delivery. Now, whether you're a business leader, a product innovator or a developer, you'll definitely find value in our three focused tracks. That's Agile Business for those working with businesses and organizations. Agile Product for product management managers, product owners and innovators. An Agile developer for the builders making Agile work in practice. The coders, the testers, the designers, the producers, the Scrum masters, you name it. If you join, you will meet over 200 agile professionals from all over the world. People who just like you, want to grow, want to share and want to learn. Learn by challenging the ideas that don't work anymore. At the Global Agile Summit, you'll get new connections, fresh ideas and the energy to take your own Agile to the next level. And who knows, maybe even find your next career opportunity. So don't miss out. Check out the full program and grab your ticket now@globalagilesummit.com I'm really looking forward to seeing you all in Tallinn, Estonia, in May. I'll see you there.