B (5:02)

That sounds like something that would feel very familiar to anyone with a project management background and training, at least for me. It does sound very interesting. When I started though, when I started looking into Agile I was a bit of a skeptic. I was a project manager, years of experience and so on with project management. And I was a bit of a skeptic when it came to Scrum. I hadn't heard too much about extreme programming at the time. When you started hearing about this, you know, let's call them experimenters trying out things like extreme programming. Weren't you also a bit of a skeptic?

C (5:42)

Well, how would I say? There was one truth I had in front of me that was the tradition of pushing menace. Suit wasn't working for me when I was living on traditional project management was just utter stress and I became a wishful liar, right Because I used to, you know, manipulate reports in such a way that will please the listener if they were bullshit. Basically. I knew it was Bullshit, I was giving bullshit. So I said, how long is somebody going to keep on this way working? What you were going to was a no result. What change was the, you know, the unsayable word. And whatever you had to change was like cutting your veins. I thought, that can't be the way of working. That's not a sustainable way of working. So, yeah, I mean, I was a bit skeptical, but anything that took me away from the madness that we were handling was good enough, you know.

B (6:42)

So I totally sympathize with this. I remember once in a project approval discussion showing a beautiful scan, right on time, all of that. And then it had the phrase underneath saying, this will only hold if nothing fails. Of course, when was the last time that nothing failed in a software project? There we go. And you've seen also like these multiple waves of agile adoption. You didn't say the year when you were kind of discovering about extreme programming? I can only imagine it was either late 90s or early 2000s.

C (7:22)

Yeah, it was about 2. I joined Sun Microsystems in 99, so I'd say that was about 2001, something like that.

B (7:29)

It could have been, yeah. So you've seen this multiple waves of agile adoption from early, almost underground days, like extreme programming to all the way to big bank scaling programs to where we are now, where you've collected so much experience and are sharing it now with the world. How would you describe this trajectory? Right, like what it was, what it became when you were there, actively participating through your career?

C (7:58)

Well, look, agile as a, as a software development, new software development approach was great. I think the people that came out with the manifesto, that's what they were, they needed new ways of working because it was up to developers, let's face it, you know, and they were speaking from the heart and they was trying to say something that was needed, really. Okay. And the big win of that manifesto is that putting the truth right in front of you. Now from there then, I believe that when the craze of methodologies came about, right, and when I say the craze of methodologies, I started thinking about the commercialization and monetization of methodologies and how can we do. That's where things started to get a little bit complicated because the general focus drifted, okay, from values and principles, that, that's what was documented and said, guys, you know, adhere to these and use this on your work and you'll see how things change, you know, and how things can evolve. It went into mechanisms and metrics, you know, and then can you, can you.

B (9:18)

Explain that a little bit. For, for those that are listening to us, can you explain exactly what you mean by this contrast between principles and values and mechanisms and metrics?

C (9:28)

Okay, now if you look at, well, when you look at the, at the agile values, right, of you know, of people over persons and you know, negotiating contracts and delivering software, if you start for example, using those and saying, okay, I'm going to look at four, I don't know, I don't know my heart anyway, but anyway, if you start looking at each one of them and say, how do each one of them, this makes sense to me of my environment and my, my company. And you see, how can you be, you could be right on spot, right? You can be far away anyway, but that gives you the gap analysis of where you would like to be and where you are and gives you already a frame to work on, right? Okay. And the same with drop, with the drop principles. Can I do this? Can all these down go from 1 to 12 and ask can this be done? Can this not be done? And you'll find that you get a map that is completely not uniform, right? Some things are really cool and you can, you're redoing it. Some other things are completely, wow, what is it all about, right? But then you start trying to make sense out of those values and those principles and try to apply them or try to get as close to them as possible. Now that's not a methodology, that is not metrics, that's not, you know, you're trying to make sense of what those new ways of working mean and how do they map to your experience as an individual, as a team, as an organization?

B (11:01)

Why do you believe that for, for the practitioners out there today?

C (11:05)

Why?

B (11:06)

What lessons? What. Maybe you have a story to share, but what kind of crystallized for you the importance to really focus on the values and principles instead of spending all of our time and effort on the metrics and mechanics.

C (11:22)

Well, because one is leading you, the metrics and mechanics leads you to just doing something without a real purpose, right? Over just because it has to be done, needs to be done. The other one gives you the purpose of how am I going to change in order and how am I going to change my attitude, how I'm going to change the ways of working in order to deliver things more quality, I don't know, make it cheaper, whatever you want. You see, it's, that is the difference when you start focusing, you just had to do something. Then agile became a noun, okay? And that is where people were trying to be agile Instead of aiming for achieving agility. You see, that is a difference what I feel. And that's where I feel that all these methodologies, which I'm not saying they are bad. Hang on, I'm not saying scrub is bad, I'm not saying HP was bad. HP never got to be the main drift, right? But I'm not saying safe is wrong. I'm not saying less ganban. I'm not saying they're wrong. It's the approach to how they're used mindlessly and without the essence of what's behind it, that is.

B (12:37)

So if I get you right, like we started with this idea of early adopters who were, of course they only had values and principles because there were no processes. I mean, even xp, the process was very high level. They called them iterations, but it was a very high level, even less detailed than what SCRUM is today, which is perhaps the less detailed of all of the methodologies out there. And then it became kind of transition to more mainstream and that led to kind of the commercialization of specific methodologies which kind of take people away from the values and principles. So that's, I guess, your point of where we are today, right? Like that we have perhaps forgotten or spent too little time thinking about the impact that those values and principles could have in how we apply each of the specific methodologies.

C (13:24)

Correct, Correct. That's what I mean. And then imagine that when methodologies are given to people, people in general follow what's been given to them without saying, hang on a minute, how does this make sense? How does this tie in? Because something may tie in into your ways of working or intention to your context. Something may not tie into your context. Now then the next question is if it ties in grace, do it and take it as far as you first obstacle and then you try to figure it out. But if it doesn't tie into your context, what can I change? Can I change the context? Can I change the methodology? Because I. Come on, the methodologies are not sacrosanct, you know, they can be changed. I can change from any day I want, you know, and use it the way I want. If I give you a hammer to hammer, you can hammer from literally four sides, you know, the two sides of the hammer and the two lateral sides. Nothing is going to stop you how you're going to use your hammer. Okay, so that's what I'm saying is that sense making, that is not, I want to say taught, but it's not encouraged. It's just blind going and doing okay.

B (14:38)

But that's where we are today. But now you have a lot of experience, you've been in the industry for many years. You've, you've been looking at agile and applying agile for many years as well. Where do you think we're going? We're headed next. What do you expect will happen to software development and agile software development specifically, next?

C (14:58)

Well, what I would think is the seeds that have been rounded, right? That is the values and the principles will remain because they are very valuable. Is how what I do and what I invite people is to make sense out of it. And that's why now, these days I'm using a lot of adaptive intelligence to take through things which is like probe, learn and adapt. You see, that sequence will take people places because what is your problem really? And agile, for me, something has to be fit for purpose, it has to be fit for context, has to be fit for practice, and I even include a fourth dimension will be fit for improvement. Okay, which I'm saying, if there's a why, why do I want Agile? Right? Is a good thing. If you can answer that question, it's great. Then you say, well, what's my context? Where do I live? Where's my, you know, my company, my how do we work? And then making sense out of that and trying to see that Agile that I want because of my goal, can it fit our context? And if it does, great. And if it doesn't, how can we make it visible, both the context and the methodologies and the AD and the, you know, Agile, the principles and only then afterwards choose a methodology? Okay, do we, we're in a very complex environment, what we do you know that maybe Scrum is good because it is, to me, it is a methodology for dealing with complexity. Maybe if you're most like, do we do complicated or obvious work? Maybe Scrum, where flow is just, I don't know, you create your own. Maybe. Because obviously after you started understanding the principles and values of Vagile, you're free to create your own stuff, which is basically plan, do, inspect. Exactly, that's what you do.

B (16:54)

And you got to this kind of understanding and of course perspective based on many of the stories that you went through. I mean, when we were prepping this interview, you said, I failed more often than I've won. And this is very important because I think that the recognition of that is also what sets us up for learning, for that inspection and learning process. So can you share a few moments where failure taught you more than success ever could and eventually shaped your approach.

C (17:29)

As A coach indeed. You know, I remember, I remember one of the. Because I went through three phases basically of my agile life. You know, first I started discovering and thought, oh, how can I apply it to make my. To soothe my brigitting manners and wounds and put balm into my soul. Right. Then I started, I went to do Scrum was a very obvious thing. So I went into Scrum mastering a bit just to understand it more, you know, stuff like that, and then started basically consulting afterwards. Right. So yeah, I remember working for this, for the startup. They wanted to, obviously they wanted to optimize the delivery and they were using Scrunch, so they thought whatever it is. So anyway, we're trying to agilize the whole organization, but the environment, the context was very, very, very much a command and control stuff. Right. As a matter of fact, the CEO was probing to say, oh, he liked Prince 2 a lot. And this was handy because I used to practice Prince 2 a lot. And I said, what we're going to do here? So I thought, well, if we're going to. It's a real hard battle. Because that context was not agile friendly. So we started saying, well, what can I do whether I quit my job? So I said, okay, let's agilize Prince too, basically, you know, and then we tried to sell it that way. It was not optimum, it was not there at all. But you know, we took it as far as we could. Okay, then I didn't call that an ultimate success. It was just winning a battle, not the war. Right. But then it might. When I moved on to my next gig, I thought, oh man. I mean, context is paramount. Okay. So I thought, culture has to. You cannot change it up front, but it's there. It's something you cannot ignore how things are done today. So start by, start by that. Then you can see, is it good, is it ugly or is it bad? Is it ugly the good or the bad? And the ugly. If it's good, keep on doing it. If it's bad, try to prove it. And if it's ugly, to the measure possible, eradicate it. Okay? So that approach changed completely. I said, next time I go around doing something, I'll better take care of that before we. And I did, because I joined soon after a organization which was about 300 people strong, you know, and they wanted to, they wanted Scrum. Fragility was something that was decided and that was a bet. And there was no really good organizational delivery system. That was the ugly. And it was a command and control thing. Right? So started by how I say I started first with my simple Agile practices, blending into Scrum and then taking a systems approach to the whole delivery system.

B (20:47)

When you say systems approach, can you.

A (20:49)

Tell us a little bit more?

B (20:50)

Like what would you call in a software development environment specifically what would you ask us to consider as part of that overall system? How would you define it?

C (21:02)

Well, in order to a delivery system, in order to deliver, you have somewhere where there's a brought into being that wouldn't something that needs to be done. Then you have whatever architectural design face, whatever building the product, basically conceiving the product and then building the product and then delivering the product. And when those things are distinct and separate, that's kind of like silo approach, that's when trouble starts creeping in. So what I meant to do here is I'm saying to explain to people that from the moment those sales and marketing people that went out there and got these brilliant ideas and want to sell them, want them built until the team that is delivering them and put them into production and make them live and supporting them, all that is a system, you cannot be different parts. And that's why I started to say to people, you cannot be acting as you were in different people and stuff like that. And then finger pointing. So we started creating value streams, understanding things how the words from conception to delivery, from idea to cash, if you want. Right. And, and that change already radically because we had to first organize ourselves a bit around it before we started talking about Scrum or anything, you know, and that was a bit of a difference because then I had people stepping back a bit. We even organized the whole sitting floor, you know, because managers were not talking to each other and people. So we, instead of, instead of putting into little silos like here is sales and here's marketing, here's security and here's development, that's operations. We started going one of the value streams you got because we had different products by product, everybody stacked together and literally the whole floor was reorganized.

B (22:53)

So what you're saying is when we think about systems very often, and maybe that's my weakness there, but very often people think about the actual software development work, right? Like how do we get things prioritized, how do we define those things, how do we get them delivered and tested, how do we get, you know, all of that. But what you're, what you're saying, if I understand you correctly, is that actually you need to consider the system as everything that influences that smaller, concentric, perhaps even system, which is software delivery.

C (23:30)

Correct. But what I'm saying is look backwards when you're going to deliver value, there's a value chain. And value, the goodness of what we're going to deliver is not the business only of the developers and the testers. Everybody in that value stream, in that subsystem, if you want, is responsible for value in different ways in different contexts. If people are selling to the outside world a concept that is not right, there's no good for what the client needs. No matter how much goodness you put in your value stream, you're going to deliver something that is not usable by the client. So you cannot look at, oh, the development was wrong, all the testing was wrong. Oh, the product is the whole from the moment, from idea to cash, all the people where work happens with, I mean all kinds of work. Work is not coding, work is not testing, work is product design, work is, you know, good, good requirements, understanding the client, all that. And that is when I started, people is, we're not here to see who to do it. Right. Everybody had to, for example, put you an example in this, in this case, security was very important. And when I joined the company there, the security were like the guardians of goodness, right? They stood at the end of the line and they went up or down, right? Okay. I said, no, they're wrong. If security is paramount, you guys should be at the beginning of the tank building security from day one.

B (25:18)

Exactly.

C (25:19)

We literally shift them, not taking their importance out of them, because if that was important, anybody was in that department was important. But I said, okay, you're going to be here at the beginning and you're going to start putting your people, your strategic people all around the chain. So security is locked upon from the conception all the way to product development, all the way to software development. And it changed completely not the importance of the people, the way people acted. So you see, and at all this moment we're not talking about Scrum yet, okay? And that's how they started. They started, everybody, about 300 people get trained on Scrum, come on, you know what I mean? And that is the difference between starting with a methodology and started to making sense of what Agile is of standard for its purpose, context and then practice. So it took us nearly, I would say five months, nearly to start talking about Scrum while we were putting together everything else.

B (26:26)

So of course you're like, with these stories, you're also talking about how your perspective, your own personal perspective changed over the years.

C (26:36)

So.

B (26:38)

You had these obstacles, you tried to apply Agile, you had that project management background and, and you had to Think beyond what is, let's call it an agile coach. So in your view, when you think about your own perspective, your own progress as a, as a scrum master, as an agile coach, how did that change? How did your perspective as an agile coach regarding yourself and your own work changed over these years?

C (27:06)

Well, I don't think I have the magic wand to tell the truth of Ascot, but I also knew that as a coach and I dreaded this because you see, I don't qualify as a coach because I don't have coaching qualifications, right. Regardless of it's agile or anything, a life coach or whatever coach I just did because of the understanding and I drew my coaching experience if you want to invert a commas because I've been a rugby player all my life, I've been coaching all the teams, you know, so I thought. And what you do when you coach is basically understand where the, you know, establish first time relationship with your teams, you know, understand where they're where they're going, you know, and try to help them make sense the way they're going to go, keep on moving forward. So you know, that's why for me adaptive intelligence is big because and because you have to sense first in order to understand the context with things evolve and then see what the behaviors are and challenge them one at a time. Most important, first don't try to go like tip the boat completely and get every drown now you have to go bit by bit and then encourage every one of those challenges, every one of those maybe micro changes into being adapted, okay. And adopted and adapted, sorry. And probe how they work. Are they working well for us or we're not, right. So you have to do that quite fast and if it do work, keep on doing. If it doesn't work, change it and then rinse and repeat. And that is what my essence of what I again this is how I approach coaching because I am not a coach. I'm just somebody that was during the years. I've seen a lot and tried to make sense out of what's going on. And, and you cannot teach, okay. Cannot force, sorry people what to do. You have to bounce ideas or whatever. Go ahead, try it, you know, give it a try. Try quickly. Okay. Don't wait for it much learn. But that is how I see it.

B (29:27)

And I really like how you bring this perspective. Even though of course you had a project management background, which is there are many good things in project management but one of the expectations we have over project managers is that they know who needs to do what by when, because that's the definition of the job. But with the coaching approach that you now talk about, it's actually completely different because you need to understand the context and what is the goal that they are trying to achieve. And then focus on how the team interacts, how the stakeholders and the team interact so that they can sort out who needs to do what by when. Because we are in a complex environment. Software is not, in other words, it's not plannable in detail in advance, like project management asks us to do with software development.

C (30:20)

Well, I would say going back to this, you know, I'm not saying anything about project management, right, because project management here will give you a good way to guide us into how we're going to organize ourselves, right? But when I was saying to somebody once, listen, look, if you have in front of you your five most important tasks, you do one thing at a time, most important first, and finish it, then you're going to have to pull the next one, okay? And that is planning at its most simple form. That is planning. Now, what you do in traditional planning, when I see you guys get into your planning sessions, according to Scrum, the planning ceremony, you want to fit a whole bunch of things into something that is not fittable. And you just want to. And you spend time arguing about it. You spend time, you know, trying to, trying to, to see how long it's going to take. There's no sense because you're trying to do something that is not really doable. So then I'm saying agile for me is not prescriptive. And I feel that that's the way it's been put. It's prescriptive. For me, agile is adaptive.

B (31:40)

Talking about prescription, there's a very important topic. I don't know if you want to go there, but I will just in case. And that's the topic of certification. Where do you come down on. How do you come down on the certification debate? Like from your perspective and in your experience, what have you learned so that you can share with our audience, many of which are just now starting their Agile journey, Correct?

C (32:06)

Correct. Yeah, indeed. Let me first be clear on one thing. I do have certifications, right? I did once upon a time. Now, the reason I did them was, well, not only because the company I was working for was paying for them, but that was the easy part. But it's true. I wanted to see what was going on because I wanted to probe methodologies and learn to adapt them to my needs. That was basically what it was. And then it was also a Means of networking, also getting in touch with some of the thought leaders around and stuff around. So. But all seeking to be a better practitioner, right Then for the past decade, I would say and still standing this today, certifications as they are presented today is about having read the book or having attended the classroom and what has been said in a course, right. Only once in my career I saw something different, right? And that was you spend, you come and join a course for five days, then you go and you're not going to get certification yet. You go, you practice it for at least six months, develop a case and you put the case in front of a panel and you defend that case. Look for success or for failure. When we're talking it's, it's. We don't, you know, then, only then we'll decide it will certify you. Now I said now that's brilliant. Because it was so close to what I did at university. You know, I was spending about four years studying then, then going for a master's and then writing my, my thesis about some topic that I wanted that related to my field of studies and then trying to, to make sure. So these people defended which for good or for bad it meant, you understand and you, you know, you're mastering your, your, your subject, hence you get a degree. That's only once in my life I've seen that all the rest is just go there.

B (34:17)

It's an Agile certification. Mario. Sorry, was that an Agile certification?

C (34:22)

Oh, that was a Kanban culture professional, as a matter of fact. Okay. So I always thanked David Anderson because I did it with him. And I said to him, David, I think now it's the only one that created a little bit of a university. But again, it's going a little bit commercial these days. But again that's.

B (34:39)

So the reason why I ask is that ironically I know that in the PMI case, Project Management Institute, this is not the case, but when I completed my Project Management certification many years ago, it was by ipma, the International Project Management association, which is European based, in fact Switzerland based. I did preach to the Federation of Project Management Associations and they did that kind of approach where you first did, I think it was even six months of training, but not every day, right? Like it was like every second week or something, you had some topic, then you did a four hour written exam, then you did a case study and then you defended the case study with the panel. And of course what we are trying to look here and IPMA does have these different levels of accreditation so that it's not just one level, which is one of the problems with the current levels of certifications in Agile. But the point was that they really put effort, meaning the people who were giving out the certifications, they really put effort into the certification process. And perhaps the difference here is that it was not a mass product. It was a product for specific professionals who had specific targets in their life. Now with Agile, we have a challenge. We need to train Everybody, meaning literally 100% of the people in software development today in different ways of delivering software. Because most people get out of university without any knowledge of Agile and perhaps completely indoctrinated in the waterfall like ideas of having things done separately by different people and then cascading down to the final person in the chain, which typically is the quality engineer, for example. So how do you see the role of certifications in Agile in that context? The context that we are actually bringing something completely new to the world?

C (36:42)

Well, certifications, I'm not saying they're bad, okay? I'm not saying they're bad at all. Because, you know, it's a first stepping stone if you want. You're saying it first stepping stone, one level, a second level or whatever you got. If you put sort of like a learning path, okay, then it starts to make it a bit more sense. But when you're just dishing out certifications and badges that people put around into the LinkedIn profiles and stuff like that, and they got. And I said, how much? I asked the question, how many times have you burned your fingers? How many times have you learned? Because that teaches you. I'm sorry, what teaches you is that, you know, being brave enough to say I failed, I learned, I move on because I'm going to next time use it better and better and better. That's what I'm saying, is that regard, that lack of regard to what there really is. And in many of the certifications that I worked and I've seen around in courses that sometimes I attend just to be the fly in the wall, right? Is that a lot of most. The bigger part of the certification program is based on the mechanisms. Very little is said about the basis. What happens in the case of Agile, the Agile values and principles. Maybe I mentioned on the first quarter of day one, perhaps, okay, a little bit. All the rest is, you know, the ceremonies, which I dread. Okay, the worst ceremony, something that I don't like very much, but that and how you go about things about velocity and burn, that charge and then you have, you know, how much you do your planning and this all the Mechanisms which are anybody of us is intelligent enough that has been around in any kind of project to know that you have to plan first, at least give yourself a shot at knowing what to do within the next couple of days or month. Do it and show it to somebody. I mean, so that's obvious. Now the principles and values are not that obvious and you need to look at them. And that is what I criticize to it. That is certification is a good way to make quick, fast buck, you know, and all of a sudden a youngster and master goes there goes, oh, I just got my certifications. Yeah. How sprints have you ever done? Oh, nothing. Look at it. How can you give somebody about a certification and it never had done in a sprint in his life? That's what I'm saying. You know, maybe you have to say if you want to Scrum a certification, you must have done, for example, over document that you've managed about 200 or 300 sprints. Then come back and we'll discuss at.

B (39:40)

Least people should listen to this podcast because we already have more than 600 lifetimes of scrum Master experience collected in interviews right here and with this episode. Thank you Mario for being with us. We collected another few decades of experience for you. Mario, it's been a pleasure. Thank you for being here and sharing all of these lessons with our audience. Before we go though, where can people find out more about you and the work that you're doing?

C (40:08)

Well, there's a couple of ways. Well, first of all, I'm obviously LinkedIn, although I'm not a big participant, I'm not writing agent, but my profile is in LinkedIn. So LinkedIn and you go under Mario a year, one word. M a R I O A I E L L O And then I have a blog. That's where I started putting someone trying to reinvent myself a bit as a writer and that is Agile Ways in one word. Agile Ways blog. Then now I will hopefully be starting a substack that is going to be called Adaptive Ways. Substack is going to be launched tomorrow. As a matter of fact, I think.

B (40:52)

Tomorrow at the time of recording. For those of you listening, the link is already in the show notes and a few articles are already there waiting for you. All of these links for Mario's contacts will also be available on the show notes. So make sure to check them out and get in touch, interact and learn from each other. Mario, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.

C (41:16)

Okay, thank you very much. Mario. It's a pleasure to have been here and thank you for the invite.

B (41:24)

All right, I hope you liked this.

A (41:26)

Episode, but before you hit next episode, here's the deal.

B (41:30)

This podcast is powered by people like.

A (41:32)

You, the members who wanted more than just inspiration. They wanted real tools and real connection 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, book, 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 scrummastertoolbox.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 Slack.

B (43:17)

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.