Latest / einfach gelöst / #20: David J. Anderson – The Agile movement is finally over
Transcript
- Stefan Roock (it-agile): Hello and welcome to the IT Agile podcast, Einfach gelöst in German. What the German title means, solved in a simple way or a more subtle meaning could be being relaxed. and I'm very happy to have David Anderson here, the founder of Kanban, for knowledge work, and many other cool ideas, hello David. David Anderson: Hi, nice to see you again. Stefan Roock (it-agile): So I guess most people already know you or have heard of you. David Anderson: Maybe. Stefan Roock (it-agile): But if there is some listener who hasn't heard of you, may you introduce yourself for one or two minutes? David Anderson: Yeah, sure. So I'm David Anderson. I'm from Scotland originally. I live in Bilbao, Spain nowadays. I lived in the United States for 20 years. And before that, I lived in Singapore for a short while, a couple of years. And it was during that time in the late 1990s, that's how I ended up in this agile community. I joined a project as the user experience architect at a bank in Singapore. And we had there a consultant helping us with the software architecture analysis and design called Peter Kode. Peter had written, at the time, five books on object-oriented analysis and design, which were very popular in a lot of universities, a lot of software engineering training. So software engineers who came through university in that time period in the 1990s were very familiar with his work. He'd worked with Ed Yordan, who was quite famous in software engineering. And Ed had his own publishing company, the Yordan Press. Pete had written books together with Ed Yordan and on its own. And Peter was one of the people are originally invited to the Snowbird event in February 2001, where they created the Agile Manifesto. Pete didn't go himself, he didn't accept the invitation. What he did is he delegated it to one of his staff, and that guy was John Kern. So John was at the meeting. They're really... in my opinion, representing Pete because Pete was the guy who got invited. John has a different version of those events, but he wasn't invited. Pete was invited. And Peter had been working on his own methodology for software development, software engineering. And it was one of this collection of things in the 1990s that emerged as lightweight methods and together with the project director at the bank in Singapore, an Australian guy called Jeff DeLuca, what evolved out of the synthesis of their two sets of ideas was something called feature driven development. So I was there at the beginning of feature driven development and therefore when the Agile Manifesto was created, I was one of these sort of second degree of freedom people away from the original creators of it. And at the time I already had a blog. I was publishing things mostly on user interface design and front end development. And in 2002, Peter invited me to write a book and I have it somewhere in the back here. This book, right? Which it says the code series here, Peter's series. So I wrote this book on managing software engineering, lot of large scale projects in an agile way. And that got me into this space really from the very early years. And I was involved before it was called Agile. Stefan Roock (it-agile): Mm-hmm. David Anderson: And the Kanban concept, that didn't come along until a little bit later. 2004 or 2005. I had been developing the ideas from this book on flow and reporting the results at different conferences. I was at a conference in Chicago, and there was another well-known speaker at that conference, Donald Reinitsen, who had written a book that heavily influenced this one called Managing the Design Factory, which I had purchased in 1997 in the bookstore in Singapore. So I had that from the point where it was first published. My publisher had sent a copy of the Agile Management book to Don, and he was impressed with it. Anyway, we started attending similar conferences together as speakers. And there was one of these events, I guess, towards the... the end of 2004, And afterwards, by coincidence, Don followed me to Seattle. I think he had a client that he was visiting there. So he came over to the Microsoft campus and we had a coffee together, breakfast. And he said, look, all this stuff you've been doing is fantastic. All this flow and managing the work in progress. But it might be easier if you just simply limited the work in progress with a Kanban system. So why Stefan Roock (it-agile): Mm-hmm. David Anderson: don't you try that? And I got the opportunity to try it with a manager from Microsoft's IT department who had a department that just, it was struggling. They weren't delivering. And a lot of broken promises, very low trust in the department. And I gave him some advice. coached him a little bit. And he implemented the Kanban system. And we published those results. Also, it really helped his career. He won an award at Microsoft for process improvement. And his big boss, the general manager, moved to Avanade to become their global CIO. And he brought him with him. made him the head of IT services for Avanade globally. So it was having a big impact on people and I started presenting at the conferences. So the Kanban thing grew out of the evolution of this, which grew out of my relationship with Peter Cote that dated back to 1997 and his lightweight methods. So I stumbled into this. Stefan Roock (it-agile): Okay, thank you very much. David Anderson: That's how we got here. Stefan Roock (it-agile): there was an origin with the agile movement in a way, before the agile manifesto it was lightweight, I remember that. And afterwards you became often a critic about the agileists, right? David Anderson: Yeah, I think that's fair. As early as 2002, I was asking questions on public forums like, is this just a club? Is it all about being a member of a club and behaving in a certain way? Or are you actually trying to make a difference in the world and deliver results? Because I already saw the movement being quite cultish and people driving for conformity of behavior. And anyone with differences of opinion or a view that maybe you could get to the goal of business agility or faster moving, more responsive businesses in some different way, that was shunned and pushed out. And in fact, for three years, and this probably dates back even to the very beginning, when the Agile Conference was kicking off, I was contacted by Jim Highsmith, who's one of the originators of the manifesto. And he said, you know, together with Alastair Coburn, we're organizing this agile conference. And we've been speaking with Jeff DeLuca. And we want to do a track on feature driven development. We want to have Jeff as a keynote speaker. And we'd like you to be one of the track speakers. And I said, yeah, that's great. happy to be part of it. At time I was working as a manager at Motorola. some time went by and then Jim contacted me again. said, we've dropped feature driven development from the program. Our market research tells us nobody's interested in it. And we've axed Jeff DeLuca from the program and the The track is gone and your speaking slot is gone. And it turned out that for the next three years, every submission that I made to the agile conference was rejected. That the people in control didn't want differences of opinion. They only wanted to talk about Scrum or extreme programming by and large. And if you had something else that might be viewed as a rival and therefore a threat to the popularity of Scrum and extreme programming, you were not invited to the party. So the first time that I ever got to speak at the Agile conference was because by that time I was a Microsoft employee and they basically paid for my speaking slot as part of the sponsorship of the event. Stefan Roock (it-agile): Mm-hmm. David Anderson: My view from the beginning was that it was in part, it was a club and you had to behave in a certain way or you weren't invited. And it wasn't a forum to discuss different ways of developing software. It was really just a mechanism for pushing one particular way of doing it. while I was at Microsoft, there were quite a few like top agile people there, but most particularly Ward Cunningham, who's famous for the wiki development work and being involved in extreme programming right at the beginning. And Ward had an apartment in Kirkland, Washington, quite close to Microsoft's campus. And I used to go over there and have tea with him in his apartment some evenings. So I got from him firsthand. quite a lot of information, the back channel information, that the whole movement was basically started with the agenda of promoting extreme programming. But the Scrum guys were somehow smart enough to kind of slide into that and do the end run around them with the launch of the Certified Scrum Master Program in the Scrum Alliance in 2004. that caught on really well for some reason, at least in the United States. At first, not so much in Europe, and I think that Europeans were not as cultish about Agile. But to give you an example, one day at a meeting in Motorola, I'd come into a meeting room. It's a bunch of middle managers, titles like director. junior executive level guys, including our finance guy from our business unit. And he and I were there a little early for the meeting and we were just chatting. And I was explaining that I was getting to know all of the development team that now reported up to me about 30 people. And to do that, I was taking them for sort of one-on-one cup of coffee or some opportunity for us to have a discussion. And... I just finished a session with one of our sharp developers, good guy to be honest. And during the interview, he knew some of my background. And he said, you know, when it comes to methodologies and software development, I am an extreme programmer. So what he declared was an identity. He didn't declare, I'm a software engineer who uses extreme programming and develops my tests first. Extreme programming wasn't a tool for him to get his job done, it was an identity. Well, I just simply repeated the conversation to this finance director and he looked at me and he said, David, are you telling me that we need to rehabilitate this guy? Now, he didn't know anything about Agile. He didn't know anything about extreme programming. But just relaying the conversation shocked him enough to think, wow, we've got this guy who thinks he's an extreme programmer. Stefan Roock (it-agile): You David Anderson: It's like a mental health condition. He needs Stefan Roock (it-agile): You David Anderson: to be rehabilitated. So it was, I think, very difficult. And it wasn't until 2007 when I still couldn't get on the program at the Agile conference, but they had created quite an innovative open space environment where they had a projector, they had a projector screen, they had some different, if you like, stations inside the open space area. And you could book the projector for half an hour or something. So one day I did that and I presented what we now call the Kanban method. There was about 25 people who came to that session, mainly by word of mouth, some people I knew already, I suppose. And three of them were from Yahoo, Carl Scotland from the UK, and Joe Arnold, and Aaron Sanders, my goodness. so long ago, but I remember all the names. Well, the next day, they sort of button-holed me in the corridor somewhere and they said, hey, we were at your session yesterday and we're all from Yahoo. We're agile coaches at Yahoo. And they told me who their boss was, a woman I also know. And their agenda was that they were supposed to be introducing Scrum across the whole of Yahoo. But... they were all working with departments and product units that were stubbornly refusing for whatever reason, right? Just there was resistance. And they said, you know, but you've got this sort of very different way of thinking about it. So we'd like to try it. We'd like to try this Kanban thing at Yahoo with the groups that don't want to adopt Scrum. And we realized that we're going to need some help and support, so we should create some sort of community forum where we can share our experiences. So they set up a Yahoo group called Kanban Dev. And a couple of years later, we had 250 people on that group. And that was enough for us to get the momentum to hold the first Kanban conference in Miami in 2009. which originally started as a joke between me and Josh Kerievsky, who's one of the better known extreme programming guys, where we had said, know, we should all, maybe someone from the UK like Chris Matts had suggested, it's time for a face-to-face meeting, we should get together. And Josh and I had teased the group by saying, let's do Kanban and Cancun. And after I researched a bit, realized first of all, it's a long way from Europe. And secondly, it just wasn't going to be that practical to do the conference there. But I noticed on the map that if you're trying to get to Cancun from Europe, you had to stop in Miami. Stefan Roock (it-agile): Mm-hmm. David Anderson: So it turned out we had some community members from Miami and they helped us to find a venue. And we did the first conference in the spring of 2009. We got between 50 and 60 people together. And that's how the Kanban movement got going. Stefan Roock (it-agile): Nice insights. Would you concern Kanban an agile thing David Anderson: it help with agility? But is it a software development methodology? Well, clearly it's not. It doesn't meet the criteria for that in the same way that the opposite way that extreme programming would or feature-driven development would. And it's also not a prescribed. sort of way of doing things. It's a, let's study the way you currently work and map it into a Kanban environment and create feedback loops so that it can gradually improve. So in that sense, it's more like a meta level thing. So that higher level, it's about creating agility in your ability to change, which, and therefore what you're doing is having an agile way of changing. and you're changing towards a more agile way of working. And the agile community, particularly the Scrum community, found it way too threatening. So I feel like I and the Kanban movement were not invited or were not Welcome. So by 2009, that was the last time I went to the Agile conference. And it's the first year that we started the Kanban conference. And I felt like we had to have some social isolation in order to protect what we were doing with Kanban and allow it to grow, to nurture it and grow it without it constantly being dragged down or marginalized. in this very cultish agile community that really only wanted conformity. And by that point, extreme programming kind of died out. sort of evolved into this blander thing called test-driven development, which it had to, because as I point out to people, it's called extreme skiing for a reason. It's not called middle of the road skiing. Right. And if you're going to scale extreme skiing so that everyone can do it, it won't be extreme anymore. Right. You'll have to have prepared piece. You'll have to have safety equipment and ski patrol people, first aid help and so on and so on. And extreme, if you're going to take extreme programming and scale it, it ends up becoming test driven development. It's middle of the road development. So I think that was somewhat inevitable. So the cultish part of the movement really remained the Scrum community. And I feel that the leaders of that community liked it that way, right? That they encouraged it, where the opposite had really happened with extreme programming to Kent Beck's credit when he did the second edition of the extreme programming book. And I was one of the reviewers of the manuscript for that, the publisher. Back in those days, publishers used to contact peer review people and have the manuscripts peer reviewed. So I was one of the reviewers on that second edition of the book. And I think Kent had realized that there was a certain cult-like behavior in the extreme programming community. The first time I met some of them was in 2000. So before Agile, right? In 2000, there was a conference in York, in England. And there was a panel session with some software engineering guys. I didn't really know any of them particularly, but one of them introduced himself as a follower of St. Kent of Beck. Like he was like some sort of religious figure that they worshiped and followed. And I remember being, quite shocked by that. So there was an element of cultish behavior inside the extreme programming community. And I feel that when Kent recognized that, he took specific steps to dismantle it, to discourage it. And the consequence was that when his second edition book came out, there was an element of the community that didn't want to follow it. The second edition had more roles. And so it's more corporate. There weren't just two types of people in the world. You were either a programmer or you were a customer. And by the second edition, there were things like business analysts. There were other roles in there. It was more corporate friendly. So there were people who just didn't want to follow. It was like the New Testament. And they're like, no, we'll just stick with the Old Testament. So it bifurcated the community. But by the time the Camban community was building, we're doing our own conferences. I don't regret that at all. I think that if I hadn't taken the steps to do that and encourage it, and it was very expensive to do it, right? It cost a lot of money, a lot of time, a lot of labor from people who were mostly on my payroll in order to keep that. going independently. But if we hadn't done it, it would just be a footnote in the history of Agile. Stefan Roock (it-agile): what were the main modifications to Kanban from the beginning until now, David Anderson: At one level, it hasn't really changed much. When I wrote the Kanban book, 2009, I was writing it. So I had to ask myself, okay, I to codify all the stuff we've been doing. Some of it needs to be given names. Write it down, teach it to other people, need to codify it. And that codification, by and large, has not changed in the last whatever it is, 16, 17 years. But there are things that have been added. The most notable one is the maturity model. And that really came about from the fact that there was such a variety of different Kanban implementations appearing all over the world. And this is something that I think people overlook, that if you have a very prescriptive methodology, then the aspiration is to copy it as faithfully as possible. So it drives this conformance behavior. But with this meta-level set of rules that basically said, look, you map what you're doing. You can have all sorts of flexibility. And we'd recognize that each of the different practices, like visualize and limit web and manage the flow, they were done at different levels of intensity. So that being referred to as depth of Kanban, and it had created all of this diversity by giving people permission to do their own thing, to be innovative. We got all this diversity. And after a number of years of that and a lot of evidence, it's worth asking the question, why? Why do we see certain practices present in one environment versus another? And we had enough case studies, experience reports from conferences, videos from almost all of our conferences. So we collected a lot of evidence from around the world. I think one year there were 15 Kanban conferences in the same year, different parts of the world. So we had collected lots of evidence and it was enough to be able to comprehend the business context and the behaviour as well as see the Camban practices that were being adopted. What emerged out of that was patterns that enabled the majority model and therefore when someone would say, we're doing Kanban, but we're not achieving certain business results that were seen in another example, another case study, we were able to start providing guidance, insight into, well, it wasn't just that they got these results by doing these practices. They had these other elements in place that you don't have. So I think the maturity model is a big one. And the other one happened a little earlier was the emergence of the fit for purpose framework, which all started with sort of two very basic things. People in training classes usually, or sometimes at clients, they'd stick their hand up and say, excuse me, but how would you know in advance whether a change is likely to produce an improvement? Which is a super simple question, but it's incredibly profound. Then there was this other trend where I noticed that senior executives in companies were switching off if we used any Japanese words or if we used the term or expression continuous improvement. And I quickly came to realize that they viewed that as some sort of nirvana, some sort of seventh heaven. and they knew that they were managing an environment that was in some level of chaos and that they could never get to this seventh heaven. That there was this structural problem. So they're like, okay, we've got some consultant, some book author here, and he's a dreamer. This is not pragmatic or actionable. It's just some dream that's not achievable. But if we started to talk about how would you improve your workflow or the work you're doing, the services you're providing, to the point where they're fit for purpose, and could we ask the customer what their expectations actually are in terms of service delivery, and then try to close that gap, that suddenly sounded very pragmatic and very actionable. And the idea that if we make an improvement in one part of an enterprise and bring it up to a level where the customers are satisfied, and then you stop and you turn your attention to somewhere else, and you're not constantly dreaming about continuous improvement and Kaizen culture or whatever. around, I think in 2012, I stripped the words continuous improvement and Kaizen out of all of our materials. and replaced it with Fitness for Purpose. Now, a couple of years later, my friend Alexei Zheglov, he's a Russian Canadian from Toronto, he said, you know, we should try to put some definition around this. It was actually another couple of years later before we really got to do that and we wrote the Fit for Purpose book, the first edition of it. But... the codification of what do we really mean by fit for purpose and how do you define fitness criteria or how do you listen to what a customer tells you and codify that as a set of fitness criteria. So that really puts some framework around the idea of a feedback loop that helps you improve because now you've got some target to measure against some set of fitness criteria which represents customer satisfaction or meeting customer expectations. And it's not just about going faster necessarily. That might not be a fitness criteria. Quality could be a fitness criteria. Usability could be a fitness criteria, and so on and so on. So the addition of fitness for purpose and the addition of the maturity model, are the two big things. and think that they greatly enhance the scope and the scale of what we're able to do. Stefan Roock (it-agile): Okay, great. I always ask the question, which forgotten agile methodology deserves a second chance? Is it FDD? David Anderson: There's something that's been on my mind a little bit recently. So I imagine most of your viewers will never have heard of Steve Miller. And Steve is one of the authors of the Agile Manifesto. He was actually at the meeting in Snowberg. And a few old guys from the software engineering world will remember that there was an object-oriented methodology called the Scher-Meller methodology, and Sally Scher and Steve Miller. And Steve Miller's company actually made a product that delivered executable UML, executable unified modeling language. So you didn't write any code. You drew pictures in UML and you added constraints and different things, different layers of the model. And then you press the Execute button and the program would run. And that was Steve Miller's view of how you became agile. Now, in the 1990s, there was similar but different movement around fourth generation languages and the whole idea that you didn't need a developer to write something that could run, as long as had someone who could think in a structured way, maybe a business analyst. And then more recently, we've had the no code type of movement. And even more recently, the AI thing. where if only we had people who could write really precise requirements in natural language, English or whichever one you want to choose, and the AI will generate you the code and it will all run. So that's the first part. Second part is that I've been developing, sort of pivoting our business and developing our own a platform called Kanban Plus. the head of the development group is a guy called Eduardo Bobson, who's been in the Kanban community since 2008. Eduardo's based in Brazil. And he's an old school software engineer like me. So we communicate a lot of the requirements using UML models that we explore the domain space. with the UML model and we express the requirements in a way that we've already modeled. And we've been talking about the idea that you could take those models and have AI understand them and generate the code Stefan Roock (it-agile): Mm-hmm. David Anderson: in a way that would give you very robust sort of industrial scale executable code rather than crappy buggy bullshit that AI tends to. tends to produce a nice prototype, but you can't run it in production. bringing the code method back, but having some AI in it, because Pete Code, he also had a company that made a product called Together. And the idea with Together was that you designed the models. it generated the code, but it kept them in sync. They were constantly in sync. If you edited the code, the model changed. If you edited the model, the code changed. It wasn't round trip engineering. It wasn't design the model, a button that generates code, modify the code, press a button. No, it was simultaneous. They were just different views of the same thing at different levels of granularity. And therefore, if you were able to do that, and add AI into the picture, why wouldn't you revise feature-driven development, which was basically the project management method that was layered on top of p-code's modeling approach? So it has been on my mind a little bit. like many things that I've done, going back to the original feature-driven development project in Singapore and Jeff DeLuca's guidance. One of his guiding rules was that when we select advice and guidance, it should be pragmatic and actionable and evidence-based. And that became the core value for my company, particularly our direct training, the School of Management training business, that anything we teach has to be pragmatic and actionable because what's the point otherwise? but it also has to be evidence-based. And I learned a lesson with this. The publisher liked the outline, but then they gave me a whole list of, here are the other things we want you to add to the book so that we can broaden its appeal. And they do this with all new authors, all first-time authors. The publisher pushes them beyond the limit and makes them write stuff. So there is parts of this book, particularly towards the back, which are thought experiments. And I'd Stefan Roock (it-agile): Mm-hmm. David Anderson: say that those thought experiments are about 50 % successful. Stefan Roock (it-agile): Mm-hmm. David Anderson: So Americans would say, I'm batting 500 on the thought experiments. But if you take evidence-based stuff and you write it down, you're close to batting 1,000. So the... If we were going to, if you like, revive feature-driven development with an AI flavor to it, it would be that I've built that inside my own software development team, that we use it to build our product, and then I might write it down and share it with other people in the same way that we did with Kanban, right? The same way that we said, this is what we did at Microsoft, and it made a big difference since other people had... Yeah, I've got a department a bit similar to that. Maybe I'll try what you tried. So you're not going to see me publish guidance that came out of my head and basically use the public as my experimental laboratory. If we revive some sort of Peter Kode feature-driven development flavor of doing something in this new modern era, of AI enhanced software development, it will be something that we've done internally first, Stefan Roock (it-agile): Mm-hmm. David Anderson: something that we know is working, something that's giving us an advantage. But right now, what I can tell you is we do use AI in the product development, but the biggest advantage we have are just really good software engineers, most of whom are old guys. The head of our flow boards development started doing assembly language on an Apple II in 1979. Stefan Roock (it-agile): Mm-hmm. David Anderson: And we get faster performance out of a human being with that kind of background than you would get from trying to boost something with AI. The concept of 10x or 20x developers is out there. There are features that we add to our product where literally I describe it on on like a daily meeting verbally. And I find that when I wake up in the following morning, it's deployed to production. Stefan Roock (it-agile): Mm-hmm. David Anderson: Because it's like, yeah, I know how to do that. We can just subclass this other thing, add a little bit there, and bang, it just appears. Because the thing's really well engineered to start with. Where what I see with stuff that we've developed with AI, and I hear this also from clients, that they don't know how the code works. Stefan Roock (it-agile): Mm-hmm. David Anderson: So debugging becomes really difficult or modifying something, something moves from one person to another, nobody actually knows how it works. Where with more traditional software engineering, as long as you've got people sufficiently skilled in what they're doing, you know how the code works. Stefan Roock (it-agile): Mm-hmm. David Anderson: And they, yeah, so I think feature driven development is interesting. And there are things that we dreamed about doing with the together product back in the early 2000s, which would be quite easy now, I think, with AI. One of the problems with together was that gradually the model got very messy. as the code got a lot of implementation detail in it. It started to make the model messy. And it was very difficult to hide it and keep the model clean so that you could actually understand what was going on. And AI would be able to cope with that very simply. Stefan Roock (it-agile): Okay, cool. So, is there anything new or cool you're working on currently? David Anderson: Well, the big thing is the Kanban Plus platform and specifically our flow boards and flow metrics applications. no one has ever built the tool that delivered on my vision or a tool that really properly implements the Kanban method or enterprise services planning or how to do it at scale. And we've got that product now. It's not got every feature I want in it. We'll get there. But the features are arriving very quickly. And it's very exciting. We show it to people. And they realize that it's game changing. So to roughly describe what we've done, imagine you took Miro and Jira and you cross-bred them together. So you get this beautiful graphical, collaborative social environment. like Miroez, but you've got all the fundamental database work item tracking capabilities that you would find in Jira, and you cross-breed them together, that's our Kanban Plus platform. So a lot of our energy is going into that, but also integrating it deeply with our training materials. I want... students to be using the tool in the training and walking away with functioning Kanban boards or whatever else they might be learning in the training. Instead of a PowerPoint slide with a drawing of a Kanban board or a photograph of one from 20 years ago, instead in the class they get to play with a real board, they get to feel it. And they can do that socially, collaboratively as a group because it has this like user interface where you see everyone else's mouse pointer on the screen. And let's move this over here. No, I don't think it should go there. You can drag it back. So that's what we're doing, that we're building this tool enhanced training experience. And I really do believe that existing work tracking tools, they're That market can be disrupted. We were talking with one of the vendors, one that we're closer to, and they were talking about a particular client in the United States, healthcare company. And they said, you know, they've got a 4,000 user license for our software. And so I asked them about the pricing, what they were paying, and so features that we're implementing. And it turned out that they had a 4,000 user license for the 15 user team level. product. So get your head around that. They're not doing anything at scale. They are just running independent teams on the same piece of software. And then they basically negotiated a bulk purchase discount for that. So we've seen that time and again, particularly with Jira users and adopters, some on Azure DevOps also, it's all team level stuff. These organizations are failing to scale and connect the dots and to be able to move rapidly at scale. So there's a huge opportunity to disrupt the market by making it much easier to achieve these scale things. Stefan Roock (it-agile): Mm-hmm. David Anderson: And to get very large organizations all collaborating together in the same virtual spaces. So it's exciting. For me, it's been like going back to a much earlier point in my career. So I'm not programming, but I'm doing a lot of the modeling and the architecture, and I'm dealing with software engineers on a daily basis and having to communicate with them. And it's fun. I'm enjoying coming to the office again. after it's been a tough couple of years, right? Difficult economy, difficult geopolitics, and the agile movement so finally is over. I'm somewhat surprised that it lasted as long as it did. I think partly the economics in the world meant that companies really weren't holding people accountable. And in the last couple of years, we've seen a huge shift. No longer do we see agile coaches and scrum masters suddenly the job titles like flow manager or delivery manager. The roles where there's some accountability, there's some objective you're supposed to achieve. And that you'll be held accountable for it. You'll be measured against whether you delivered. That money isn't cheap any longer. And companies are paying a lot more attention. So, and of course, with a difficult economy that has hit the training business, right? I think all of us, not just in the agile space, but anyone who does training has seen that the business has been under pressure, particularly in the agile space. So, it's a, we, Cambine Plus platform is a new direction and it's really fun. It's tiring, but it's really fun. Stefan Roock (it-agile): Is it available David Anderson: yeah, it can ban dot plus. bit of a delay with things like the auto provisioning. But by the time this discussion goes live, that will all be working. Because I think Stefan Roock (it-agile): Mm-hmm. David Anderson: we go live with it tomorrow. So that's the 26th of February for everyone else. So yes, it is available. Stefan Roock (it-agile): Okay, cool. thank you very much for your time and your insights. It was a pleasure for me. David Anderson: It's great to see you. It's been a while since the last conference. We need to figure out how to reboot those. Just the challenge is knowing what it should be called, right? What will get people to come? But yeah, I miss all you guys in Hamburg, so it's lovely to talk with you. And thank you very much for the invitation. I appreciate it.