Hi, I'm Richie, software quality coach, keynote speaker and author. My guest today is Derk-Jan de Grood. Derk-Jan is a principal consultant and Agile inspirator. He's known for helping organizations take the next step in their Agile journey, not just with theory, but with hands-on practices that deliver real value. As an RTE coach and value delivery expert who works with leaders, scrum masters and teams to drive agile transformations that stick.
He's a respected international speaker, a columnist and the author of several best-selling books, including his newest one on surfing the waves of agile. We first met at the testing retreat last year and had some great discussions about agile quality. In this episode, we talked We talked about Agile quality too, and what it actually takes to make it work in real teams. Are we living agility or just following frameworks like a checklist?
What happens when everyone is responsible for quality but no one really owns it? And why are we still surprised when developers test faster than a single tester can ever catch up? We explored how to break testing and improvement down into small actionable practices. Deg-Yan shared how to scale skills, not just frameworks, and how to connect strategy and team-level action through shared responsibility.
And we looked at where quality gets lost today, and how the biggest blockers often sit in the management level, not in the team. And a little goodie, if you listen to this episode, there is a chance to win a book from Jan, his newest book, just follow the link in the show notes. And now enjoy the episode. Hi, Derk-Jan, nice to have you on the show here. Very good to have you here as well. I'm glad finally we found the opportunity to meet, although it's online.
Yeah, yeah. We met in person last year on the testing retreat. And then we get in contact and I said, Okay, you have to come to my podcast here. Because, yeah, you're a brilliant mind and have a thoughts about agile and quality. And so I think it's a huge benefit for the for the whole testing community too. Yeah, and I think we have a great topic when we when we talk to each other. It's it's about agile quality. And how do we do agile quality nowadays? And
yeah. So what's your first thought when you think of agile quality? 2025? five. So it's a nice question. Well, I'm not really sure. But the funny thing is, I think it splits right between between leading people and lacking people or something like that. Because, as you know, I've been doing a lot of testing in the first, say 20 years of my career, and then I moved over to more agile kind of stuff. And the recently, I was at
interim a test manager. And I didn't really like that in the first place, because I was only two months or something so very short. But But in the beginning, I didn't like that, because I thought all things probably changed that much. I don't want to do that anymore.
I'm not really sure if I'm capable. But in that context, so you got leading and lagging, of course, it wasn't that that because we didn't get really to assess manager didn't really get into the tooling and that kind of stuff where a lot of things have changed big time I think. But on managerial test managerial stuff it's not that different
and in that organization we were still having a lot of the old school problems. So it was really like memory drawers like I was working in a suddenly oh wait now I remember we always had oh we have the problem here as well. So in that case fundamentally I'm not thinking has changed a lot testing this and didn't really do that changed a lot. On the other hand I think technical did a And yeah, for the leading part. Yeah, I don't know, actually, do you? Agile testing is that
much different than testing? No, I think it is the same principles. But I what I what comes to my mind is that agile and agile project forces you to use it. Because you have to you cannot sit and wait until you get some increment. And on the side, no, there is then And if I talk about testing, I talk about also having automation in place, the CECD pipeline. That's not agile testing, that's just proper testing.
So if you have all those things in place, all those competences, all those, how do you call it, skills done and you're doing it in a proper way, it doesn't really matter. But I'm still surprised that sometimes I see organizations that start a new project, big project, and then I think, "Oh, probably everything will be done automatically, right?" and I look at look in the plans and like, Oh, I still do manual testing on functional level. Oh, where's your CEO? You don't?
Yeah. So that's that's that's the testing nowadays as a standard, the defective standard. Again, it's the leading leading thing, right? Yeah. Yeah. And what do you think it's for for a team to get into the testing and quality stuff more when you look at that from the leading perspective. So how do you think, can we get people there that they use their knowledge and what they all learned about testing and the stuff?
Well, I think it's the thing, having the knowledge together and using it or allowed to be using it. So lately I'm talking about a lot about scaling up. So not scaling up your agile, but scaling up. And it's all to do with of course with the Agile manifesto where they say any principles like technical excellence kind of thing. But it's very difficult to grasp I think for organizations as well as practitioners, whether they're Agile or quality or whatever role.
And for me, I'm talking a lot about practices, where practice for me is like a small container, the smallest container you can think of or something like that sounds really Agile, right? of skills, knowledge, and mindset that you need to do certain tasks well. So for a traditional tester, I think one of those could be the container like using test techniques. And then you have a lot of techniques that you can use, of course, but basically the skill is using it or the practice.
And CACD can be a practice, et cetera. There's a lot of practices that you can do. And I can give you some examples if you like, But what I like most is if you do that, basically you break up the whole thing of innovation and skill knowledge or something like that into really small things. It's much easier to grasp. And then you can start talking with a team, I think, like, "Hey, I have these skills, I have these skills.
"Shall we exchange knowledge?" And then you can do all kinds of things from lunch session, brown paper sessions, books, reading, whatever, just to practice that or do some mopping or something. But also on organizational level, you can also play a different game. Because I've been in too many games, organizations, also the more agile ones, they really thought we should do something with innovation or something. And then people got room in teams to do 10, 20% innovation.
Yeah. And they were like, yeah, what should we do? What should we do? And it was too big and not good to grasp. And on one hand, you had the management layer or leading layer, leaders that said like, we want to do innovation. Why is it anything happening? Why is anything improving?
improving and the other teams say like yeah what should we do and if teams don't know what they want to do then business probably say if you don't know I know what you want to do and then they stack with a lot of work again but we're making that more more tangible by using more practices and say like shall we just do CCD or shall we do test automation shall we that kind of stuff I think I played around with that on a lot of workshops as
well yeah so it's just an idea that's starting to get a grasp of my mind more and more yeah I think there are two very important things, what you mentioned here, is that the first one is to do the practice and the training stuff. Because I know a lot of testers who know the testing techniques, but they don't use it in real life.
So to get practice in all this stuff like CI/CD, like test automation, like test design techniques, test data generation, all this stuff is very crucial for doing a good job. Yeah, but all together it's a very big heap of a lot of work and everybody says, "Now then I'll just continue doing my ordinary job." It's too much. Until you break it up into small pieces and start talking about it.
Yeah. Yeah, and that's the second thing I like very much is when you have these small chunks and say, "Okay, who has the skills for that?" This deals with, I think, a big problem now in HL teams when we say everybody is responsible for quality and everybody should do the UI and development and test automation and so on and nobody, a developer wants to code and wants to do his stuff and not doing some UI design or something like that or doing data.
But if you break it down to this to the small chunks and say, okay, who has the skills for this? Who wants to become better in it or something like that? Yeah. And you don't have to do it in a team, right? Yeah. I think like five years ago or something, maybe more, we were really like the multiple discipline team. Everybody's a developer, separate testers can't be. I don't think we want that now anymore. Not that strict. So I should say like the team should be self-sufficient.
So all the skills and all the knowledge should be disciplined, should be in there, preferably. You can specialize still. But you can still do it in a guild or something like that as well, right? So if all testers once in a while come together in a guild or a chapter, what you call that, can still do the same game. You don't have to do that also only with the team. Yes, it's a great approach, I think. And when you when you see a good performing team today,
is there still a real tester in there? Or is it more a quality guy? Or some is it is it done by the developers? What do you think? I think it depends a lot on on on the level of testing, basically. So if you take your female, of course. So the more technical tests are mostly done by the developer. And I think you can actually ask them to do that or assume that they should, something like that. I recall that it's a demand, right? They should.
But I think the more functional tests, well, that's maybe a shimmering area, but all the end to end testing, or maybe the process testing or the AA, I recall that, where the people can really work with it, might still be something for a tester's job. But I also had sometimes where I had a small example, which is an old example of a small team, where there was one tester who was testing the work of say five developers, and he was working his guts out.
And then we sat with the team and said like, he's working very hard, and you're programming with five people program faster than he can test. So we made him more responsible for the test strategy. And we said like, what tests can we do? Should he do as a tester? What tests can you do as a developer? And then we made some kind of table. It basically is in the book that I once wrote, but I don't know which page. So I'm not gonna look at it now straight away.
But basically, but I say like, if you can help me on this part, then I free some time and I can think more strategic. And I think that was a very nice, mature situation. So that was one of the later test projects. I didn't reuse that anymore. So it's coming from real drawer somewhere. Yeah. Oh yeah. Now we talk about it. Yeah. Okay. I think that's a good thing, right?
If you're a test manager or a tester, if you can move a little bit to the strategic level and you're not running and then you can say like, I want these tests to be done and then on one side you can go to the organization and say like, hey, is this the test that you want me to do? Yes, yes, yes. And on the other side, you can say like, this is all the tests that we need to do, but I don't have time, give me an extra tester, or maybe you can help me out on this part or that part.
And then once more, it becomes a team activity, of course, where the responsibility is of course of the team, but everybody has its own specialism. - Yeah, and what do you think the role of the developer in this all quality stuff, how has it changed in the last years in the in the all the HR stuff? I don't know, actually. No. And the good question is why don't I know right?
So I'm thinking now myself whether that's what I'm less involved with teams and more on a strategic level with with transformational things working. Maybe that's one thing. I don't know. No, no, it should still be and I think that is still a core responsibility of the whole team. I think that's grasped by many people. Yeah, and when we go to the strategic level, so we look at the transformation, so how is the way of going into agile nowadays?
So when I remember in the beginning, we had just the scrum and maybe some Kanban style, and we did all these frameworks and tried to get it stuff. But how can we start today to go more into a real agile or into more value-based or a mindset or something like that? Good, good question. Well if you completely, now it doesn't really matter if you're completely rookie or not, I think you should start with why you want to do it. Because that's a good question, yeah.
A very difficult question maybe as well. I just had a talk with somebody who says like, in one way you could say that the heydays of Agile are something gone, right? Depending on what organization you are still doing organizations that really are starting. But we used to find it very cool to be Agile. Now it's less Agile, less cool at least. And two years ago, it was really cool to have a PI event, something like that. It was more about the PI event than the purpose of the PI event, I think.
So if you say, "Did you do your PI?" "No, I didn't. I did a PI event with so many, so many. How cool am I?" So the bigger the better. But now it seems to be more going to, like, why are we doing that? So personally as a professional, I'm shifting also from agile transformation much more to that, towards more value delivery expert. Value delivery can be quality value delivery, something like that, business value delivery. whatever you want.
So in that way, the real purpose should be like, Agile could be cool, but it's not our main goal. It's just a way to get to another goal. - Yeah, yeah. - And I really liked, 'cause yesterday I had a talk with somebody, he says like, yeah, we wanna do some more Agile. But basically, although Agile might be a little bit on the decline, agility is not, right?
But Agile, I think we can still use it as a vehicle to get the message across and to get people more responsible and more self-assured and get more decisions lower. And I thought that's really cool. Yeah, I think that the question for the why is really important there because a manager often sees, yeah, we just want to get some money back and want to release faster and save some costs and this stuff.
But the real purpose of doing Agile is not really asked or they do it because it's like a hype or something like that. And please enter on stage the practices again. Because what I did, I like to talk about this book a little bit. My old book, it's four year old. Next month or this month I'm going to launch this one, which is the updated version. No difference, right? The scroll has become, oh, that's also different because I grew older.
The scroll has become a giraffe and yes, I grew a little bit older. In here, there's some practices again. When I wrote this book, it was much more four years ago about being agile and going agile, cool. Maybe if I started writing this book now, I wouldn't even use agile. And in the update version, I tried to reduce the agile a little bit and improve the sense a little bit more.
For the same thing, like those practices, in this book I mentioned in the built-in quality thing, you've probably read it once, right? With all these kinds of things, the practices. I identified something like 75. And then in built-in quality workshops, I always say like, if you wanna improve your quality here or there, or there in the software development lifecycle, How are you going to maybe by embracing practices, a good way to sharpen your tools and actually improve something.
But now I made that list a bit longer. I think I'm 100, 150. And I think if we were sparring together, we can come much more as well.
But the good thing you can, if all those practices make up good software development or agile software development or agile, it's very easy to say like, which of those practices actually help you to reduce costs or which of those practices actually help you to speed up or which of those practices help you to reduce the number of returns or quality errors or something like that, fault injections. I did it even by asking Chechi GP. And they're like, of all these practices, which one?
And it came up with a very nice list. And now whether that's correct or not, I think as an expert, you can always judge the better, but wouldn't that be great to say like, if all the things that I managed to have and I can do as an organization or as a group of people or as a team. If you don't want to agile, but you want a cost reduction, then I should start and then you can really cherry pick practices.
And you're still doing agile because the agile practices and you're still doing proper development because the development practices, but you can sell them in a completely different way. So that will be much more easier to go back to the very first question I think we started with, to align with the business that says like, we want a cost reduction and as a team to respond to that, like, oh, if that's what you want, we want to work on these things. Because I think these
will improve our quality, especially as testers, of course. And align with your ambition to do this or that. Wouldn't that be great? I like the view very much because when I talk to clients who are so fixed in some frameworks like Scrum, and for me, it's like a framework, like Scrum is also a set of best practices, of practices that worked for someone or for some organizations, but each organization, each team is very individual.
So you have to choose what is working for you and you have to try it out. So you cannot say if it works up front. So you can try to do a daily meetup in the morning or something like that or a Kanban board or something like that. But you have to try it out if it works for you, it definitely delivers you a value to go forward and not it's just a practice you do because everybody's doing it. Yeah, and Scrum of course is great because I have a lot of rules, much more for instance than Kanban.
But I'm not that strict in it. My favorite training tool nowadays is my Jenga tower that I bought. So the Jenga is those wooden blocks, right? They're stacked and then you have to get them out. And I often say like, well, Scrum gives you a lot of guidelines, 15 minutes stand up every day with a team of maximum nine people, that kind of stuff. Does the world really have a great disaster if it's 20 minutes? No, I don't think so. Is it a problem if you don't do it every day? Et cetera, et cetera.
So it's the framework, right? You have to tune in and try what works for you. But if you get out too much, then the whole tower will probably fall down. And in trainings, I play with that. And I can every time in every discussion we have like, yeah, of course you can do that. But then you take out one more Jenga block. And as long as your tower doesn't fall, it's okay. But if you take out too much, you don't know what you're doing, it might fall. I like it a lot. Yeah, great metaphor for that.
It's so useful. Yeah. Yeah. When we look at the software development process up to now and all the practices, where do you say or what is your opinion where is the biggest lack of quality nowadays where we say okay there we can invest so on a general level because there we have a lack.
Yeah I very much like to say of course management but that would be too easy goal maybe to say that but in a way it's I think it's a good thing because they should be quality aware as well because they should be aware that certain practices are important and certain things. I've been struggling with a recent client a lot about like when are we going to accept things. A lot of discussion, a lot of contracts around it. And actually I still don't know.
So like if you don't know when you're going to accept, how can I know what I need to test? So in a way I think and then the test manager came so I was at the interim so I could pass it over to him as well. And he was also saying like, yeah, but if I want to do this, and especially at the end and the usability testing and use testing that and adapting their business processes on the in scope, on the out scope, who's going to test that?
I think on that area, in this organization, it was all very new. So that will take a lot of time to sort that one out. If you're an organization that does software releases frequently, then that might not be a problem at all. Yeah. Yes, so the management is the problem. Always, of course. And the other thing will probably be the first thing for each team or each organization as well. Where all the usual stuff like if you're not doing CI/CD properly, etc. Why? Start there maybe.
But I've been also in organizations that so much problem with just ordinary work that they couldn't really invest and improve anymore because every minute they needed to do their testing and going back to that one test that I wanted to move to strategic level, same thing.
Like if you need to do a lot of testing, a lot of retesting all the time and you're getting completely frustrated because you're just repeating, repeating, repeating, repeat, repeat, sleep and more testing, yeah maybe you should try to move one layer up and see who else can help you. Yeah, yeah. Okay, so I think there is a lot to do for our projects in the future. And one guide could be your new book, your new released book. So just get us into that, what's the storyline of the book?
Of this book? Yeah, of this new one. - Well, it's called "Surfing the Waves of Agile" because I wouldn't want to change the book for the second print, the title. "Surfing" because it's fun and you need to look ahead for the next wave to participate. And it's all about value delivery in a changing world. And it used to be value delivery in large and medium organizations, only to find out that actually, except for some people in retail, we're always working for large organizations.
- Yeah. (laughs) because I think everyone is, but there's a lot of things changing. We didn't even talk about AI yet, right? Yeah, we can. That's the other solution, perfect question. Yeah, let's not for this time. No, but any answer that I gave, the other answer could be, of course, AI. Like, what's the biggest challenge, AI? What's the biggest challenge, AI? But in this book, it's basically about transformation. But I've really – I used to depict very often Agile with more the scrum part,
a single team, like a reactor thing in a chemical plant. So basically, you have some metal thing, you put all the kind of chemicals in, little fire underneath and that's the chemical process. And then you have some pipes in and pipes out, right, to add more stuff. And finally, the chemical product rolls out on the other side. So then you have something like supply lines and the outlet lines of the boiler. And the boiler would be the team then, of course, that makes
everything happening where the chemistry is really going. And I really have, I think testers are often focusing on the outlet, right? The outlet's everything from how do we integrate a single team performance or single team results into one product, release it on several stages, check whether it's okay, et cetera. But the supply lines are also very interesting and I have some soft spot for that. So in this book, I have a lot of talk about like how How do you prioritize your epics?
How do you do your refinement? What are the roles that you need to have? All the things that you need to have, basically for, from the idea to concrete something that the teams can build, like, aha, I get it, definition already, prioritizing, et cetera, and all the things around it for, to get that value flow going, of course.
And the built-in quality, the last chapter that we've talked about previously as well, in our other talks, is a little bit more supply, but it's also in there like, that's the storyline of the book basically. - Yeah, great. So I'm happy if I get one exemplar. (laughs) - You get one example, yeah. - And we will surely put the link to the book. - Oh no, better.
I give you two examples, two examples, one for you and one for the listener that replies to you in your fine action that you create, something like that. - Ah, that's okay. - That's a good idea, right? I mail it to you and if somebody's listening and says, "I want it," sure how you're going to arrange that you send to him. We will manage it. Yeah, great. Yeah, that's good.
And we will also put the link to the book in the show notes and the information so that I think it's very valuable because I know your speeches and your content, your things, it's no blah blah, it's all real practice and I'm really, really happy that I can read it too and use it for my practice too. Yeah, cool. Yeah, Dirk-Jan, thank you very much to be here on the show. You're welcome. The time is running very fast with you.
So I think always, always, especially when you're recording full cast, right? Yeah, yeah. Most people say like, oh, already half an hour. Yeah. Yeah. So I think we will we will do another episode in the future. I can imagine that. And yeah, so thank you very much that you were here. And I wish you all the best for the future. And yeah, happy to see the book and to the people reading the book and enjoying it. Yeah. Okay. Meet you around. Thanks for listening. Bye-bye. Bye.