← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
BONUS Challenging the Agile Status Quo with #NoBacklogs | Allan Kelly
00:36:52
BONUS: Challenging the Agile Status Quo with #NoBacklogs, Allan Kelly In this BONUS episode, we explore the provocative ideas of Allan Kelly, the author who introduced to the Agile community. Allan shares his insights on why traditional backlogs...
Loading summary
Transcript67 lines
- [00:07]
Host
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 those who've done it. They'll be telling their own stories from the stage. I'll tell you more about this at.
- [00:37]
Vasco
The end of this episode.
- [00:39]
Host
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]
Alan Kelly
Hello, everybody.
- [01:05]
Vasco
Welcome to a very, very special bonus episode on this week of, let's call it teasing, the Global Agile Summit. We're going to explore another interesting topic in the Agile community. There are many pragmatic innovators out there and Alan Kelly is one of them. Alan, welcome to the show.
- [01:24]
Alan Kelly
Well, thanks. Thanks for having me. Glad to be here.
- [01:30]
Vasco
I guess I shocked him a little bit there, let his back. Are you okay, Alan?
- [01:35]
Alan Kelly
Fine. I'm fine.
- [01:38]
Vasco
So Alan is the author of no Projects and an outspoken Agile practitioner that helped introduce the idea of no backlog, something I've been talking about recently, to the Agile community. His work spans several decades. I mean, you can find stuff from him from the early 2000s, and includes some breakthrough contributions that he shares in his books and conference talks. He's the author of, among others, Project Myopia Continuous Digital A Must Read, the Art of Agile Product Ownership, and ksanban, which is a mixture of XP with Kanban, a book about Team Agile Centric. Sorry about Team Centric. Pardon me, Agile Software Development. So, Alan, we brought you here today to blow our minds, metaphorically speaking, about how we might be looking at software development these days that is perhaps not really so well aligned with Agile, at least as we understand it at the moment. So how do you think the traditional concept of backlogs has hindered agile practices in modern software organizations?
- [02:50]
Alan Kelly
Yeah, so let's be clear, backlogs have their place. They also differentiate between what Scrum calls the Sprint backlog and the product backlog. The Sprint backlog, the work you think you're going to do in the next few days. No problem whatsoever. You don't need one of them either. But you can run a full Kanban, but if you're just planning out work for liquid kitchen of weeks, no problem. We're talking about those big product backlogs, the things you measure in.
- [03:18]
Vasco
Okay, let's tell people what the monster looks like. So give me a real life example that you've seen out there in the real world. What do these product backlogs look like?
- [03:30]
Alan Kelly
Well, these days, they're all Endura. I'm old enough to remember when they were physical cards and you could pick them up in your hand. You never had a runaway backlog when you had to pick pick them up and carry them about. But, you know, in Jira, no one can hear you scream. You've got a limitless backlog and you can keep on adding things. And so these backlogs, you know, they're not just tens of items, they're not even hundreds of items. In the extreme, they run to a thousand or more items.
- [03:59]
Vasco
5000. Just heard one today.
- [04:02]
Alan Kelly
Oh, God, so painful. You and in there. Yeah, there's a load of duplicates, there's a load of rubbish. I found stories in there that say, as a product manager, I want the product to ship in two weeks so that I can make my customers happy. They just become dumping grounds of good intentions. They're like children's Christmas list. The children write out everything they want for Christmas and throw into the backlog and they stop communication. Because as an overworked product manager, product owner, someone comes to a new idea and rather than taking the time to say, I really like your idea, but it doesn't really fit with our product strategy, or if I'm being honest with you, that won't get prioritized in the near future. You say, oh, thank you very much, I'll put it in a backlog. What you're actually thinking is, sucker, this stuff goes in the backlog, it goes there to die. Once upon a time, backlogs were useful because they helped us transition from that old world of big requirements documents.
- [05:09]
Vasco
Also with thousands of items, by the way.
- [05:11]
Alan Kelly
Also with thousands of items. Exactly. But, you know, backlogs are like children's comfort blankets, cuddly toys. They were there to help us make the transition, but the same as your kids. My kids, they give up those comfort objects when they get more confident and they know mum and dad are coming back. We've hung on to backlogs, and now teams are measured by their progress since the backlog, and they spend time prioritizing them and refining them. And all this management overhead with backlogs.
- [05:42]
Vasco
So I heard the real life story. It was just today I was interviewing someone for the podcast and they have a backlog with 5,000 items. They complete around 10 items per sprint every two weeks. They have two week sprints, but every sprint they also get 300 new items. So they are minus 290 items after every sprint. There's no way this information can be ever treated coherently.
- [06:10]
Alan Kelly
So I first saw this a few years ago. I was working with an airline and every Sprint they did about 100 points of work. That's cool, isn't it? 100 points of backlog done. And I measured this. They were doing like 7.5% of the backlog per sprint, but actually they had more work coming in. And I measured it, they had 8% more work coming in. Most people know their velocity, but you also need to know the arrival rate. And when you're like this airline, it's like having a mortgage where your monthly payments don't even pay off the interest you're accruing. You're what we call underwater. You're never going to pay the mortgage off.
- [06:51]
Vasco
Okay, so we've ranted enough about product backlogs and both Alan and I are of course old school agile practitioners, meaning we started in early 2000s. Alan, when did you start, by the way? What was the year?
- [07:05]
Alan Kelly
Well, I always say I started in 97 when I put a whiteboard above my desk with a friend and we guys working, we divided it up and we said the next release occurs, I think it was every three weeks then. And we're just going to flex what's in it. I'd read a book called Dynamics of Software development by Jim McCarthy and it changed my life. It was another two years before I read Extreme Programming Explained and I was like, oh my God, we are not alone. There's other people doing this crazy stuff.
- [07:39]
Vasco
Absolutely. Okay, so as we've established, Alan is a little bit older than I when it comes to practicing agile methods. But anyway, we're quite old to this now. We both, and I guess I'm speaking also for you in this, Alan. We both would agree that backlogs were a great idea in the late 90s, early 2000s. In that particular context, backlogs brought a lot of solutions right today, as we've established. Oh, and by the way, I just talked to another person on Thursday last week, so five days ago, and they said the average age of an item in their backlog, the average age was two plus years. This basically tells you that there are people who put Items into the backlog that no longer work at the company. That's a very simple conclusion to get to. Okay, but backlogs were a good thing, right? But now not so much, especially in the way that they are used, as you called it, a dumping ground for good ideas. Of course, you can never find the good ideas because there's too many bad ideas around. So we need to look for alternatives and as pragmatic innovators, we should ask ourselves, okay, so, but what do we do in practice? So what alternatives to backlogs do you suggest to the companies and teams that you work with these days that helps them focus more on, you know, having an impact, making a difference rather than just delivering more stories?
- [09:07]
Alan Kelly
Yeah, so you want to get away from the micro features, the micro bits of backlogs. You want to look big, you want to think about the outcome. What is it you're actually trying to bring about? How are you actually trying to change the world when you finish doing your next delivery increment episode, whatever it is, how will the world be different? Think about the outcome. And outcomes are always nested inside other outcomes. It's like those dolls are nested inside one another. There's always a big, you're always going for bigger, bigger, bigger outcome. And the trick is to find some outcomes that you can focus on in the coming time. You know, next, if maybe next two weeks with a sprint goal, maybe the next quarter with a quarterly goal or maybe something bigger like your product goal or your five year plan. What is a bigger outcome? And you work with that. You get away from this, lots of small things to do. You work in the small, your team divided up into small, you produce small, you deliver small. But when you're deciding about what you're going to do, you need something bigger to think of. And so I think most of us can agree on, it's the outcome, it's the next step you're looking for. I've taken. I know this is a bit of a red flag to you, Vasco. I've taken a bit to the OKR format and I like. Okay, to my mind, OKRs are test first management. Tell me what you're going to do, the, the objective, the outcome. And then the key results are your success criteria, they are your tests. And yeah, and I want them to come from the teams going upwards. But we can talk about strategy, how you set them another time. But just think of it, you're saying, this is what we're going to do and this is how you can measure us. This is Our success criteria, and you reset them every few weeks, months, whatever your cycle length is. So that's how I do it. Look at the outcomes and maybe objectives.
- [11:11]
Vasco
Okay, so I like the idea of test first management. I would never use okrs though, and you know that, of course, you already mentioned it. So I would use something else. So first I would start from a vision. A product must have a vision. If it's not a product, it's a service. Service must have a vision. Once the vision is clear, you work with impact map to map out the main strategies you could use to get to that vision and the necessary business outcomes. Because no business outcomes, no vision, no future.
- [11:39]
Guest Expert
Right.
- [11:40]
Vasco
So you need to be looking for a business outcome. So you use impact mapping for that and then you use a story map to hold the big picture of the product together. This is not a set of requirements. This is just what the product is so that you can overlay on it the change you have in mind before you do it. Now, this is typically done very interactively on a big wall or on a digital tool like mural. And that is done to create then the two to three weeks of backlog items. Now this could be one sprint. I could go as far as two and a half sprints, not more. Two and a half sprints is fine, but longer than that, the backlog loses its meaning because it does not create focus. It doesn't help you to clearly rank, prioritize the work that needs to be done because there's too many things there. And of course it becomes a dumping ground of bad ideas that shadow the good dumping ground of bad ideas that shadow the good ideas that might be hidden somewhere there in the, what do you call it? In the haystack is I can't use.
- [12:49]
Alan Kelly
A needle in the haystack.
- [12:50]
Vasco
Yeah, because the needle is the good idea.
- [12:52]
Guest Expert
Right.
- [12:52]
Vasco
But there's so much there. All right, but I really like this test first management. So I would add to this one caveat, and that caveat is every single backlog item is an experiment written as an experiment that basically gives you the test first management so that we talk about what something will give us before we detail what that something is.
- [13:16]
Guest Expert
Right.
- [13:16]
Vasco
Like, so we want to create this, let's say, onboarding flow so that we get 5% less drop off in the credit card entering step. Right, that would be something test first. Now how do we get there? I mean, we could change the whole flow. We could integrate with Apple Pay or Google Pay, whatever. Like we don't care. Like there's something there. That will give us this 5% improvement in drop off rate. So that, that way I can bring in test first management with a vision coherent in the long term, with an understanding of the product as a homogeneous experience for the client, the customer, rather than a hodgepodge of many things kind of glued together. And I don't need okrs.
- [14:04]
Alan Kelly
Well, you know, the team I'm working with at the moment, we have some OKRs. But exactly as you said, each one of those objectives is stated as an assumption or to be tested. The assumption is we want to validate this assumption and then there's these key results, how we, what we're looking to test on that assumption so they're not a million miles apart. I mean we're talking about the same idea. We're saying, you know, think a bit bigger, you know, in your product, your vision. Do you remember I said these are like goals are nested inside goals. It's like, you know, dolls. And your product vision is a bit fair that if you've not got that, if you're not going, yes, certainly work on it. I also know sometimes people can't think of a product vision until you can actually show them something. And then there's. I hate to say this, but there's an awful lot of cynicism in our industry and an awful lot of customers who don't really believe us. And it's only when you show that you can deliver stuff, that you can actually do something useful, that you will really get a conversation with them about what they want and what their real priorities are. Until you can show that you're not like everybody else, you can deliver. They're like kids with a Christmas list.
- [15:20]
Vasco
Yeah. And of course we'll get back to the project aspect later talking about delivery, but let's keep on this backlogs item because one of the original idea of backlogs, and it was a good idea at the time for that, was to provide some structure but allow for flexibility, right? You had this product backlog which was stack ranked in Scrum or you had this incoming queue in Kanban that was size limited and always prioritized with clear cycle time and lead times. And that gave you the structure that then allowed you to be flexible, right? So you had a time of focus. So in Kanban it would be you start one feature, you end one feature, you don't start 25 features, right? Always keep the working process limited. In Scrum you have one sprint backlog and you work on that until the end of the sprint and then you work on something else.
- [16:20]
Guest Expert
Right.
- [16:20]
Vasco
So you have that time of focus. So it gave us enough structure to provide for us to be flexible. Because at the end of the sprint in Scrum or once one feature was delivered in Kanban, you could change the priorities. You could now rearrange based on feedback and adapt. So the teams that you work with, how are they if they are not using backlogs or how do you suggest teams work if they are not using backlogs to balance the need for structure and also visibility, transparency towards their managers with the true need for agility, the flexibility.
- [16:56]
Alan Kelly
So one of the things that hinders agility with backlogs is that it's no longer someone sits down, writes a story and gives it to a coda. No, no, you have to write your story, you have to marinate it in JIRA for several weeks. You then refine it and you marinate it for a bit longer. Sometimes you forget it's in a marinade and it goes off before you get to do it. Actually, a lot of teams now have this pre tail of work that's be done to a story before you can get and that hinders your agility. So what I do, the teams I work with is we have our goals, our objectives, the outcomes we are trying to bring about and we go into a planning meeting and we review where we are, we tick the ones we've ticked, we talk about the ones we're struggling with. Somebody having started, we decide the product person leads off on where the priority is, where the focus for this sprint's going to be. And this is the point we set the sprint goal. Most teams set a sprint goal as an afterthought. And the sprint goal isn't much more than do all the stuff we said we were going to do. And it freaked me out this until the other week I noticed that tool I keep mentioning doesn't ask for when you create the sprint, it asks for you for the goal. When you open the sprint, Jira asks for your sprint goal at the last possible moment. The sprint goal should be at the start. So we review the objectives we're chasing, we will gris sprint goal around it and then that drives all our work. That drives what we do. We say to the team, what do you need to do to do this? What are the tasks, what are the stories? And we flush, we have a conversation. It's collaboration, it's shared responsibility. It's that old talking to each other. In fact, tomorrow I'm going into London and we're going to meet up to do some of this, we still do it physically. You get a good conversation, but you harness the team's problem solving capacity. Now, the challenge for the likes of me and the other, the subject matter experts and the bas is we have to be a bit ahead of the team. We have to be able to anticipate what they might ask. Or we just have to know our domain so that when the team ask a question, either in the planning meeting or shortly after, we're on top of it and we've got the answer. But we do that by staying with it. And that way the team can just flex and follow where today's priorities are.
- [19:36]
Vasco
I really like the idea of starting from the goal. It's something that I have been talking about and writing about for a long time, the importance of having a goal. I even have this blog where I say that you need one team and one goal, right? Like one single goal for one team. And the team needs to know, you know, who's on the team. Unlike project management, we'll get there. Where people are shared between multiple teams. But I really like this idea of starting with a goal because it provides the option for us to pivot in how to reach that goal. And when I think about structure and flexibility, this ability to delegate the direction, the details to the right level, right. The people who actually need the decision should be the ones making the decision. So you bring the authority to the point of action, the point of taking ownership and goals allow us to do that. Right, because we can explain the goal. We can say, here's how we measure the goal. If we do the test first, management we were just talking about a moment ago, and we allow the team to adapt. And as you said, if we have nested goals, we can do this at any level. You can start with the strategic goal. At company level, you allow the organization to cascade their own approach to that goal. OKRs in their original format were supposed to do this. They don't do now, but we can talk about that later. And this also brings me to the next big question, which is the difference between working from a goal that provides structure but allows flexibility versus working on this infinite number of items that is in an ever growing entity called the backlog, right? Which in my opinion, and I would be interested to hear your thoughts, it pushes us back to this idea from project management, which is that the work is already defined. The only obstacle is you are not able to code fast enough.
- [21:36]
Alan Kelly
Yes, yes. There's this idea that the work to do is a fixed quantity, a fixed fixed entity, and in the extreme, somebody else, somebody else who works for a different company and charges a much higher fee can actually write this out for you in advance and tell you what it is you want. And actually that's not the case for a number of reasons. Partly, as customers see what we're building, as people work on the thing we are creating, their image of what they want changes. Partly, there are multiple solutions to any one problem. And the solution you come up with is going to depend on the boundaries you have. If you are told you have lots of time and lots of money, you'll come up with a rather long last, long, big solution. If you don't have the time, if you don't have the money, you'll do it quickly. So listeners, take yourself back to that day in March 2020 when somebody in your company said, the day after tomorrow you're working from home. Your company suddenly had to enable the entire workforce to work from home. There was no project plan, there was no scheme of doing this. You just had to make it up as you went along. And for a lot of that Covid period, we were faced with new situations and we were inventing it. How much of that innovation would have occurred if a year beforehand your management has said to you, in a year's time, we're all going to work from home, we're going to have the. Can you imagine the meetings you'll be in? But faced with a deadline, and I have nothing against deadlines, I think deadlines are a great way of enhancing your creativity face with a deadline and certain restrictions, you came up with solutions. Less than perfect solutions, more time, more money, you can have a perfect solution. But that's not the world we live in. So that's what engineers do. Engineers create solutions within constraints. If you tell them what the goal is, they might think in a different way, because there's different ways to solve a problem. If you prepare, if you helpfully prepare too much for them, then you're not using their ability, you're not using their skills, you are making the decisions they should be making and you're guiding them in one way. And it also means your engineers will switch off. They will expect you to give them all the details and they won't like to challenge you because you probably don't like being told your ideas are rubbish. So if you want to unlock creativity, if you want to unlock their skills, you give them more chance to do just that. Solve problems, tell them the constraints, tell them the goals, and say, engineer.
- [24:25]
Vasco
Okay, so I'm an engineer and I know that I'm going to be asked tomorrow, I'm going to go to my manager and I'm going to say, hey, we should try to work without backlogs. The question my manager will ask is, right, but if we don't have a backlog, how do I know you're doing the right things and how do I know that you're progressing fast enough? By the way, those are project management questions for which there are very strict and one would say reasonably well tested mechanisms to ensure. Now, they don't work in practice, but they're well tested.
- [24:58]
Guest Expert
Right.
- [24:59]
Vasco
They put you to work on the wrong things, but they are sure you're working on the wrong things, except they think they're right. But, you know, we'll get to that.
- [25:06]
Alan Kelly
Have you ever met a team where people say they're going too fast? Have you ever met a team where the management don't say, I wish they could be faster. Every team everywhere could be faster.
- [25:16]
Vasco
So let's go through that, because one of the objections to this idea of working without backlogs is exactly that I don't know how fast my teams are working. So how do we answer that question? How do we keep the teams accountable and how do we keep a pulse on whether the teams are progressing if we don't have backlogs?
- [25:35]
Alan Kelly
Well, tell me if you've heard this one before, but the primary measure of progress is working software. Let's just see what they're producing. Are the team able to demo something? Is the thing. Is it just me to demo is an accomplishment in its own right that you, you have created something to show? Yeah. Are they able to show they're taking steps forward? Are they able to get feedback from other people on the thing they are creating? Like, let's measure what they're actually delivering. And if you've got goals of some description, if you can talk about how you are progressing towards them, because the conversation you're always coming back to is, what do I need to advance further on this goal? And that's what you want to be saying, is not, have we done 10 stories, have we done 20 stories? Or whatever, but are we closer to our goal? Have we uncovered anything that perhaps invalidates our goal and says we should do something different? Have we discovered something which makes the goal change? Or have we moved ourselves and our capability of meeting that goal a bit further forward? It's as simple as that.
- [26:53]
Vasco
That would require that we somehow have to structure and kind of institutionalize this idea of having goals and having ways to measure those Because I mean, if we work from a backlog, we don't need any goals. We can only, we can measure just the number of stories completed per sprint.
- [27:11]
Guest Expert
Right.
- [27:11]
Vasco
Much simpler.
- [27:16]
Alan Kelly
Yeah. It's measuring the number of stories per sprint, but nobody can quite agree on what is the right size for a story or what is a big story and what's a small story. You know, and particularly if you're doing story points, you can see this with stories as well. There's a little thing called inflation and we've all heard about inflation, we all know what it does to the money in our pocket. But the same thing happens with story points and stories, you know, because it's a bit of a movable feast. And if, if people want you to deliver more stories, there's a very easy way to do that.
- [27:54]
Vasco
Make more stories smaller.
- [27:56]
Alan Kelly
Exactly, yeah. And people lose the idea that stories contain business value. The stories become so small your business partners can't recognize any difference, which is ideal if you want to show progress without doing anything. So we undervalue ourselves. So we need to measure what we're actually delivering. What are the benefits, what's the progress? If we reduce it to numbers, we're going to introduce inflation and gaming. Now, one way I do do it, and again, this goes back to my test. First management. We can look at the objective and if we've got those tests, we can see over time that we're ticking off the tests. If I was to show you the mural at the moment with my team's objectives and tests on it, you'd see a bunch of them have ticks by them and some of those objectives have actually turned to done. So you can see over time that some objectives are being met, some hypotheses are being tested and some of the tests we're applying have been satisfied. So you can still measure progress.
- [29:08]
Vasco
Absolutely. And this also highlights that although the backlog might have the right work to do in it, quote unquote, the fact is that it doesn't really matter what work we do. What matters is the impact that that work has. And by measuring progress towards an impact, we are allowing that structure and visibility and transparency while also promoting adaptability in decision making at the team level. And I think that's one of the core aspects that Agile brought with it.
- [29:41]
Alan Kelly
Yes, we're harnessing all the brain power in the team. We're using all of their knowledge, all of their skills, all of it. And you know what, when people are involved in making these decisions, when part people are a part of the problem, solving and when they're involved with setting the outcomes you want to chase, they're more engaged. If they're more engaged, they're more committed. If they're more committed, they work harder and they do stuff and you can make more progress by engaging people.
- [30:13]
Vasco
Absolutely. A great conversation. Thank you very much Alan, for all of you listening out there. This is what we talk about at the Global Agile Summit.
- [30:22]
Host
I don't know if Alan will be.
- [30:23]
Vasco
There, he hasn't told me yet.
- [30:25]
Host
But there will be a lot more.
- [30:27]
Vasco
Pragmatic innovators discussing this and many other topics based on real life experiences. So I'll see you all there. Alan, before we go, what would be one recommended reading podcast YouTube video that you have for someone who's interested in what it means to work without backlogs?
- [30:50]
Alan Kelly
Wander over to YouTube and or go via my website Alan Kelly.net but go to YouTube and find Honey, I shrunk the backlog that there's slides on my website, there's YouTube recordings of it up online and that's where I talk more about why the backlog was a good idea until it wasn't and how you might want to work in more this objective orientated fashion.
- [31:15]
Vasco
Absolutely. And do follow Alan. He's the prototypical no backlogs hipster because he was there before anyone else was. So if people want to follow you Alan, where should they go?
- [31:29]
Alan Kelly
You know what? I'm really sure to have a lot of social media this year. LinkedIn's the best place to find me. Just Alan Kelly, you'll guess which one I am on LinkedIn and just connect to me there or follow me there. Most of my stuff gets posted up there. Just a bit slow at the moment.
- [31:46]
Vasco
No worries, we'll put the link in the show notes to make sure you all can Find Alan on LinkedIn as well as his website. Alan, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.
- [31:59]
Alan Kelly
Thank you for having me.
- [32:03]
Host
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 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.
- [32:24]
Vasco
We get discouraged.
- [32:26]
Host
Especially when conversations revolve 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 Tallin, 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 an unconventional look at product growth with his Lizard Optimization keynote. Other speakers include, for example 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 the contract negotiation? How agile is that? But there's more. We'll cover engineering practices in our 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 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.
- [35:37]
Vasco
That's Agile Business for those working with.
- [35:39]
Host
Businesses and organizations, Agile Product for product managers, product owners and innovators, and 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. 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.