← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
BONUS: Consulting is Different—How Consulting Contracts Work Against Agile Development | Jakob Wolman, Wilko Nienhaus
00:42:33
BONUS: Consulting is Different—How Consulting Contracts Work Against Agile Development, With Jakob Wolman and Wilko Nienhaus In this BONUS episode, we explore the critical differences between building software as a consultant versus inside a...
Loading summary
Transcript67 lines
- [00:04]
A
Hey there, Agile adventurer, just a quick question.
- [00:07]
B
What if, for the price of a.
- [00:09]
A
Fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame war free and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's this Scrum Master Toolbox membership. And it's your unfair advantage in the agile world. So if you want to know more, go check out scrummastertoolbox.org membership. That's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now.
- [01:06]
B
But if you're not doing it now.
- [01:08]
A
Let'S listen to the podcast.
- [01:12]
C
Hello everybody.
- [01:13]
B
Welcome to a very special episode. We have two guests today. With us, Jakob Vollman and Vilko Niehaus. Welcome to the show.
- [01:23]
D
Thank you, Jakob.
- [01:25]
B
Jakob, who is the author of an article we will explore today, is an experienced engineering leader who knows how to build great software and and most importantly for today's discussion at least also how to mess it up. And Vilco is the CTO of a consulting company in Tallinn, Estonia and focuses on the challenges of delivering software in a consulting environment. Today we're exploring the differences between building software as a consulting company versus as a product company. These differences are described, or some of these differences at least are described by Jakob in a critical article that he contributed contributed to the Global Agile Summit book. The link is in the show notes, if you want to check it out, which collects articles from presenters and contributions from the community. In that article, Jakob explored how and why consulting and here we mean software development in a consulting environment. So third party software development is a very different process from product development in house. And with Jakob and Vilco joining us, we will explore what ownership, trade offs, teamwork and business pressures are in that environment and how they shape software development. So let's jump straight into it. Jakob, in your article you make a point that consulting is fundamentally different from product development. But most people outside your environment probably don't really see what that means. So give us a concrete example. Let's explore one of those stories from your experience where those differences really hit you in the face.
- [03:07]
C
I think this is a lot about what we call shoemakers children. One of the things that comes to Mind is I was spending some time with the client and I was helping them mainly with the process. It was a non technical client. So we were basically, the idea was that we would help them with the process and then kind of build software to, to help them be more effective. We were spending time with the teams at the client, we were doing value stream mapping, we were digging into how they worked, we were suggesting how they could improve different things. I come back to the office from this workshop and suddenly with these eyes on, looking for improvements in process and I just suddenly am hit by this revelation of why are things so slow here? Why are we working so inefficiently? We should really do something about it. And then realizing that I can invest in helping the client, but it's much harder investing in improving where I am and where I'm sitting. I think that another example of this, and this is something I think is funny, is when you go around different digital agencies and I'm sure you've seen this as well, and you look at their websites and see how much or how little time and effort they've spent on their own websites. They might look fancy, but when you start digging into it and you look at the quality and the technology behind it, you're like, oh my God. Because it's the same thing.
- [04:54]
D
It's the same thing.
- [04:56]
B
It's a case of cobbler shoes, right? Like we help clients as consultants, but in the end we don't do enough of helping ourselves to have a better software development process.
- [05:08]
C
Yes, I really think it's about that.
- [05:10]
B
How about you, Vilco? You've been in the consulting business for a very long time. You probably don't have any recent product development experience in house. Maybe you do, I don't know. But what is your experience? And do you see similar patterns to what Jakob described in your client base as well as in your company?
- [05:36]
D
I think so. I can definitely say the own website is always a bit of a challenge to spend time on because we have those great clients that we spend our time with, so we don't have time for our own things anyway. I think we definitely see the. I would say we see it with clients when in the consulting engagement, that it's very different how they actually ask for what they're looking for. I often have said it's a bit of a procurement mindset. It's here's a list of things I want, tell me why it's done and then they forget about it. It's not entirely true, but they forget about it until eventually it's supposed to be done and then it's just magically supposed to be the right thing, solving all the problems. It's not as black and white, but it feels like that sometimes.
- [06:39]
B
So I hear you describe that one of the key dynamics in consulting or software development in a consulting environment is that the often referred to wall between the stakeholders who want something and the team who develops it is even stronger and more accentuated, more clear in these consulting engagements. And of course, that has a bunch of consequences. But is that what you see, Pilko?
- [07:09]
D
I would say so. I think it probably comes from the fact that we are two separate entities functioning in different ways. And so you don't necessarily understand or see what the other side is doing or needs. So I think that's part of what causes that.
- [07:30]
C
I would go even further and I would say it's two different entities, but it's two different incentives. The incentive models are very different. If you are in a product company, those are usually not always there are different departments that might have turf wars, but there is somewhat aligned. Whereas you have different companies, you have very different incentives where consultants get paid by the hour or some other model, and the company that the customer in this case has a very different incentive model. And I think that quickly becomes a challenge in this environment.
- [08:08]
B
So let's explore that incentive model and make it crystal clear for everyone listening. So, Vilko, give us your version of those two incentive models between the consulting company developing software for a client and then the people in the client who want that software developed.
- [08:25]
D
Well, I can maybe take a fairly blunt stab at this and say on the one side, on the client side, they of course have business objectives they would like to reach, they would like to grow, they would like to achieve more. And maybe then the blunt side, on the consulting side is we just want to be busy. And it almost somebody once said that to me, it's almost as if the clients are actually paying us to be slow because our incentive is to spend more time on achieving what the client wants because we get paid more as we get paid by the hour. And that is a clear. It's not what we internally really want, but it is still fairly easy to see it that way and see the conflict between what we want, between clients and ourselves.
- [09:13]
B
There's an article on the Global Agile Summit book by a consulting company owner and CEO from Germany who tackles exactly that and he places the blame in the contracting process. Right. Like how contracting really emphasizes that kind of incentives that you describe. So check that out in the Global Agile Summit book. But how's your perspective, Jakob? Do you see it the same?
- [09:38]
C
Very much so. And I think it's fixable, but you have to work with it. Like you really have to deliberately change this model, whether it's the contracting or how the collaboration works, but in the kind of standard way. Yes. There are two incentive models that are in direct opposite of each other. And I think this is kind of one of the keys to the problems is that if you have digital tech consultancy that gets paid by the hour and they want to spend more hours, we all want to deliver good work, we want to ship good software, we want to do good things, but we're not incentivized to be more effective. And then the customer, they're going for some kind of business outcome, as Virgo said. But the tech consultancy doesn't really get a benefit from that business outcome. I mean, they want happy customers, they want to make a difference. But if you go down, if you follow the money, they're not necessarily going to get more money because they build a great website. They're going to get more money because they spend more hours on it. So it's, if you don't work with that, it starts becoming a problem. Now this is very cliche. Most consultancies don't work like this and don't want to work like this. But if you really look at the incentive models, I think, I think this is what it comes down to.
- [11:14]
B
So if I go beyond the incentives though, I think that you are, both of you are describing a dynamic that we used to have in in house product development, which is this idea that you have a stakeholder who wants something and writes down the requirements. Typically it is a product manager and they don't really care literally how the software is delivered. They don't care if you're using waterfall, if you're using agile, if you're using ad hoc or cowboy coding, which was and perhaps still is the most often used process out there for delivering software. They just want the software done. But this also drives, and this is something I would like to hear your thoughts on because you have direct experience. But this also drives that stakeholder to think that what they asked is what needs to be delivered. When you wrote that article. Consulting is different, Jakob. What came to my mind is this dynamic of I already know what I want. Why isn't this consultancy delivering it to us while we as software developers, both as consultants and in house, we know that actually knowing what you want is the beginning of knowing what you don't Want, Right. Like in Agile we very often say people will always know what they don't want, but first they need to see it, but they never know what they want. Right? So you always show something, then you get the feedback, oh, this is not exactly what I wanted. Hey, but that's what you wrote. Yeah, but it's not what I wanted. And then especially in consulting you develop this antagonistic perspective which is that as a client now I need to pay you more to fix the problem you created. And I never think because I wrote the wrong spec. Right, but that's the reality. And I think that this drives this idea, especially in consulting, that you can define everything up front and you just deliver it to a team and they will deliver exactly what you need, not what you asked for. Very importantly, because people, when they give you a contract as consultants, what they want is what they need, not what they asked for. And this also drives this antagonistic perspective that hey, don't change the spec. Yeah, but if I don't change the spec, you don't get what you need. Yeah, but if you change the spec then I need to pay you more. Right. So Jakob, your thoughts on this systemic dynamic that tends to develop.
- [13:33]
C
So I see this happening a lot and I think many of the companies that I work with don't have that much competence within how to build software. Like that's not, that's why they come to an agency, that's why they ask somebody else to do this. That means they know what they want or they think they know what they want. They have a spec, they have a budget, etc. But they don't understand the non functional requirements, they don't necessarily understand the technical underlyings, they don't have requirements for it, they don't care. It should just work and have very little opinions around scaling around, caching around providers, around all of these things, security.
- [14:22]
B
Which is a very important thing which will buy to them in the future.
- [14:27]
C
Data processing, all of these things. And that falls down on the consultancy to have to make these decisions and be, and I think this is what good consulting is, be an advisor in how these things work and what different choices there are and the consequences of these choices. So that's the first thing. The second thing is I think within any product company that I come across, if I find a product manager that comes and says we're going to do this because I say so we're going to do this because this is my opinion, that to me is a red flag immediately because if you don't understand what the customer, in this case, what they want, what they need, how to get that business outcome. So if you have somebody with a budget and says, here's a spec, just implement it and we'll get this business outcome already there, we know that's going to be a problem. So we have to find a way to work iteratively to test with users to see is this really causing, are we really making money out of this outcome or not?
- [15:32]
B
Wilke your thoughts on this dynamic?
- [15:37]
D
I think for me it often in consulting I see this, what you described earlier as we come up with a spec and we want this all and so on. And I think one thing that I somehow realized is that as part of the process, client comes to us, they would like to get something. It's usually quite a lot because they actually, I think it's almost like a bad thing. They have a big budget. And because of this budgeting process where you now need to motivate what this budget does, so you need to spend that budget, you essentially create this necessity to define everything. In fact, in the process as such, everybody now wants to basically get everything they can possibly think of into the specific. Because there's only one budgeting process. If they don't get their stuff in this time, they have to wait for the next year to get anything in. So everybody stuffs the thing full. And because everybody knows that this is difficult, we're not going to really get exactly what we want. We now need to fix that by having more discoveries, more meetings, more details, more everything. It just becomes more and more and more, all of which ends up basically costing a lot of time and in the end doesn't really improve the process very much because as you said, they don't really know exactly what they want. They know what they don't want once they see it.
- [17:06]
B
And that's a very important. I'll give over to Jakob who wants to come in, but that's a very important realization that I need to get everything in because otherwise I need to wait a year. Is the exact same dynamic that we see in Waterfall Project. But Jakob, you had something.
- [17:22]
C
That was my point. I think when I see this, my frustration is we've fixed this, We've already fixed this. There are tons and tons of books of articles of experts of we fixed this problem. But it just appears here because there are two different entities and they're not necessarily working together. And so I think there's something about the collaboration, there's something about, I mean it is fixable in a consultancy setting as well. I've seen it, I've been part of it. But to me it's funny that it kind of pops up again and it's exactly the same problem that I was struggling when I started out with agile and waterfall discussions. We fixed this problem.
- [18:09]
B
It's like 1999 all over again. Okay, and there's another aspect. So we've discussed this antagonistic dynamics. We've talked about how there's this pressure to put everything into the spec because there's only one budgeting cycle. But there's also a very practical day to day difference, right. In product companies, engineers often have a sense of ownership and continuity. I mean, if nothing else, because they know they are going to look at the code later again, right? While in consulting, the client owns the vision, the direction, we've talked about that. But also the developers know that once this is done, we're probably never going to come back, or at least not for many years. So why would I care? So Jakob, how do you see that dynamic, right, like from the real engineers working on the product, how is that clear difference between in house product development and developing for a client?
- [19:08]
C
I think most engineers want to be proud of their work. They want high quality, they want to stand for some of these things. I think the problem that I see is it comes from how we educate people. Again, incentivize, I always say, follow the money. How we incentivize people around these things. Skilled engineers will be frustrated if they're not allowed to do a proper job. People that have spent a lot of time in an environment where they're never allowed to do a proper job, or maybe even punished for doing a proper job, they will have given up and not care. So I think many consultancies really want to do something proper, but you have to be very deliberate in your collaboration with the customer. And if you don't succeed well with that, well then it goes south very quickly where you just say, we're in it for the short term, just fix this thing, get it out there. And I think this also comes back to one of your favorite topics, Vasco estimates. Because they come with a spec, you make an upfront promise and of course you have to stick with that promise. But we know as soon as we start coding, things change and we learn as we go. And so you just have to complete this thing because if you don't, the company you work for are going to start losing money.
- [20:44]
B
And that's a very important aspect, right? Like if you think about it from the incentive perspective, in a traditional time and materials contract, the developers are incentivized to use up the whole budget. But in a product development environment in house, where the budget is the same for everybody, right? Like there's no budget for development, you know, budget is for the whole company there you're incentivized to deliver something valuable as quickly as possible and the highest value first because you know that that's the way you get more money from the sales so that you can invest more into product development. Right? So there's this survival imperative, if you will, and some people will say growth imperative. How do you see that in your own experience, Vilko? Do you see the same dynamic? Do you see this difference between the incentives of a third party software development company versus the incentives for the developers in an in house software development effort?
- [21:49]
D
I think quite a lot of things are coming together here because incentives, who controls the budget? Not the budget, the direction and so on. But I think from an engineer point of view, we can see this in our company, quite a nice contrast because we have cases where essentially the team is controlled by the client. The client needs one more person of this specific skill and they'd make these choices, even though in many cases they actually don't really have the experience with this expertise. But anyway, we have that and then we have teams where we actually control the team. And we have this idea where teams should be, generally speaking, stable units. We don't want them to be perfectly static, there is a bit of change and so on, but in general we want them stable units. And you can definitely see in terms of ownership that people express. And I also do believe, maybe it's just my own experience as an engineer, but engineers want to do a great job, but eventually you sort of numb down when it doesn't really matter, right? And we do see the difference between these teams. And there's just one thing you mentioned in product companies, the survival topic. I think sometimes we actually, I almost considered it a downside on the consulting side is that sometimes, especially these initial huge, big projects where everybody wants everything, there's actually very, very little real world feedback as to what a developer did. A developer built something great and they want to do a great job, but are they potentially overdoing it? Are they just following theoretical ideals here? There's no real world feedback until much, much later in the process. So we have all these dynamics that we.
- [23:42]
B
I want to zero in on what you just said, Filko, because this is extremely important for all agile thinkers and practitioners out there. The length of the feedback cycle, meaning the longer the feedback cycle is, the more we are pushed towards a waterfall way of working. The shorter the feedback cycle, the faster we move into a more agile way of working. Right. So I think this is a very important kind of mantra and kind of rule of thumb to keep in mind. Jakob, you wanted to come in?
- [24:17]
C
No, I think that the feedback cycle is very important in terms of how you do the collaboration with the customer. And I think the best consultancy and customer collaborations and kind of successes I've seen have some kind of iterative approach and not only the best ones don't only have this iterative approach with a stakeholder at the customer, but also with the customer's customer where you're able to iteratively bring on. If you're building a new website or an E Commerce or whatever it might.
- [24:55]
D
Be.
- [24:58]
C
You'Re bringing on new customers that can try the new site on the developers, get feedback, what's working, what's not working, did they like it? Where did they click? All of these things that we know from a great agile environment, when you start bringing them in, it actually works. The problem is this is not intuitive. For many people that buy consultancy services, especially not if you're not within tech. This is not an intuitive way of working. Instead, you have a budget and with this budget, I want this new E commerce site. Here's the design of the new E commerce site. Give me that one. Once it's done, I'll launch it.
- [25:41]
D
There's actually a interesting thing you say that seems to be not intuitive. One interesting thing I've picked up over the last 12 years that it seems actually that the higher up you go on the client side, the more intuitive it becomes to them.
- [25:59]
B
Sometimes it's a theory at the moment what becomes intuitive. Vilko, can you describe that?
- [26:05]
D
That's a short, like a feedback cycle where you actually spend some time doing something, then you see what the result is of that, then you go back and you change, you adapt. This seems to be more intuitive to senior leadership. I've had one example with a company this is perhaps a bit unique in our field because they started from nothing to an E commerce setup. Usually they already have something, but in this case what we ended up doing is they wanted a scope that would probably take around two years and we told them, no, no, no, let's break this down into smaller steps. They agreed to us, all makes fine, but that's still something like nine months or something at a piece. So then we said to them, what if we tried to actually go live and we had to clarify a bit what that meant, but go live in a single Sprint, which most companies is two weeks. And they were like, nah, we're not so sure. And he said, don't worry, you're going to get everything you want in your scope by the end. But just let's try these first two weeks, let's see what we get out of it. And of course, when you think like that, now it's in two weeks, you can't do everything. So now you have to start thinking, what can we leave out? And that starts becoming easier for them to sort of process or handle. And in the end, we ended up setting a goal. One customer, an existing customer, placing one order for one product that they already know because they're repeat customer. So we didn't need images, we didn't need lots of attributes of the products, big descriptions. We didn't need a lot of things. And in the end we actually delivered that, yes, it was slightly more than a Sprint, but doesn't matter. It's in that time frame or that, that ballpark. And then it became a discussion with a client, what happens next? And there were senior leaders in the room and somebody said, oh, but now we need the images because whatever. And then it became, no, but our customers know the products, they don't need the images. Let's focus on something else. Some others wanted. Let's expand the catalog to all the hundreds of thousands of products we have, because we actually just put something like 200 of them in just to have some reference. And somebody else realized, actually, no, the quality of the information is so bad, we actually need to work on that instead of the volume. So this became a really reliable discussion. And in the end it actually turned into a very interesting discussion because people were realizing with this first version and how that first customer reacted, in effect, not knowing what to do on this website because so new to them. They actually realized, okay, we actually have an internal incentives problem, because who's going to teach or guide our customers? Oh, our salespeople. That's easy. But why would they give away their sales to the website when they earn commission on selling it themselves? And all of a sudden a new topic came up that was not in the spec. Sure, as consultants, we could have known it. We could have guided them there doing discovery, but still, it's an early discovery that made a huge difference in what we actually ended up working on. And then we continued from there iteratively. It was really, really nice. Worked even in the consulting setup.
- [29:24]
B
So, Vilko, when you're ready, let's publish an article about that story on the blog because I think that story is incredibly valuable and will be a great example for all consulting company and software development practitioners out there. The key thing that struck me from this story is exactly this idea that once you change the dynamics, let's release in two weeks, something, whatever that might be, then the mindset of people completely changes. It goes from let's put as much as we can to what is the one thing I want delivered. And as you then illustrated Vilco, and this is really important, once you see that live, and most importantly the customer sees that live, you start getting feedback that develops totally different insights into what is next, the most important thing. And I think that that changes the dynamic, right? And this is what Sven Ditz talked about in the Global Agile Summit. Make sure you check out the book because he talks about changing that dynamic, how they change that dynamic with their clients so that instead of having this huge contract with a huge budget, they'll just say, hey, we'll do something in two weeks. If you like it, you pay it. If you don't like it, you don't pay it. So let's just do something, right? And that totally changes the contracting dynamic and also the way software is delivered.
- [30:46]
C
And I think to this dynamic, what's, I mean, the groundbreaking thing that's happening right now is AI and it really feeds into this direction because instead of speaking you can actually building, you can see things, you can, you can do stuff that you can really test in a much more real way than you.
- [31:11]
D
Could just a few years ago.
- [31:14]
C
Absolutely.
- [31:15]
B
I think that now it's time to talk about one very specific thing that affects how we do software development for clients, which is this idea of maintainability. Jakob, you described the challenge of convincing the clients to pay for things like testing infrastructure, long term maintainability, probably code reviews and so on. Things they don't immediately see value in because they think you code perfect code right. Like every client will think you do it right the first time and it's always perfect. That's not how software works, but that's how clients might think it does. So what approaches have you found that actually work when trying to explain the value of to a client who just wants features fast or all of the features in one go?
- [32:04]
C
Most often I just simply think it shouldn't be a choice. Like we have to be very firm on this is how we work. We are the experts. You are paying us for building this because you trust that we are the experts. I think when it starts becoming a choice to, to customers and it's really, really hard to educate non technical customers in how good software is built and have them understand this whole process why you need all these different things, why you need these reviews. It just simply shouldn't be a choice. That's an example of a consultancy company that I've come across. They work strictly XP, so strictly extreme programming and they don't explain all the details to the customer but they explain we need you in these meetings, we need you doing this. We're going to pair program, this is how it's going to happen, this is how we do all our projects. It's not a choice, this is how we do. I don't know how they're doing financially but I think it's an interesting model. But basically it shouldn't be a choice.
- [33:17]
B
Well, that's one perspective. I'm sure clients will probably want to dictate how you do write code but I see your point and I think it's a very valid one because we're supposed to be the experts in software development and they're supposed to be the experts on their business. Right. But how about you Vilco, how do you see this?
- [33:38]
D
Yeah, we do see the occasional client to really as an opinion, strong opinion on the code but aside from those I think I also believe very strong much in this. It's not shouldn't be a choice. It's not like we phone up our client and ask them are we allowed to use Google Search to look up something? Right, we just do it. And there's one challenge however when it comes to especially testing or test automation primarily testing seems to always somewhat be acceptable. But what I would, what I'm working towards is getting away from this enormous amount of manual effort when you can automate it is that when that comes into the estimation process, our favorite concept then there is a tendency for padding to happen. Oh, but we also need to do the tests, right? And one thing that I've been doing a lot is to try to show how testing actually saves time in many scenarios because it actually even I've shown it even as a tool for developers just to be slightly more effective because you don't have to click your way through a product, you just run a test and a split second later it tells you yes or no, you can run it many, many times and without that you basically click your way have to keep typing in things into fields again and again and again. So you can actually, even without comprehensive coverage, you can actually speed up by having Good tests.
- [35:18]
C
I think one of my frustrations here is I think some of the problems in this area are very much on consultancy companies themselves with the current market, which can be a struggle sometimes, it sometimes becomes a race to the bottom. And so there are consultancies that kind of underbid each other and over promise to the customer. And then suddenly you will have executives within your own company that come and say, hey, they promised they can do this for X amount of hours. We said Y amount of hours. Why can't we do it for X amount of hours? Oh, but they're known for building a shitty product. Yeah, but the customer only looks like the price or they're going for short term gains or whatever it is. I also think we are to catch the business. We kind of do this within consultancy as well, where we kind of over promise to the customer. And then finally the customer might find out after the project is done, after they pay the bills and they see this and see that there are some bugs in the system. And then you start arguing who should fix the bugs. And then you throw out that consultancy, you bring in another consultant, it opens up the code and says, oh my.
- [36:43]
B
God, we're never going to touch this.
- [36:46]
C
Exactly.
- [36:48]
B
All right, well, thank you very much, Jakob and Vilko for being with us. We're close to the end here. But before we go beyond the Jakob's article in the Global Agile Summit book, the link is in the show notes. What is one resource that you could recommend for people who want to explore how Agile applies in software development within a consulting environment? Jakob, let's start with you.
- [37:14]
C
I'll be honest, I'm really struggling with this. I think this is a big hole and I wish we had more. And a lot of people say if there isn't a book about it, well then. But the book I mostly recommend within consulting is Jerry Weinberg's the Secrets of Consulting. I actually have it here. I think it's the best book on how to be a good consultant, a good advisor, and how to kind of help your clients in the best way. Not that much about estimates and other things, but it's very much being a good advisor.
- [37:55]
B
How about you, Vilco, what would you recommend?
- [37:59]
D
I will echo this struggle. I think there is actually, generally speaking, perhaps too little real good material for consulting companies in the agile space. I think the book that came to mind for me was one from Nick Brown, recently released. It's called Real World Agility. And what I like about that, I wouldn't say it's specific to consulting but what I like about that is it provides one a different perspective away from like an alternative also to the whole estimation idea because it goes a lot more into data, into statistics and how to use that to guide your process. And while it aligns with my thinking, as I mentioned earlier, these big scopes with everything being thrown in, a lot of what we're currently focusing on is how to create or break this all down. Smaller batches, smaller cycles, smaller, shorter feedback loops. And this book I think helps also with that in terms of the data, actually visualizing that for clients so they actually see a bit more about the process. I think that's quite a nice book.
- [39:14]
B
Absolutely. So we'll put the link to all of these in the show notes. Be sure to check them out and get in touch with Vilco and with Jakob to share your thoughts, maybe suggest some things that you have tried and ask questions to do that you need to know where to find them. So Vilco, let's start with you. Where can people find you and learn more about the work that you're doing?
- [39:38]
D
I think probably the easiest is LinkedIn as a easy place to find me.
- [39:45]
B
And we'll put the link to your LinkedIn profile on the show notes. How about you, Jakob?
- [39:49]
C
Same thing there. Follow me on LinkedIn. I do write. I wish I spent more time writing, but I always share those things on LinkedIn and I love the interaction. So looking forward to talking with you.
- [40:03]
D
Absolutely.
- [40:04]
B
Thank you very much, Jakob and Vilco, for your generosity with your time and your knowledge.
- [40:10]
C
Thank you.
- [40:16]
A
All right, I hope you liked this episode. But before you hit next episode, here's the deal. This podcast is powered by people like you. The members who wanted more than just inspiration.
- [40:28]
B
They wanted real tools and real connection.
- [40:31]
A
To people who are practicing agile. Every day we're talking access to over 700 hours of agile gold, CTO level strategy talks, Summit keynotes, live workshops, E courses, deep dive interviews, books. And if you're into no estimates, we got the pioneers of no estimates in those Deep Dive interviews as well. Agile business intelligence, creating product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners. Plus a private Slack community which is free of all of that AI slop you see everywhere. And of course, without the flame wars, it's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership so head on over to scrummaster toolbox.org membership and join the community that's shaping the future of Agile. We have so much for you, so check out all the details@scrummastertoolbox.org membership because listening is great. It's important. But doing it together, that's next level. I'll see you in the community.
- [42:06]
B
Slack we really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes? Share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is caring.