← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
BONUS Team Effectiveness With Arne Roock
00:45:08
BONUS: Beyond Individual Talent: 2 Leadership Myths We all Believed in with Arne Roock In this BONUS episode, we delve into the complexities of team effectiveness with Arne Roock, an experienced Agile consultant who has worked with organizations...
Loading summary
Transcript39 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 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. Hello everybody. Welcome to a very special bonus episode. And for today's bonus episode, joining us from Sweden is Arne Rog. Hey Arne, welcome to the show.
- [01:16]
Arne Rog
Hey, happy to be here.
- [01:17]
Host
So you are in Sweden today, right?
- [01:20]
Arne Rog
Exactly. I live in Sweden, but I was born and raised in Germany, as you can probably hear from my accent.
- [01:25]
Host
Yeah, that's why I asked, because I wasn't sure. So Arne works as a consultant for Agile methods and leadership and team effectiveness as a trainer and coach. He supported both startups and big corporations in different industries. And for the past 10 years he took a deep dive into the tech industry as an embedded coach with Jim do and Spotify, for example. And Arne is here to talk about two leadership myths we all believed in at some point. So let's start with the first one. When we were prepping for this recording, Arne, you brought up this leadership myth that if you just take highly talented individuals and you kind of put them together into a quote unquote team, you automatically get a high performing team. Now this is a myth, so we're already kind of spoiling a little bit the storyline. It isn't actually true. It doesn't actually happen like that. So in your career, what was that moment when you realized that just simply putting highly talented individuals together doesn't automatically create a high performing team? What happened at that time and what did you learn?
- [02:44]
Arne Rog
Yeah, so there's some things to unpack here. I would like to start with a quote that Ruth Wegeman uses a lot, and I'm sure I'm going to refer to her work a couple of times during this recording. She often says a team of experts is not an Expert team. And this is exactly the myth we were talking about, right? You have talented people, you put them in the grouped together, then you expect the magic to happen. And very often that does not happen. And because everyone likes a good sports analogy, and there's plenty of examples from the sports world where like a billionaire, for example, bought a basketball team or hockey team and then bought the best individual players in the world and then expected, of course, to win all the championships. But that did not happen very often. These teams ended up being very mediocre. So it's clearly not the case that we have the best individual players and then we combine them to get the best team. There's also a really fascinating story from ice hockey, which I recently read. It was the Russian team called the Russian Five, or the Red Army. So that was a long time ago during the Soviet Union era, and they were basically dominating ice hockey for several decades. They were so good that a lot of the great teams did not believe they could ever beat them. Even their opponents were talking about them like they can read our minds. They have eyes in the back of their head. They move as one. It's magical how they play. And remember, this was during the Cold War, so these were hardcore opponents. Right. But still they were saying these things about the team. And then there was the miracle on ice. Every American knows this, where the US Managed to beat the Russian team. And that was a huge thing how they managed to beat them. But it's still true that the Russian Five were like, they were so much better than every other team on the planet for several decades. Then the Soviet Union broke down and the team did not exist anymore. And then most of the players from this team decided to go to North America, either Canada or the U.S. to play in an NHL team. And of course, the teams were very eager to get them. So they were paying a lot of money, bought them. And what happened, they were not performing well, so they did not boost the team performance. So here we have the reverse. An excellent, excellent team. But the individual players were actually, I mean, they were good, they were very good, but they were not so good that they would beat any other team on the planet. So that's just a long winded way of saying it's not true that we just need to combine a lot of great individuals to get a great team.
- [05:51]
Host
Yeah. So basically what you're saying here is that we already have several examples from history where we see that great individuals, when coming together, don't form great teams. And if you take individuals from a great team and Put them in another team, you don't necessarily get a much better team.
- [06:14]
Arne Rog
Exactly. Yes.
- [06:15]
Host
Now, when it comes to software development, I can think of a few examples, of course, of when that happened with me. But how about you? When you were working with software teams, can you share a story or two about how you saw that happening in those teams?
- [06:31]
Arne Rog
Yes. So what happened to me? Many times in my career as an Agile coach, I was working with managers and they would say something like, hey, Arne, can you help me with this team? And we would have a conversation and they shared that they were not happy with the team because they were delivering slowly in their opinion, or they were fighting all the time or people were slacking off or whatever and they wanted me to fix the team. That never felt great to me. But I thought back then, this is part of my job and who am I to say no to an executive? So I said, okay, sure, I'm going to do it. So I was parachuted into these teams with the mission to help them. Then I used all my skills as an coach, my facilitation skills, my teaching skills and my agile methods skills and worked with these teams. We had workshops about ways of working and retrospectives and sometimes conflict resolution workshops. And very often it seemed to actually work. So on the short term, what we were seeing, that the problem seemed to disappear and the managers were happy, I got a pat on the back. But then when I reflected a little bit and revisited these teams, I realized that this actually did not have a long term positive effect. It was more like a patch or like a painkiller. But it did not address the real issue and sometimes it even made it worse. And that's when I realized something's not right here. So the things that I'm doing are not having the impact I wish they had. And for a long time I couldn't make sense of it. And then I read the book Leading Teams by Richard Hackman, and this is an excellent, excellent book. I would really recommend everyone to read it. And he talks a lot about the conditions that need to be in place for a team to be effective and the design of a team. And I realized that what I was doing was mainly interfering on a behavioral level and not so much affecting these conditions. And now back to your question. I think my assumption as well was these are all talented people. They know what they're doing, they're not malicious. So that's not the issue. The issue is also not a lack of process understanding or process knowledge, because that was my area of expertise and I was teaching them on these great processes. So in theory they all should be high performing teams, but they were not.
- [09:27]
Host
Yeah. And that of course leads me to the question, okay, but what are those conditions? So you talked about leading teams, a classic by Richard Hackman. What are these conditions that you have discovered through reading the book and of course through your own experience that need to be in place for us to have these high performing teams?
- [09:46]
Arne Rog
Yes. So one thing that really resonates with me, but it is counterintuitive and it took me a long time to really wrap my head around, is the so called 60, 30, 10 rule. Based on Hackman's research, he. And then later Ruth Wegemann, who's kind of now continuing his work because unfortunately hackman died probably 20 years ago. The 60, 30, 10 rule says that a leader should spend roughly 60% of their time and effort into designing teams and creating the conditions that a team can flourish. 30% into launching the team and only 10% into coaching interventions. But what happens in reality very often is the reverse. Leaders spend very little time and energy into designing teams. This is all the work that happened before the team even comes together the first time. They spend very little effort into launching teams and they spend a lot of effort into then trying to coach them. So all the things that they did not do, they tried to now repair by coaching interventions. And that is very hard to do. It's like swimming against a very, very strong.
- [11:14]
Host
Basically, what you're saying, if I understand you correctly, is that the way the team is set up at the start creates its own dynamic that over time will reinforce certain things that are very hard to reverse or backtrack through interventions.
- [11:32]
Arne Rog
Yes, exactly. And one metaphor that I like is you design the team like you design a spaceship. And if the design of the spaceship is not right, it will never take off or it will never reach its destination, like the moon or whatever it is. So the design needs to be absolutely flawless. And then you launch the spaceship, you send it on its trajectory, and if it's on the right trajectory, then you can steer it a little bit like the last things, like a little bit to this direction or this direction. That's the 10%. But the 30% is the launch. You're sending it on its trajectory and you cannot change the general trajectory with coaching. And then if we talk about teams again, it's similar. You build the team, you make sure that all the conditions are in place, then you launch the team, and after that it should be on a good trajectory. And then you can get maybe the last 10, 20% of effectiveness by coaching, but not the other way around.
- [12:44]
Host
Okay, but this then brings up another question. Okay, so we started with this myth that, okay, if you put experts in one team, they'll become an expert team. Okay, we already understood that's not the case with the examples that you gave. But then this last statement, that the coaching interventions help with just adjusting direction, but not really changing the. The setup, the conditions that are in place. Then this would suggest that when we think about coaching, we should focus a lot more on helping leaders set up these teams. Or you called it design, but it's a lot more than just design. Right, because it's not just sitting down with a piece of paper and thinking through it. There's a lot more involved. Right, so is that what you're saying? That as we think about setting up and creating new teams, we should actually spend most of the coaching time with the leaders that are creating these teams in the first place?
- [13:43]
Arne Rog
Yes, that is one of the implications. And that also took me a long time to let go of some of my beliefs. And it's also part. It was part of my identity because that was pretty much what I was doing as an agile coach. Right. Coaching teams in the sense that I. I was trying to influence their behaviors and their ways of working. And that is all good and great, but only if the other conditions are in place. So to your point, yes, before a team is launched, we should spend time with the leaders, and leaders very often are managers. But there are different types of leaders. Right? Scrum masters are leaders. Product owners are leaders.
- [14:22]
Host
Project managers are leaders.
- [14:24]
Arne Rog
Yes, they can be leaders. I mean, there's a bunch of people who can influence the conditions for great teams. So that is great. Then also think about the launch of the team. That is really important. And then also what I want to say is what I just described sounds very linear. We first design it, then we launch it, and then we coach it. But in reality, it's actually very iterative. So we do think a lot about the design. We want to get it right. We launch the team, and then we observe the team. And if we see that something's not right, we. We can think about a relaunch or even a redesign of the team. But, yes, that is very different from what I used to do, which was basically trying to coach the team into a trajectory they were not sent on.
- [15:16]
Host
When you talk about relaunching or redesigning a team, I get the sense that what you're referring to is this concept that Katie Helfand who's been on the podcast as well, calls reteaming. Right. So that you're not just one team forever, but that teams change over time, and not just change in terms of where they're focusing on, but composition, setup, rules, working agreements, all of that. Is that what you're referring to, this reteaming concept?
- [15:47]
Arne Rog
Yes and no. So I also read her book. I think there's really interesting ideas in there, and there's an interesting tension between her ideas and Hackman's ideas, because what Heckman found in his research was that team stability is actually very important. And I know it's a controversial topic even in the agile community. And now there's more talk about having more fluid teams, and I see all the advantages. Just in Eggman's research, it was very clear that we need some stability. They don't need to be stable over a decade or whatever, but they need to be stable enough to accomplish meaningful pieces of work. And if we reshuffle them all of the time, again, that, according to the six conditions model, would be a flaw in the design. So I would urge people who are working with teams to think about redesigning the teams, but that does not necessarily mean changing the members of the team. And that should be a last resort.
- [16:51]
Host
Yeah, absolutely. So we're also considering then, what is the impact of relaunching or redesigning a team versus impact on the team itself versus the benefit that we are looking for. Like, for example, one of the things that we've talked about on the podcast is that in some cases, rather, the conflict within a team is so large that resetting so creating a new team, maybe with some of the members and other people from other teams, might be a much better choice, because there's very little hope of kind of relaunching that team in that constellation. Right?
- [17:33]
Arne Rog
Yes, sure. I mean, it's not either or. It's not binary. There are situations where it actually makes sense to change the membership of a team. I would just be. It would not be the first thing I would do. And we have talked about some of the conditions already. Now maybe it's useful for our listeners to mention some of the others as well. Right. So it's called the six Conditions framework, because there are six basic conditions. They are divided into two groups of three, the fundamentals and the enablers. So we're talking about a real team. That means there's interdependence between the team members. It's reasonable, stable over time. We're talking about the compelling purpose. So it's clear what the purpose of the team is, and it's compelling, it's consequential, it's motivating for the people. And then people have the right knowledge and skills they need for the task. And usually that means we have a cross functional team. People know what they're doing and we have complementary skills. So these are the fundamentals. And then we have the enablers. And they're called enablers because we take care of the fundamentals first. And if they are in good shape, we then think about the enablers and that is the task design. So the overall task should be designed in a way that enables or even encourages teamwork. Then there's organizational support, which is, I think, very often overlooked. Does the team have all the support it needs from the organization in terms of information, in terms of training, and in terms of rewards? And the rewards one is a really interesting one because very often we pay lip service to teamwork because we say, yes, we believe in teams and teamwork. We form all these teams as the basic building blocks for our organization. But then people are rewarded on an individual basis. For example, if you look at promotion processes in many companies, you will see that in order to get promoted to senior or staff engineer, you have to show your individual contributions to the code base, which might be undermining to teamwork. Then the last thing just to finish the six conditions is expert coaching. And that could be the manager, it could be a dedicated coach, it could be some other person who acts as a coach or mentor to the team. But this is the last one. So coaching can be impactful if the other five conditions are in place. But we should not start with the coaching, which is again, a little bit offending to someone like me who has coach in their job title.
- [20:42]
Host
Yeah. One of the things that I really appreciate by this model and also our conversation is this idea that we need to be deliberate about setting up teams. That teams are not just a group of people that somehow comes together and the more. The better they are individually, the better the team will be as a whole. And that's not the case. And I'll put also the link to a very old TED Talk video by Margaret Heffernan called the Super Chicken Paradox, where she actually relates some research. Exactly contributing to that understanding that when you put a team of experts together, actually you get a lower performance than if you have average performance together as a team. And the difference in performance of these teams is different. And she talks about chickens as an example. So read, check out the video. It's a very entertaining video as well. But. But Arne, I also wanted to have you on the podcast to talk about another topic which is I think another leadership myth. But we'll get there because I'm not sure you have the same opinion as I do. But this myth is related the the delivery responsibility of Scrum Masters and Agile Coaches. Now we know that especially from our leaders there comes very often a strong emphasis on just do it right, just deliver, hit the deadlines, put more features out. And sometimes this even comes out as assigning Scrum Masters, Agile coaches, project managers as delivery responsibility so they become responsible for the delivery, making them a delivery lead, for example. What are your thoughts on this trend? And let's focus now on Scrum Masters and Agile Coaches. What are your thoughts on this trend of making Agile Coaches and Scrum Masters more of delivery lead?
- [22:38]
Arne Rog
So to make this a little bit bigger, I believe that a lot of things and organizations go in waves or they are oscillating from one pole to another. And you can see this in many different examples. I wrote a blog post about embedding designers and product teams or then removing them from the teams and organizations very often go back from one extreme to the other. And a really great book about this is Polarity Management by Barry Johnson. I really recommend this book. It has nothing to do with software development or agile, but it's a really great book. And he talks about the polls and usually very often we are at one pole and then we start seeing some of the disadvantages of this poll because every poll has pros and cons and we start seeing more and more of the disadvantages. Then we look at the other pole and we hope to get all the advantages of the other poll. So we move to the other extreme until we then start seeing all the disadvantages and we move back back to the first one. Now back to your question about Delivery lead and Agile Coaches and Scrum Masters. I believe that one thing that has happened was Agile was partly formed as a counter movement to the old style ways of working in the 1980s and 90s which was very much process focused and the human factor was not super important. So Agile wanted to change that and amongst a couple of other things and what has happened now in some organizations was that Agile people, agile coaches, grandmasters, have focused very much on the human factors. So it was very important that people thrive, people get along with each other, psychological safety, trust, all these things and these are super important. Don't get me wrong. And now I think what has happened recently was that organizations think that we went over the top with this. We are focusing too much and now they start seeing the disadvantages of this and now they're looking at the other poll which is delivery, delivery, delivery. And there's like, oh, this is great, we should move this and there. And now we're going from one pole to the other again from very human centered product development to a model where it's all about delivery and we're not focusing on the human factor anymore. And I mean, it might be obvious, but we need to find a balance. Both things are important. It's not one or the other. But to me it seems like right now we're seeing a pendulum swing to, to the other side.
- [25:38]
Host
I really like this metaphor of the oscillation between polls because obviously in any, let's call it group like in this case software development organizations, there's not only one dimension, right? Like we are only talking about the delivery versus focus on people dimension, but there's other dimensions also involved. For example, there's the cloud versus on prem dimension. There's the AI versus no AI dimension. There's the we only hire seniors and super experienced people versus we want to have a lot of juniors because that decreases our salary expense dimension. There's all of these dimensions kind of interacting with each other. And there's one which I think is useful in this delivery discussion, which is this project management versus inspect and adapt iterative empirical software delivery dimension. Right? Where in project management we have this poll of wanting to know everything that needs to be done before we fund our work and then executing that plan because the plan is what is funded. That's one dimension. And then we have on the other extreme, the lean agile financial planning. We also have a podcast episode on that where we talk about funding teams and then maximizing the value that those teams deliver by having product management or product ownership working to find out what is the most valuable work. That's also another dimension. Right? And what I fear is happening with this delivery shift. So the shift of putting the delivery responsibility on Scrum Masters and Agile coaches is that this hides the fact that this delivery responsibility is something that has always been shared among the whole organization. I give a concrete example. I was working with a software development organization where the teams were doing Scrum and they were relatively agile. There were things wrong, but you know, they were doing their two week sprints, they were reliable, they were delivering things, but in order to release anything, they needed five, five different sign offs before anything could be delivered to the market. Right. And what this meant was that the teams were actually spending considerable amount of their time managing the, you know, collecting of the sign offs, talking to the stakeholders and all of that instead of focusing on delivering features. So this change, change of focus, I should say from, you know, the teams are responsible and can deliver to. No, no, no, the teams can't do that. We have to have five different organizations to double check that the teams did what they thought they did and with high quality. That shift completely transformed the way that software was developed and of course made it much slower. And I'm afraid that this delivery focus that we are talking about is just saying, oh, the teams can do whatever they want, they don't need to worry about delivery because we have this magical role, Scrum Master, Project Manager, Agile coach, whatever there is, we have this magical role that somehow resolves all of the delivery problems.
- [28:48]
Arne Rog
Yeah, I agree. And I personally believe that delivery is a shared responsibility of the team. What happens if we have a dedicated delivery manager is it very often undermines teamwork because exactly like you say now, people could reject this responsibility and say, no, this person is responsible. I'm just doing the coding, I'm just doing the designing. And that in my world is an anti pattern. The other thing I find interesting is when we look at Scrum Masters, Scrum Master is a full time job and especially since a lot of Scrum Masters I've met are working with two or even more than two teams. So if we now give them also the responsibility of delivery manager, what makes us believe that they have extra capacity for doing this job? Or in other words, what do we expect them to drop? And this is also a conversation people are usually not having.
- [29:54]
Host
Yeah. And when you say what are we expecting them to drop? Then of course there's a bunch of assumptions that can come from there. But this also kind of implicitly means that, okay, but then the delivery becomes their most important priority. Right. Which also means that we already know what they're going to drop. They're going to drop all the work that is done towards helping the team thrive.
- [30:19]
Arne Rog
Yes. There's also a very interesting tension here between the short term and the long term and the tangible versus the intangible. And delivery is usually short term or maybe midterm and it's very tangible. Whereas what you just referring to building great teams and making them thrive, that's long term and that's very intangible. And then back to your point, if a Scrum Master now has both responsibilities, this person will usually prioritize the delivery because it's short term and it is tangible. So it's easier to get rewarded for this as well.
- [30:59]
Host
Yeah. And I think from this conversation the big question that emerges, at least in my mind, is how can we make this shared delivery responsibility or shared delivery ownership effective? Right. Because the reason why the delivery responsibility is being shifted to one role, whether it's project management or Scrum Master or Agile coach, it's because it's thought to be more effective when done that way. Now, we've already talked about some of the consequences of doing it that way. It's perhaps not that effective, but making it effective. Right? Like, you know, either predictable or efficient or well coordinated or high quality, whatever that definition is. Right. Making the delivery effective should still be the goal. So what have you learned from your experience on how we can make the delivery process and the delivery ownership shared but also effective?
- [31:57]
Arne Rog
That's a good one. So the first part of your question, I think we can now go full circle back to the beginning of our conversation and that is the design of the team. Because very often what we see is stakeholders or managers are dissatisfied with the delivery and they want to fix it by having a dedicated delivery manager. Whereas the real problem is that the design of the team is flawed. So then according to this condition framework, we have to work with the managers and the team, maybe do redesign or relaunch of the team. And just to give you one example, which I've seen over and over again, a manager says, I'm not happy with this team and they are not delivering. So we need a delivery manager. At the same time, they are assigning people to multiple teams. And if an engineer is part of three different teams and two working groups and a committee and a council, and they are also expected to work full time, super focused on the delivery, of course that's never going to happen. So that was my comment to the first part of your question. And then the second part, I believe was about moving from just shipping anything, just deliver, deliver, deliver, to actually creating value, impact or outcomes. Right? Yes. And I've been struggling with this a lot because almost every organization I've seen we can call a feature factory. So they try to optimize for delivery and they don't care so much what it actually is that we deliver. And I've had in some cases good success with leveraging two practices that we know from Scrum. The first one is the Sprint goal and the second one is the sprint review. And it's interesting because both of them are undervalued and overlooked very often. So even teams that claim to Work with Scrums in several years have never heard of the Sprint goal. And if they're doing a Sprint review, it's a mere demo. They're not getting the stakeholder feedback. So if we use those two practices, it can have a huge impact and shift us from just delivering stuff, just churning out new functionality, to asking ourselves what is actually the value we want to provide and making sure we are providing this value to our stakeholders. And then we can also apply this on a slightly bigger scale if we move beyond this single Scrum team. One example would be okrs. I know it's a controversial topic and it's maybe a topic for another time to get into the details, but a lot of companies are using OKRs on a quarterly basis. So every three months they're setting new OKRs and then they're coming up with initiatives and they never check if the initiatives actually delivered the value they were hoping for. So if we use the same kind of thinking, what is the goal we want to achieve here? What is the impact that would be the equivalent of the Scrum goal, the Sprint goal. Maybe it's the product goal, maybe it's something similar, but then also in the end have a mechanism that's similar to the Sprint review, that is getting feedback on have we actually achieved what we were looking for? Have we created this value? And I know that if we're talking about a three month cycle, that's a very long cycle, but that's already better than what most companies have. And if we then manage to move this to have one review cycle in the middle every six weeks, that would take us a long way.
- [35:59]
Host
So we're talking about creating shared delivery that is effective, needs to, as you said, go back full circle, think about the design of the team. Because if a delivery manager, quote unquote is needed to fix the team, probably it's not the team that is the problem, but how the team was designed, how it was set up and the conditions there. And then the second thing is using tools or practices like the Sprint goal and Sprint review to help the team focus on learning from their process of delivering. Right, like the goal, meaning that we know actually the value we're delivering so we can organize around that and then with the review to actually collect effective feedback. So feedback that helps us improve for the next cycle. And then you also talked about okrs per, but I imagine that okrs, you mentioned it more in the sense of having the company wide view of what we are trying to achieve rather than the team view of what we are Trying to achieve. Correct.
- [37:02]
Arne Rog
Exactly. And in my view, if we zoom out a little bit and think more about the principles behind the Sprint goal, the Sprint review, we can apply them on different levels of the organizations. And I was using okrs just as one example where we can apply the same thinking on a company level or at least something like a business unit level.
- [37:27]
Host
Yeah, absolutely. And I think that this is relevant in the discussion of an effective delivery process or effective shared delivery ownership because those are company wide considerations. Right. Like in some companies, one team is responsible for the delivery because it's just one team in the company. But in most companies that deliver software out there in the world, it's going to be two or more teams that are impacted by a certain delivery, which then also brings another problem which we haven't touched on today, which is the coordination chaos. Because if you have multiple teams and they all have a different delivery manager, then who's making the delivery work? Right. And you're just abstracting the problem away with the hope of fixing it. But it actually doesn't fix it, it just delegates it to another level which itself needs to eventually delegate the problem to another level and so on. So for me, I think one of the things I take away from this conversation is that delivery in a multi team setup needs to be the ownership of the organization, whether it is engineering or whether it is product product or whether it is team of team style organization. But it needs to be a responsibility of the organization and not single individuals.
- [38:48]
Arne Rog
Yeah, I fully agree with that.
- [38:51]
Host
So Arne, we're getting close to the end. It's been a wonderful and insight filled conversation so far. If people want to know more about you and the work that you're doing, Arne, where could they go?
- [39:06]
Arne Rog
Yes, so I'm on LinkedIn. You will find me Arne Rog, just search for it. And then my professional website is arne rogue.com so ana rogue in one word.com and you can find my profile and some of my work samples. And then also my blog is on there where I post a lot about what we discussed today. Teams, effective teams, leadership and then the intersection between leadership and team effectiveness. Other than that, the only social media I have left is Mastodon because I moved away from Twitter and Facebook and Instagram. But there I only post private stuff. But if you're interested in that, you can find me there as well.
- [39:56]
Host
Absolutely. We'll definitely put the links in the show. Notes for people to go check out Arne's work and why not engage, ask a few, follow up questions. There's so many topics here that we could have explored even further. Arne, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.
- [40:14]
Arne Rog
Yeah, thanks. It was great. Thanks for having me.
- [40:19]
Host
Hey Fran, 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. 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 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, Clean Quinton 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 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. That's Agile Business for those who are working with 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.