Latest / einfach gelöst / #13: JeffDe Luca - Agile, FDD and Color Modelling
Transcript
- Stefan Roock (it-agile): Hello and welcome to the IT Agile podcast Einfach gelöst translates to solved a simple way or a more subtle meaning could be being relaxed. And I'm happy to have Jeff Deluca here today. Hello Jeff. Jeff De Luca: Hello? Hello? Stefan Roock (it-agile): May you introduce yourself Jeff De Luca: Oh, well. OK. Well, my name's Jeff DeLurca. I am currently happily retired. I've been retired since September 2018. And let's see. Well, before that, I guess, in the context of Agile, I'm most well known for being the founder or creator of Feature-Driven Development, FDD. But I have a long IT career doing many, other things. mainly around, you know, software delivery and projects, et cetera. But for the last several years of my career, before I retired, I actually went into like the C-suite at large, a very large corporate multinational. And I actually enjoyed that quite a lot and learned a bit out of that as well, meaning that not just focusing on the change aspect, which is what projects are about, but what they call the BAU or business as usual aspect as well of running an IT organization. Stefan Roock (it-agile): Mm-hmm. So ⁓ let's go a bit deeper into FDD, since that was the topic that led to our first encounter more than 10 years ago, where you were at IT Agile to teach us actually FDD. Yeah, what is the foundation of FDD when was it? Created Jeff De Luca: Okay, well, let's see, I'm to stretch my memory here on dates. FD &E got badged and came to prominence out of a large project in Singapore for United Overseas Bank. I guess I'd say, for me, FD was just the way I ran projects for most of my time. But on that project, I came together, I brought in Peter Code to lead the modeling activity for us. And Peter brought to the table the idea of fine-grained features. I'm not sure what the source of that was, actually. It may have been with Peter, it may have probably come from somewhere else. He brought to the table the idea of fine-grained features and, well, then, know, colour modelling was also actually invented on that project, which we could sidestep to if necessary. ⁓ But that was actually, that was entirely a peter code thing. But it was birthed in Singapore on that project at that time. And I guess afterwards, Peter felt that the the the cutler modeling in particular was really significant and he wanted to write about that. So he started working on a book himself and Eric Le Fabre. And and then he wanted to bring me in on that because he also wanted to describe FDD, which was what he saw as a hall. He's the process for, you know, for better delivery and being agile and more responsive and et cetera. And so that's. It was kind of after the fact how it got birthed. Another thread with this was during that time, that project was one of the largest Java projects in the world. And so we would be visited by Sun Micro and JavaSoft from time to time. And there was one of those visits. It was from John Gage, who was the chief scientist at Sun Micro. And I went to lunch with him, myself and the CIO. We were talking with John and I think Alan Baratts, the CEO of JavaSoft was there. John was telling us about the things he was into and some of the other roles he played outside of just working for Sun Micros, such as helping with APEC, the Asia Pacific Economic Forum, and so forth, representing the US, and helping with think tanks and that sort of thing. And so he was talking about these different ⁓ approaches he would use for how they would run such sessions. And so I started talking about, well, yeah, what we do is we brought all our users in, we've got these colored post-it notes and we stick them up on bits of flip chart paper and present and merge and collaborate like that and to flesh out what this thing ought to be. ⁓ And I remember he got really animated about this and he kept challenging me on it. Like I said, well, who's your project anthropologist? you know, who's writing this stuff down? And so it was really that meeting with him and discussion with him that kind of pushed me to then go back to Peter Cote and say, yeah, okay, let's write about this. And so that's kind of how it came to be. But, you know, I sat down with Peter over a weekend and he just turned on a tape recorder and we talked for like, I don't know, 20 hours or something. And out of that emerged an outline of a chapter on FDD which ended up going in that book and the rest is kind of history. Stefan Roock (it-agile): ⁓ When first project, when did that happen roughly? Was it before or after the agile manifesto? Jeff De Luca: yeah, yeah, it's before. Yeah. ⁓ Well, I went over to Singapore, I think in 85, 86. I was working on like a forerunner to this project where ⁓ a different, I don't want to name and shame, so a different big consulting company and IT firm were kind of running the thing. ⁓ I was just like a dev manager, if you like. ⁓ And then that failed rather spectacularly. And then the bank... picked it up and took it over and asked me to run it. So I think that was in mid 1997 And then the actual kickoff, I think the modeling session started around September, October, which is when Peter, I flew Peter in and we brought the business in and when we started doing the color post-it notes and the chart, yeah. Stefan Roock (it-agile): you said project was large. How large was it? Jeff De Luca: ⁓ Well, I mean, how would you answer that question? Like, what's the measure? It was to build a commercial lending system for a major bank. And it was front office, middle office and back office. And it spanned consumer, commercial and corporate and private banking. So roughly about one third of an entire bank. that's possibly the best way to describe like the scope of the thing. I mean, know, project team and headcount and whatever, you know, that all depends or whatever, but the direct IT project team was around about 50 people. Stefan Roock (it-agile): I guess most the listeners don't know ⁓ FDD color modeling. So ⁓ let's to get a ⁓ bit more details about that. How would you describe FDD Jeff De Luca: Yeah, okay. Let's see. as I said, FTD was really came out of the way I ran projects and my business was I had my own consulting, if you like, boutique consulting company, but we ran projects, did delivery and took on the risk. So I would bid for software development projects at commercial and corporate companies, fixed price. So I'm carrying the risk. So that's the context and... Stefan Roock (it-agile): you Jeff De Luca: Obviously what you need when you're doing that kind of work then is, you you need some way to establish upfront, well, how big do we think this thing's actually going to be? What's it going to take? How can I lay out a plan that's going to be accurate? And then that I can track with accuracy and report meaningfully back to the client. So that's kind of the, I get the context or the shape, if you like, of where it comes from. FDD is five processes. The first three processes are what we would call the startup phase of a project. The next two processes are what we would typically call like the construction phase of a project. So the first three processes begin with one called the develop an overall model. And that's the activity where we bring in the business people together with the chief programmers from the IT side. And we collaboratively do flesh out what the real requirements are, what subset of the problem domain are we trying to tackle in this particular project here. That was done using color modeling, which we'll come back to separately. That was using color modeling. So we have four color post-it notes. Each of these colors represents a particular archetype. ⁓ in the model. And basically we break into teams, three groups of three is a good set of numbers. ⁓ You say one business person, two IT in each team. And they would, you know, do question and answer amongst themselves and they would then build up a model, a class diagram, right, in response to that. Each of the teams then when we're done and these iterations don't run very long. So these sessions would run, I don't know, maybe 15, 20 minutes or something. And then each team would come back and present one by one and the group will ask questions. And sometimes you'll go back for a second round or whatever, or, if not, but when we're done, then we would take those three models and merge them together into one. Using the best understanding across the three based on the Q and A and then feedback and critiquing that's gone on. And that would then become, you know, that's the shape for this little part of this little section of the domain that we just described. There's kind of a lot to that actually. The thing about, you know, the written word is, which is why, you know, the big stack of requirements documents is, you know, is folly, is the written word is actually very vague. You know, and I think Kerry Weinberg gave a great example a long time ago of that Mary had a little lamb, you know. Mary had a little lamb, Mary had a little lamb, Mary had a little lamb, Mary had a little lamb. It's like, okay, which one of the five meanings is it? You know, it's such a simple sentence. So the thing about models is they're very visually explicit. They're very expressive and like something's related to it or something else or it's not. Yeah, it has a cardinality of zero or one or one to many or many or a dozen and... Stefan Roock (it-agile): Thank you. Jeff De Luca: Those cardinalities in particular, they're very explicit, they're very expressive and a lot of discussion happens around those things. Well, is that really zero to many of this relationship or is it one to many? Does the customer have to have an address or is it optional or, you know what I mean? And so you get a lot of really high quality discussion and conversation going on because these diagrams are so visually explicit. ⁓ When that activity is done, that knowledge is taken and the IT folks go away and then they'll build what we call the features list. And the features list is simple functional decomposition of the domain. So it's categorized. We call the top level categories, we call them subject areas. So it might be the customer or the origination of a loan or approving a loan or calculating risk. And then within each of the... subject areas, have the next level of decomposition we call business activities. And then for each business activity, there's basically one of the steps that you need to take to get that done. And those steps are written out as features. Features are very fine grained. They should take no more than two weeks to fully complete, which means, you know, design, build, test, promote to build. ⁓ But they often are much shorter than that. So two weeks is like the limit, but they're often much shorter than that. And then the third upfront activity, which was called Develop an Overall Plan, basically lays out the development, ⁓ the construction phase oriented around which features are going to get done when and since features belong to business activities and subject areas, we can develop nice visual representations of that. ⁓ that work being tracked and reported through the construction phase. That works really well for business because that entire diagram, subject areas, business activities, the steps that are needed, the client-valued features, that's entirely expressed in the language of the problem domain, in the language of the business. And so as we're moving through construction, the businesses see in their own language what's actually being done, what are they working on right now, what's finished, what's not. Etc. So that's kind of the startup phase. That startup phase is typically one week's worth of activity for every three months of construction time. So if you thought this was going to be a six month construction effort, you'd spend two weeks doing this entire effort. So it's not a very heavy upfront process, but it's a very important one. And then we fall into instruction where we basically design and build by feature one by one. ⁓ I say one by one, you know, they would get batched into things we call work packages and then that work package will get pushed through design and build. And then basically you iterate on that or increment as FDV would like to say, ⁓ until you're done. That's kind of the gist of it. Stefan Roock (it-agile): Mm-hmm. Mm-hmm. Jeff De Luca: And well that's a question I haven't been asking a long time. Stefan Roock (it-agile): Okay, good. And do I remember correctly that ⁓ when the features are built, FDD doesn't use long-term stable teams, but creates the teams for every two week cycle? Was that correct? Jeff De Luca: on terms of table claims. okay, now I understand what you're saying. Yeah, so in the project model, and we can talk later on about, well, okay, so what changed after that? yeah, one of the things I did was I took the project structure out, because where I got to was, I believe, more in the product model and the product model. But let's talk about classic FTD, if you like. So in the project model, yeah, you're going to have a group of developers of what we would call problem domain developers. We have system interface developers, we have user interface developers. And by the nature of whichever features we decide are going to get designed and built now in this particular work package, right? ⁓ I've left out one piece. We also have the concept of class owners, right? So the whole thing's object oriented. We've been coming off these class diagrams. So each class has an owner, a person. And therefore, the selection of the features in a work package dictates which group of developers are going to be involved in designing and building that work package. And those teams, yeah, are forming and reforming all the time based on whichever features are selected to go through design and build. So yeah, that part's dynamic. The people that are, if you like, assigned to the project are not, right? You want them for the life of the project. Stefan Roock (it-agile): ⁓ Funny side note here, when I learned FTD, this kind of teamwork felt strange for me. Since I was in this, ⁓ we need to have stable teams at Dogma. roughly perhaps 20 years after your 1997 thing, we in a way rediscovered this idea. And now we call these concepts fluid teams. That for certain contexts, it may be more efficient to have unstable teams. And so that on Jeff De Luca: Okay. Stefan Roock (it-agile): It may be more efficient since with the unstable or fluid teams we may be ⁓ better able to align with the business needs. So in a way I think that, I guess that was one of the ideas in FTD also with the team building. Jeff De Luca: It's a complex topic and I think that to fully answer what you just raised, I'd need to talk about non-project or product versus project, which is possibly a topic best left for a little later. But ⁓ the notion of the CP teams or the feature teams forming and reforming in FDD really came around from the fact that it's, if they had a belief that class ownership was a better model, and because you get better consistency, you think about OO, right? You want, you know, encapsulation and consistency of interface, and you'll get better consistency of implementation and interface with the same person working on the same component, right? Which is how all, at the time, know, large-scale software development was done inside like IBM labs and et cetera. ⁓ which is where I picked up on that concept back in the 80s as we now know. So for example, when I was working on System 36 at the time for IBM in one of its US labs, DollarMaint was one of the big components in the operating system, was the librarian. If you wanted to talk to DollarMaint, that was Marguerite Diamond. If I wanted to know more than what was in the published spec, I'd go talk to Marguerite Diamond, Marguerite is DollarMaint and yeah. So that sort of thing. that's where the thread or nugget of that kind of concept came from. But it also gave us then this ability to have groups of people come together, but under the tutelage of chief programmers. So chief programmers are the 10 to 50x people. They were the people that were involved up front doing the modeling with the business. They were the people that decomposed into the features, provided input to make the plan. And then they're the leads through the design and build. So we want to mentor and transfer skill and transfer knowledge as quickly as possible. But I don't want to do it as inefficiently as say pair programming where the overheads, you know, one to one. In FDD, the CP to P ratio is more like one to four to five. So it's just, I don't know, to me it just felt natural, but it was more, it was a more efficient way to deal with those kinds of concerns. ⁓ I think Being more business aligned is an interesting discussion. I think product versus project is a better way to address that. But to come back to FTD, FTD, as I says, expresses everything in terms of the problem domain, in terms of the business. So the business are the ones that they describe their problem. We turn that into a model. We turn that into client-valued features. And then we design and build by client-valued feature. So we don't have features that are like, you know, install the database or configure indexes or everything's done in underneath some sort of client failure feature, a fine-grained one. So that's the business focus aspect of FTD and which, you know, I found it always made it really well received to me when you showed what was called that parking lot diagram, which is one of the ways you could visually show the progress of the project. That thing was very, very successful. It would resonate with business strongly. Yeah, right after the C-suite. Stefan Roock (it-agile): let's go a bit into color modeling. Jeff De Luca: Right, colour modelling. Colour modelling was just a refinement of codes, like approach to modelling. He already had in his head when he came to us in September, October, 97, I mean, he already had this idea of there were four major class categories, if you like, that he tended to see again and again, and they had certain characteristics. ⁓ And on that day, there happened to be a bunch of post-it notes, colored post-it notes on the conference table, four colors. You had four class categories you wanted to share with us as a way to think about this. And on the spur of the moment, four class categories, four colors, you associated the two and off it kind of went from there. And it was later on that we realized that there was something really profound going on here, something deeper. ⁓ people were much more productive using that approach. People that were less, if you let's say, experienced at ⁓ modeling or whatever, were able to get into it more easily. And so after the fact, he went back to look into, well, what's going on here? What's it about? And started to write about it. So it was really the idea that there were these four major class categories or types of the classes that you see again and again. And he colored them. So there's a green, which is a party, place or thing. There's only one of those and has some sort of unique identity. know, a person might have a tax number or a social security number or whatever. You know, a company has some sort of business number. Pinks, moments or intervals of time. They happen in a moment in time or over a period of time. They tend to represent things that are important and need to be tracked. You could think of that as perhaps a transaction or something like that. You have a yellow, which is a role being played or a way of participating in something. And just as people can wear different hats or play multiple roles. And then a blue is a description. It's like a category of something that describes a category of something that happens again and again. And for each of these archetypes, then they suggest Here's the typical attributes you'd expect to see for one of these. Here's the typical methods you'd expect to see for one of these. More or less, you won't always see all these attributes, you won't always see all these methods. But then it was dynamic as well. It was when you see a yellow and a green, they tend to associate in this way and they tend to interact in this way. So they tend to associate ⁓ with a particular relationship and cardinality. And then you tend to see typical interactions from green to yellow or yellow down to pink, know, such as in a yellow, know, methods like assess performance or assess value to business, these types of things. And so that was kind of the secret sauce with it all, which is like once you're stuck down a green, a yellow, a pink and a blue on the sheet, you automatically had a whole lot of content and associations and interactions you're expecting to see. and that would really help you drive the model and then challenge whether, is this the right way to think about what we just heard? That's ⁓ a really short description of it, but I guess I do need to point out, so, FDD got written up as part of Peter's colour modelling book. FDD doesn't prescribe, you that you have to do colour modelling. If you think about that upfront process, Stefan Roock (it-agile): Mm-hmm. Jeff De Luca: Its purpose is there needs to be some sort of informational or analytical activity to get enough knowledge to be able to lay out this client valued features list and then build a plan with high accuracy and have it be meaningful to the business. That's the problem we all have. If you're bidding for fixed price construction work, that's the problem you've got. So it's just... the power modeling and doing it in the small teams and doing the present and merge or whatever is the best approach I ever sort of do that. Like I say, that kind of just happened collaboratively in Singapore at that time. But FTD, you know, doesn't actually prescribe that, okay, that's the way you have to do that. If you can substitute any other informational analytical activity that we can derive the same knowledge, then great, Grin, we're in good shape. Stefan Roock (it-agile): Okay, great. ⁓ I just looked it up. The book I read that ⁓ years ago is called Java Modeling in Color with UML. And I think it's a bit misleading since from my, ⁓ as far as I remember, it doesn't have to do much with Java and not with UML. Jeff De Luca: Well, the syntax is UML or the notation is UML and you've got to go back in time. At the time that was topical, especially to Peter because he had his own notation, code notation, right? And then there was also, ⁓ God, I'm stretching my memory, Yakutson or whatever had his own and... Right. so, know, Brady came along with UML and UML was kind of steamrolling and everything. And, and so it was, it was around about that, that era or just, just before, think where Peter and kind of, you know, recant is not the right word, I guess, but baby's they conceded it's like, okay, we've got to go with UML here. It's the, it's now the 800 pound gorilla. I'm going to dispense with code notation. We'll go with UML. So that's. Stefan Roock (it-agile): Thank Jeff De Luca: That's, I guess, a little bit of the era and context. But yeah, I do agree with you on the title of the book. it's not a, ironically, it's not a great book actually either because, I mean, it was well intentioned, but the book's fairly inaccessible. So what Peter's thinking was at the time was, I forget if remember, there was like the Gang of Four patterns. book had been around, you know, don't know, a few years prior. And while that was good, what people were telling Peter and I was one of them was like, yeah, look, that's great. You you've got the pattern for this, I don't know, this algorithmic thing or this other IT thing. Where's the pattern for order entry? Where's the pattern for doing a general ledger? Where's the pattern for product catalog? And Peter was like, yeah, you're absolutely right. Everywhere I go, this is Peter. This is what I do. I'm showing people how to model those ⁓ repeating business ⁓ patterns or whatever. So that was the motivation for him to do it. So we hooked up with this guy, Eric, who didn't have any object ⁓ expertise, but was like an ERP kind of expert and worked on big ERP systems for many, many years. So Peter tapped on his model knowledge and then built these color models. So here's a model for product catalog and here's a model for order entry and here's a model for and so on and so forth. So it was a great idea and it was a real need and it's still really valuable. And if anyone ever wants to build a product catalog, I highly recommend you when you go, that's the solutions right there. It's archetypal, so you start customizing it to your needs. But to come up the book cold, it's hard. It's like, here's this model. There's a few pages of description. It's like, wow, man. Without having been there for the walkthrough whatever, it's hard to ⁓ absorb. But the book was a best seller. did very well. ⁓ But yeah. Stefan Roock (it-agile): but it's the only source for the color modeling, right? Jeff De Luca: It is the only source for colour modeling. Yeah, that's true. It's stretching my memory a lot here. Now, I assume there's a chapter at the front before it gets into all the models where he outlines colour modeling. I hope you did anyway. mean, that would be the place to go. ⁓ If not, I don't think I ever published ⁓ talks on it. I mean, you would have seen me do one, ⁓ Yeah, I'm not sure if they're, I know Peter did, like he went and spoke at Java one and did a like a, you know, a 30, 40 minutes on color modeling, which was a really good session. You know, I don't know if those things are online anymore or not, but that would be a great, that would be a great way to get an overview of what it is and what it's about. Stefan Roock (it-agile): FDD was invented with this ⁓ fixed price project and you mentioned that there was adaptation for product model Jeff De Luca: Well, I guess you're going forward a lot of years now from 97, but when did this happen? Well, I guess even before the product thing came along, just had the feeling that having to orient around projects wasn't always going to be the best way of structuring things. So I guess let's talk about maybe where I ended up. So now I'm C-Suite at a large telco, a really big telco, right? In one particular country. ⁓ And it's got an international presence in multiple other countries with other operators. And it's also got a big telco in Australia that reported into it. I was looking after all of that in the digital space. ⁓ And so now you're not just running a change organization, you're running a big business as usual organization as well. ⁓ And I really got to learn a lot from that. And so it was there where I kind of crystallized in the, it's time to move away from project structures. ⁓ And product versus project was one way of thinking about that. Now, again, you back to my time in IBM back in the 80s, working in the labs, doing product development for IBM. mean, that's where a lot of that was rooted. However, at this particular time, it was actually, I stumbled across a couple of pages that Martin Fowler had written on this topic. ⁓ And it didn't source with him, it sourced somewhere else. I can't remember that person's name right now. So apologies to whoever that was. But Martin wrote that up, know, and cited this person ⁓ and talked about product versus project as something that ought to be considered. So if you think about ⁓ a typical IT organization in some sort of corporate, you know, the, there's a, let me ramble here a few minutes, because there's kind of several dimensions to this. ⁓ But the structures are, you might have, the permanent structures are, might have a permanent architecture team and a permanent testing team, a permanent group of project managers. mean, God, I hope not, but that's common, right? Yeah, and that sort of thing. ⁓ But then projects are formed to deliver whatever it is the business wants in this particular fiscal year. And the project teams are temporary. They come together, they do their work, they're disbanded, right? It's these other structures that are permanent. ⁓ And that's completely the wrong way to think about it. So what we really want is we want permanent delivery teams that are business oriented. And they stay together for the duration. So the thing that's permanent is the thing that's actually delivering value. ⁓ And the team then would be oriented around business KPIs, not IT KPIs like, you know, on time or on budget or whatever, right? You would rather be oriented around business things. So I'll give you a simple example, but it was one that resonated well. So if you think about, well again, let's stay in that telco space. So you've got... what they call the online sales funnel, which has a conversion rate. So you go to the telco homepage and eventually you'll navigate to, I don't know, mobile phones, you'll navigate to plans, you'll look at models and eventually hopefully for them, that ends up with someone purchasing something. That whole thing is called a sales funnel or whatever and the metric from here to an order, is called the convert, or at each step you call the conversion rate. And so obviously the higher you can get that conversion rate up, the more business you're gonna do. So if you had a team that was oriented around that, so that's their job. So if you imagine, they will come to build run in a second, but a build run team, they sit at the one table on the wall or on the monitors or whatever there is that. that funnel, it's like every step of this chain or whatever. basically all they're doing for the year is how do we refine this? How do we make that better? How do we get the conversion rate up? What would it take to do? Yeah. And that would be their KPI, right? So then that would be a product mode team and it's funded on a rolling basis, ⁓ for a year at a time, just like the business would be, right? You'd have periodic reviews, of course. And then whatever work they happen to do would be classified as capex or op-ex, not the other way around, which is what project structures enforce. So you fund the team and then you would classify the work as capex or op-ex rather than what's done typically is you fund the work and classify the people. So you move from these, ⁓ what I would call outdated schedule and budget IT KPIs and get to more business aligned KPIs. you know, strategic business changes, business outcomes, improving online takeout, know, reducing shopping cart abandonment, improving the conversion rate, these sorts of things. And these teams are persistent. And ideally, what I wanted was you have the business sitting with you as well, right? So it's this joint kind of team. And I called them Build Run Teams. And I think that... That name, I think, came from Amazon. don't know, might need a show note to come back and clarify where I got that from. I'm just off the top of my head, can't recall right now, but I think it was an Amazon concept. But basically, you know, it's a build run team. You build it, and they're running it, supporting it, right, as well. So again, if you think of the traditional structure where we've got this temporary team that comes together, they're project team, they do their bit of work for three months, six months, whatever it is. Stefan Roock (it-agile): Mm-hmm. Jeff De Luca: they disband and it's someone else's problem then what happens to that thing now that it's in production and maintaining it or, you know, supporting it going forward where the build run team is, you build it, you run it, you deploy it, you own it, you love it. Yeah. So that was, that was kind of, you know, where, where I guess I'd evolved to by the, you know, by the time I came to retirement or whatever. so FDD was, you know, had to be Stefan Roock (it-agile): Hahaha. Jeff De Luca: adapted if you like to then come out of what was originally a very project oriented structure to one that I just described that's really not project oriented at all. It's a persistent team that's funded on a rolling basis doing work. Stefan Roock (it-agile): Thank you for the insights. the FDD training I participated in when were in Hamburg was one of the most influential trainings I ever had. I did FDD the book, but... Jeff De Luca: ⁓ Stefan Roock (it-agile): ⁓ I used ⁓ color modeling, I used the idea of creating an overall model for larger things with color modeling or other techniques. used ⁓ format creating the feature list and I ⁓ every time lot diagrams for communicating ⁓ Jeff De Luca: Yeah. Stefan Roock (it-agile): progress. ⁓ Jeff De Luca: thanks for the feedback. ⁓ But that's very much in the spirit of FDD and in the spirit of Agile. You take the bits that are going to work for you ⁓ whatever you're doing at any particular point in time, it's not prescriptive. Yeah. Stefan Roock (it-agile): Yeah, exactly. ⁓ Jeff De Luca: Yeah. Stefan Roock (it-agile): thank you very much for your insights.