Scaling Done Right with Gereon Hermkes and Louis “Q” Quintela

Listen To Podcast Episode

Keeping Agile Non-Denominational, Episode 19

Watch Video

Alex Kudinov   Hello everybody and welcome to Tandem Coaching Academy's Keeping Agile Coaching Non-Denominational podcast. We are your hosts today Cherie Silas and I, Alex Kudinov, and today we have more than one guest; today we have who have Gereon Hermkes and Q and they are authors, Agile coaches/advisors, whatever that means, and today we are talking about Scrum at Scale. So Gereon, Q, why don't you introduce yourself to our listeners?

Gereon Hermkes   Okay, so why don't I go first, my name is Gereon. I'm from Berlin, Germany born and raised and, as you guys know, I consider myself to be a reluctant coach of sorts. So I'm originally a Scrum Master and kind of still feel like it even though I do mainly coaching today. So I'm a Scrum trainer under Jeff Sutherland and also a common trainer and I mainly do some training and Agile coaching, specifically around scaling Scrum.

Alex Kudinov   Q

Luiz Quintela   Yeah, my name is Luiz Quintela; I go by Q. I'm based in Washington, DC. I used to split my time between the US and Europe before COVID. Now, it's mostly west and a little bit of Europe. I'm an Agile advisor and trainer, Scrum trainer, and Scrum at Scale trainer under Dr. Jeff Sutherland, and have been doing Scrum since about early 2006.

Alex Kudinov   That's a lot of Scrumming

Luiz Quintela   I know. I know.

Alex Kudinov   So as I'm thinking about Scrumming, and I don't remember who said that but it seems like it's all over the pages these days, 'If you want to scale, don't. Stop before you start scaling.' and you guys definitely have some different ideas in mind. So what's scaling for you?

Gereon Hermkes   I actually wouldn't say so because that's one of the core tenets of Scrum at Scale. Yes, scaling is in fashion, right, and we're experts on it but even as experts we still tell you don't scale until the very last moment that you can postpone it. The problem is that as soon as you start scaling, you tend to invite a lot of problems, a lot of complexity, into your system and a much better answer, if you're already doing Scrum, is to invest in your teams because a lot of teams are really not working at their full potential because they're missing a lot of stuff. They are not closely adhering to the Scrum Guide. They have a lot of organizational impediments. They have a lot of relationship problems within the teams. We think that there's a lot of opportunity for investment - let's call it that - into the teams so that they can get really good before you start scaling. The problem is really that it's such a fashionable topic, right? Everybody wants to scale; it's all the latest buzz and if you're a coach, you can say, "Oh, I've been coaching eight teams at the same time", right? What you should have actually been doing is focusing on one team and making it really good.

Alex Kudinov   Yeah. I remember somebody told me with a pride in her voice that she was coaching 36 teams.

Gereon Hermkes   Yeah.

Luiz Quintela   Yeah.

Alex Kudinov   So you mentioned the last moment and what's coming to mind that last responsible moment; what's the last responsible moment for scaling?

Luiz Quintela   I don't know. I don't know if I would call that but I made a name of being called in Agile transformations that went, let's say, bad and all of them, of course, were scaled. I had a client once that trained 20 teams on a certain framework. They had never seen Scrum before and then they didn't know why it went wrong, right? I mean, you send everybody to training, why is not working, right? So I wouldn't say you have to wait until the last possible moment but you'll have to wait until you have solid knowledge, understanding and practice of Scrum. What happens most of the time is people get to this project, "Oh, we need to convert from the old system to the new system." "Oh, great. Let's train everybody to do Scrum and then, since we only have a year to do that, let's get about 50 teams with 600 people doing this" and things go bad. So I think when Gereon says, "the responsible moment" is, that is when you have maturity in the teams, at least enough maturity, to make sure that people are able to practice things in a way that doesn't get amplified all the bad practices. That's not usually what we see.

Alex Kudinov   Yes and as an Agile coach, or as a coach, or an advisor, how do you go about estimating whether the teams are at the maturity you would like them to be to scale?

Gereon Hermkes   Yeah, so let me jump on this one and going back to the question before, one thing I would like to add is, I think there's also a missed opportunity, right? Because the investment that goes into scaling could have gone into the team and there are a lot of treasures to be found in really investing into the team and not just on a surface level. Okay, let's send the Scrum Master to a class for two days, but actually really investing into the team, because scaling is very expensive. So how do you know it? Well, it's kind of tricky to say, from a business perspective, I would try to look at diminishing returns on investing into the team. So if you're really like taking a business view but from a practical viewpoint, what you should always be doing as a coach is helping the team to self-assess, right? So find a way to work with the team on assessing themselves and helping them to find opportunities for growth and then try to find a point with them where you mutually agree that a lot of improvement in velocity, for example, can easily be had. I think that's a good starting point to see. Okay, so we're really doing good with this team, there's still a lot of work that needs to be done. Maybe this is a good point to add another team.

Cherie Silas   Yeah. This brings to mind different companies that I've worked in as an Agile coach. Like you said, there's always a big buzz about "We've got to scale! we've got to scale!" What I've often seen is the conditions in the company don't exist to even need to scale. So I'd like to hear, from your perspective, what are those conditions that tell a  company, "Maybe we need to look at how we scale things"?

Luiz Quintela   Let me jump on that one. Like I was telling you guys before we started recording, I work a lot of leadership. One of the things that I see a lot is leadership doesn't quite understand Scrum but there is a tendency to copycat. What I mean by copycat is, "Well because so and so is doing Scrum, and it's working so well, let's do it!" They forget that the company itself does not have the knowledge, does not have the understanding, does not have the structure; the whole premise is starting on a very shaky ground. You are copycatting without understanding if a particular thing, in this case Scrum, even works for you. It should and it normally will but you have to first understand what you're trying to achieve with that. To compound this, they don't want to start small, they want to start really big, which exponentially grows the problem. So I spend a lot of time working with leadership, especially when things went bad, explaining to them how Scrum works and making sure they understand that so the copycatting is stopped and they assess the situation at 'what we did wrong.' One of the first things they figured out is we really didn't know what we're doing and we went to just, "Oh yeah, it should be very easy" and it isn't because I have a client right now that Scrum Master doesn't even exist as a job title. They were having trouble finding Scrum Masters because people don't see a career path. That was relatively easy to fix but they didn't know about that. So I think in order to have the conditions there, you have to make sure that the leadership, especially senior leadership, understands what the framework brings to them and what can be achieved with them and not just simply copycatting because you cannot change the organization if people don't understand what it takes to make that change. Sometimes they even think there is no need for a change, right but we all know it's quite the opposite.

Cherie Silas   Yeah. So Q you mentioned the Scrum Master role and I think Gereon you mentioned the Scrum Guide and that makes me wonder, the new changes that have happened in the Scrum Guide in the last, you know, last few months, how does that impact the work you do? What's happening with that?

Gereon Hermkes   So one thing I see, and I think that was the intention behind some of the changes, is that...well, Jeff Sutherland said that they are witnessing that a lot of Scrum Masters aren't really doing their job, they're not really performing the role appropriately and that's why there was this change from role to responsibility. I think some people are misinterpreting it and going too far with it but I think the general idea behind it was to call out the responsibilities of the Scrum Master more, which isn't to just invite people to meetings, and maybe preparing the retro but it's actually being a leader, actually removing impediments, actually working on continuous improvement items to make the team become quicker. I think that's a big issue and Q and I have been having this discussion for a long time because he is originally Product Owner and I'm a Scrum Master. He was always like "Ugh the Scrum Masters, they don't know what they're doing." and I was like, "What are you talking about? The problem are always the product owners; they are the ones that don't know their job." but I actually had to eat my own words there because I have now seen it and I totally agree now, because there are Scrum Masters who don't really know what they should be doing. In turn, the rest of the organization then says, "Well, we don't know what our Scrum Masters are doing. It's supposed to be a full time job and they just go to their Scrum Master meetings, and nothing is happening. If you look at the velocity of the teams, it's not improving. The conflicts in the teams are still there, nobody's taking care of that, and so I think the problem of Scrum Masters not filling out their role are a big part behind some of the changes. I do appreciate them. I was a little bit reluctant in the beginning, because I really liked that term of servant leadership, it really resonates well with me. Now that the focus has been moved to true leader, I actually saw that resonate with a lot of Scrum Masters that they actually have a bigger role to play and that they should be a little bit more...forceful is maybe not the right word but maybe step more into that role and start to affect more things.

Luiz Quintela   I actually would add, because we have this conversation all the time, like Gereon said, I think the way we train Scrum Masters is pretty defective and I'll explain why. I just had a new department added to me a couple months ago and the first thing I asked the Scrum Masters is, "Do you know what your percentage of process efficiency is?" They didn't even know what I was asking. Then I asked them, "Can I see your value stream mapping for development?" Blank stare. So I think we don't train Scrum Masters properly. I think actually a two day class is completely inefficient. You know, when I teach Scrum Master, the minimum I do is three days. I have the advantage, I don't do public classes, I do private classes so I can tailor them very well but I also think that one of the things that the Scrum Guide brought up forward is, we forgot the leadership. I think we talked too much, "Servant leadership is completely hands off. I'm just here to serve." but the Scrum Masters forgot that leadership. I think a lot of people confuse leadership with management. That's not it. Leadership is actually having your people's backs, it's protecting them, it's making them efficient but I think a lot of Scrum Masters their training is very lacking. They don't understand Lean thinking. They don't understand the value streaming. They don't understand lots of things that are core to help process improvement. So I think the Scrum Guide bringing up this leadership and accountability and all this concept is actually going to make the favor to sort of wake some people up.

Gereon Hermkes   Yeah, and I think the Scrum training, it's a starting point, right? Some people see it as an endpoint. "Yeah, took a two day class or a three day class and now I'm good to go" and  it's actually just the start of your journey, and it is a journey that you have to do you still have to lift those weights and have to go that way. So I think some there's sometimes confusion about that.

Alex Kudinov   So it's clear who of you two is the problem child. It's Gereon. There's always a problem with Scrum Master. Let's go on to less problematic side on the product ownership. We know that Scrum is built around products, right? People who work together in teams to create great and creative products and solve the problems. So how does scaling, change approach to product development?

Luiz Quintela   That's my ballpark. I think Scrum is built around product but product ownership, it's also not very well understood. Scaling requires product management, which is far more complex and encompassing than product ownership. I think of product ownership as being more tactical and I think product management are being more strategic. What I mean by that is, if you go to a team product owner, in most cases, and you ask, "Hey what marketing collateral is going out? What are your revenue streams? How do you intend to monetize this?" a lot of them don't get into that because that comes from somebody usually called 'tThe Business', right? That's where the product management is happening. When we scale, I think one of the beauties of Scrum at Scale, is putting emphasis on this thing that we call the EMS, the Executive Meta Scrum, which is a central sort of authority -- I hate to use that word -- that deals with the product management, deals with, "What's the product direction? How are we going to put this product out the door?" and all those things that are strategic, and then that cascades to the product owners, which can then, in their teams, do the tactical things and make sure that things are being developed, and they need some criterias of acceptance, etc, etc, etc. I think, even at single team level, a lot of product owners are not familiar with product management and how to do that and I always tell people -- I actually use this in the morning; I was having a meeting today -- "We are concentrating on output. Output means nothing if it doesn't achieve an outcome." Especially when you use Scrum in IT. It's all about output, "We have to get this out! We have to get this out! We have to get this out. Well, I have news for you, right? I use PowerPoint a lot, maybe I use 10% of it so the other 90% are output and that's a waste. It's not making my outcome any better. I think that's one of the problems we see with product management/product ownership is they don't emphasize the outcome. I want to have a happy customer. I don't care if I put 20 user stories out or 200. I may put 200 user stories out in production that the users hate. That's one part that we seem to forget. We are obsessed with output and we forget the importance of the outcome.

Alex Kudinov   So I have to recognize that there are definitely different schools of thoughts around product ownership, product management, and you go one way and they say, "It's all Product Owner and Product Owner is responsible for ROI", and you go another way they say, "It's Product Owner works together with Product Manager" and those are two separate roles, two separate organizations and all that. I think what they all agree on, though, and what you are to bring up is that, we as a community, we as a trainer community, we don't provide enough of holistic training; We don't provide enough of holistic roadmap for people to develop in their chosen way, whether it's a Scrum Master or a Product Owner. So I know you both are trainers. How are you thinking about people development in this specific kind of roadmap, if you will?

Gereon Hermkes   I think that's a very good point and so when I'm looking at Scrum masters or as potential Scrum Masters, I'm always looking at their leadership potential first because that is the arc that they will follow as they develop. How good can they deal with people? Also the serving aspect, right, what kind of leader are they? That's basically the arc of it and now we've heard from Q that on the other hand, on the Product Owner side, the Product Owner training is also only a starting point and then it develops into something larger, like a Product Manager. There seems to be a lot of confusion because people think they can work as a product owner for a year and then they are a fully fledged Product Manager as if they could take over a product at Apple and be successful with it. I think if we construct the roles more as developmental arches in which people can grow over time, I think we're really doing them a service.  I can just talk for myself, in the beginner classes, the Scrum Master and the Product Owner, my main focus is on the mindset. There's a lot of material, there's so much material actually, that it's kind of difficult to use all of it to get everything across in two days. So what I'm trying to get them to understand is the mindset. So for the Scrum Master is, for example, well, "How do you lead the team? How do you support them? How do you achieve flow? Why is it important to take care of impediments?" Right? A lot of people don't seem to really understand that, in a sense, the obstacle is the way, right? You could say, "Well, yeah, my job is to increase the velocity" but what does that mean? Cracking the whip? It's actually the obstacle that is the way and that's the impediment. The impediment is not something bad but it's actually the way through which we support our teams, and increase velocity, and become more productive, and become better leaders also.

Cherie Silas   So when I hear you talking about that leadership, it makes me think of coaching; the thinking that professional coaching can help people in leadership to take things to the next level. So I think I get how professional coaching can help Scrum Masters and Agile coaches and I'm wondering how this actually might connect into the ability to scale? What are your thoughts on that?

Luiz Quintela   I think it's actually more important at scale. When you're talking about scaling, you're talking about coaching an organization and not only individual teams. Coaching, actually, it's important to coach teams how to communicate; cross team communication is extremely critical, especially when you have a large number of teams.  I work a very large organization so for us having a group of 30/40 teams is very normal. I see people having difficulties communicating between 4/5/6 teams, let alone when there is 30 in there. So it's important to have proper coaching to making people understand that without communication, things will not work. It doesn't matter how good your Scrum Master is, how good your Product Owner is, how good is the Chief Product Owner, the Chief Scrum Master, all of this, if people have trouble communicating. So it's important to coach leadership about the fundamentals, how the organization should work, but it's also how the organization should communicate. When we talk about removing impediments, honestly, a lot of the impediments, they could be removed at a lower level much faster if people knew how to communicate. So there's a lot of opportunity for. I always say training works like this, you train people, you mentor them, and then as they mature, you coach them. I think people kind of skip steps or they go into coaching before the team is even able to understand what they're being coached on. So there's a lot of opportunity for coaching, especially at scale, because the complexity increases and therefore there is even more need at scale, then it is at team level only.

Gereon Hermkes   So for me, the thing that I really like about Scrum at Scale -- I actually learned this from Q through one of the coaching sessions because I was a visitor there at the beginning, and now we're doing them together at least once a month -- and so what's really interesting about Scrum at Scale to me is that it seems to really fit well together with professional coaching, in the sense that it's not prescriptive at all. It lays out basic structure but that structure can be easily changed and we're not forcing anyone to do anything. So basically how Scrum at Scale looks is we have two cycles, one for the Scrum Master and one for the Product Owner. If you look at those, it's basically two circles that overlap in some parts and on these two circles, there are bubbles which represent different components. So one of the components on the Scrum Master side could be cross team coordination. Another one could be deployment. On the Product Owner side, it could be vision or backlog decomposition. So you have these different components but we're not telling you how you should do them right? So is it a good idea to have a vision? Well, probably, if you want to have some kind of decentralized command, which you usually want to do in Agility, because that's where the action is, that's where people have the knowledge, then it's probably good to have the vision but how you arrive at it, we don't really care about that. Is it useful to have cross team communication if you have cross functional teams that are not in functional silos anymore? It's probably a pretty good idea but we don't really tell you or prescribe how you should do that. Basically, what Scrum at Scale is, is it's a network of different components that we think you should use, but that you don't have to use. The way it's constructed is that it's basically like an API. So if we have a component, such as the vision, we define the inputs and outputs to that component and as long as you respect those definitions, the inputs and outputs, you can do with a component however you want to use it. A side benefit of that is that if you want to work on your vision, for example, you still keep the whole system intact, right? You only work on that component and the rest of the components aren't affected because it's kind of like a network; it's like a USB slot, it doesn't really care as long as you respect the requirements of the USB slot. You can add a printer to it, you can add a stereo to it; it's really up to you. This construction, and it took me quite a while and, like I said, Q's input to realize it, it's super well suited to professional coaching in my mind because you don't have to go in there and kind of sell a system, right? It's not, you have to do this, and you have to do that and you either do it or you're doing it wrong. You can actually go in, see where the client is at, meet them where they are, and focus on the stuff that they want to work on. If they say, "For us an issue is cross team coordination", which is often the case, and you can say, "Good, let's work on that." Then you can maybe upgrade that a little bit and you don't interfere with the rest of the company. That's the funny thing, right? As coaches, we hold the space and it seems to me like Scrum at Scale is somewhat holding the space because we just have these loosely coupled components, so we can just work on that. Then if the customer determines, "Well, that's looking better now, but our deployment is really bad, let's work on that." Then you can just like, follow along with them. You don't have to force them into a structure that you determined to be right. So the implementations can look very differently between clients but that's what I really like and I think it's it's very compatible to professional coaching and what we hold dear and I sometimes wonder if not more people should be made aware of that, because I think it's a very natural approach to professional coaches to Scaled Scrum.

Alex Kudinov   So, as you're talking Gereon, I remember what Cherie told me several months ago, she's like, "Love the guy. He keeps coming back to my classes, he keeps taking classes, and he keeps telling me, 'I don't want to be a coach' and he keeps coming back." So it sounds like you found the value, you found the application. So how did professional coaching and skills change your approach to your practice?

Gereon Hermkes   That's a very interesting question and one I keep asking myself about once a week, especially now that I have a new engagement. The funny thing is, I would say, not very much and everything at the same time. So not very much in the sense that, do I think I'm a much better Agile coach because of the professional coaching? I kind of don't because I think I would have handled a lot of the things same way. At the same time, I can't imagine being an Agile coach without being a professional coach anymore, because I use it all the time. So for example, you do a one on one coaching session and the person starts crying, right? So what do you do if you're a professional coach and you keep coaching, then that's completely normal to you. If you're just an Agile coach, suddenly you're completely overwhelmed and then you start messing up. You have team dynamics that are off, how do you deal with them? Well, you do a coaching session with them, right? So on one hand, maybe I'm too close to it to really see it. Maybe if somebody would have looked at me from the outside, they would say, "Well, Gereon you're completely changed so much it's obvious" but I can definitely tell you that I'm using the stuff that I learned from you guys almost every day.

Alex Kudinov   Just hand out tissues

Cherie Silas   No.

Alex Kudinov   Yeah. Just tissue, just wipe it off. Who does tears in professional coaching, come on!

Luiz Quintela   You know, the funny thing is I never had anybody come in crying to me but they come screaming quite often.

Cherie Silas   *laughs* Cry to Gereon, scream to Q, got it!

Gereon Hermkes   Yep. I should note that I make people cry in Agile transformation.

Alex Kudinov   What about, Q, what about professional coaching and maybe with a perspective from the Product Developer.

Luiz Quintela   You know, the funny thing is, I'm known as a product person but lately I've actually been doing work more with Scrum Master than anything else, you know. So I go both ways and I grew up as a developer too. I can tell you one thing. One of the things that professional coaching taught me, that was really hard to learn, is to listen. We don't do that enough. If you come from a development background and an engineering background, like me, I'm a problem solver. The moment you're telling me, "Q, I have a problem", the third word out of your mouth, I'm already having the solution kind of brewing in here. When I took my first coaching class, it was really painful to shut your brain, keep your mouth closed, and bloody listen to people. That made a huge difference. Sometimes I relapse a little bit. I think we all do, you know, because sometimes you're tired, or you have some involvement on an issue, etc. but I always keep repeating, "Shut up and listen. Shut up and listen. Shut up and listen." I know you're laughing but a lot of people fail miserably on that and we get into a lot of trouble. So if I have to choose one thing I learned from professional coaching that I will never forget is: Listen. Listen. Listen. Listen before we start doing anything.

Alex Kudinov   We're just laughing because we remember all those people who fail at listening.

Gereon Hermkes   Actually, if I can build on that, what has changed, taking the professional coaching training, is I do even less and I have more impact. I talk less now, and Q has been talking, I talk less, I do less, but the impact is much more. It seems like everything I do is like highly targeted and highly effective. I think people are sometimes wondering how I do it and I'm surprised how I do it myself but it's less of an effort and just effortlessly listening to people and then moving at the right time and having a larger impact.

Cherie Silas   Yeah, it's giving them the space to do it and honoring their ability to run their own company. That's pretty awesome. When I listen to you talk about this, what I'm hearing is that coaching is a component, right? It's only one piece. Just like Agile is not a silver bullet, Scrum is not a silver bullet, coaching is not a silver bullet, scaling is not a silver bullet; it's a component of how we bring success into the client's space.

Luiz Quintela   It's one arrow in your quiver, right? This is a skill that you need. That's why I always emphasize you need training, you need mentoring and need coaching, right? And you need to progress towards something. As you mature, you need more coaching, less mentoring, less training, right? So it's part of it. I think one of the advantages of being both a trainer, advisor, and, to a certain extent, a coach, I do a lot less coaching than, for instance, Gareon does but I do some, I have to do some, as part of my job. It's important to acquire multiple skills and combine all those skills the same way that it helps Scrum if you are if you're familiar with Lean, if you're familiar with Kanban; the more you learn, the more skills you acquire, the best you can deal with people, you can communicate with people, you can offer solutions when they ask you for solutions, which is an advisory role, right? So learning how to coach people helped me a lot the same way that learning other things helped me a lot too. So it's a skill set that you have to build. I wouldn't advise anybody to claim to be even an advisor, let alone a coach, without having at least basic knowledge of coaching and how to interact with people because you are probably going to get into a lot of trouble.

Cherie Silas   One thing that's been really pleasing to me to hear you say is that you don't install scaling; take it out of the box and just drop it in. 'This is what we do; install everything that's in there' and yet I think that when people go and look up Scrum at Scale, they go look up these other scaling models, they buy your book, and they're like, "Oh, let's do this" and they're tempted to just like, take it out the box and drop it in. What would you say to those people?

Luiz Quintela   I went to several clients in the past five, six years, who bought this concept of framework in a box, they dropped the box in there and everybody start following the box. It's really easy, right? You have the cake recipe, blah, blah, blah, blah, blah, blah, blah. Then after a year, year and a half, they didn't see a lot of improvement. Yeah, they managed to work in a scaled environment but they really didn't reap the benefits. Then when you go there, you start asking questions and people start to think, "Well, perhaps we shouldn't have followed the prescription" because you see, my mother used to be a very good cook and she never followed any prescription or recipe or anything. She just pulled stuff and put together because you have to understand the environment. You have to understand the people. You have to understand all of this and then you can draw some elements with a real framework that's not prescriptive, and adopt them, and implement them into the environment. So when you go with this mentality of a box, honestly, it takes -- my experience -- about 14 months until things start to not go so well. Or even if they're going well, they are not improving. You're actually not reaping the benefits of having a couple hundred people working on a thing. That's because people tend to be prescriptive; they tend to think that the recipe is going to fix your problem. One of the Amazon reviews that we got to the title of that somebody wrote there, "these guys are fearless" then he said, "because they pretty much said things that people think they know but they will never say in public." What we did is draw from our experience from us both dealing with this thing that people go doing things expecting to follow a recipe and then things don't work. That's another reason why you have to have professional coaches and you have to have not only professional coaches but also technical coaches. You have to have a lot of this because it's when people start to have questions, and they don't know where to go, the prescription doesn't tell you that. The prescription is not there everyday to say, "Well, we are having a quality problem in there and our developers don't know this and this and that. So where's the technical coach there?" or we have personal problems with people who are unsure they're even going to have a job with all this changes that we're gonna get. Where are the coaches in there? So I fear this box solution. It's like asking people to wear the same size of clothing. It's not gonna work, right? So, G want to add anything?

Gereon Hermkes   Yeah. So I personally think that if you have an overly prescriptive system for Agility or for scaling Agility, you're not being Agile at all. It goes against the core value of it and I, frankly, don't care for it.  I'm a deep believer in decentralizing decision making. I'm a deep believer in Agility, because I think it's mandated by environmental changes, right? So if I lived in the Middle Ages, and nothing changes that much, and we live in a feudal system, you don't need Agility, right? It's very specific to our time and to our way of working, which is knowledge work. So these prescriptive systems, they don't really make sense to me. I'm all about Agility. That's what I love and that's what I think makes sense. So doing agility with a prescriptive system is a contradiction in terms to me.

Alex Kudinov   It's funny. I can totally see Gereon saying in his quiet German demeanor. "You're not Agile at all."

Gereon Hermkes   They're not! NO!  They're not! The truth is they are paying for people's cars. Right? So, yeah.

Luiz Quintela   He tends to be a lot nicer than I am when I say something.

Cherie Silas   I can hear it coming out completely differently between the two of you.

Alex Kudinov   So while we are on the culinary trip -- culinary Scrum trip interesting -- so what is your guys' recipe for that fearlessness in your work?

Luiz Quintela   I don't know if there is a recipe. I think it's just after 15 years of Scrum and 30 years of software, I think you just learn that you have to be fair with people but you have to be very precise. I don't like to waste time. I think time is very precious and it's very costly. So I will report to leadership what I see and the way I see it; I am not gonna use fancy words. I'm not gonna say "Hey, let's beat around the bush with this." I think my recipe is I'm a very honest and frank person. I've always been my whole life. One of the scrum values is courage. If you don't have the courage to come forward and tell people the truth. Yeah. Okay, so you want to fire me because I told you the truth, that's fine. Your problem is not going to be solved because you heard something you didn't want to hear. So that's the way I go about it. I tell things for what they are. I tell things as I see them. In my experience, I may be wrong at times, and at times I've been, you know, we all are, but I don't like to pretend that something is a little better than what it is just because it makes leadership feel better. In the end, that's gonna make you spend a lot of money, you're gonna make a lot of people unhappy, and your product is not going to get any better, your stock price is gonna go down, and unless you go to Reddit and ask people to go buy your stock like crazy to pump the price up, I think being honest and having the courage to be honest, I think, a lot of us were very timid. I prefer to be very frank, very honest, and very direct because there is there's no point in trying to pretend that something is not happening because a leadership is going to be happy about this, and I save my skin, right? But you're not solving the problem and eventually, something is going to happen. "Well, why didn't you tell me that?" So I've always been very direct, I got in trouble for being direct, multiple times but analyzing that I say, "You know what? I'd rather not be working there anyway." So G?

Gereon Hermkes   Yeah so for me, it's this issue of being good with the outcome, whatever it is, right. So kind of like being in general less...being like, in a sense, egoless, right? Of course, I have some aspirations or some hopes for what they are going to do but I can't really influence that. I can help them, I can mirror stuff to them, I can support them but in the end, it's their company, it's their decision to make, it's their life, and I'm there to support them but in the end, I'm good with any outcome.

Alex Kudinov   So with you guys, the book is out of the way. It's kind of...its history, it's out there. It seems like you're getting pretty good reviews. What's next for you?

Gereon Hermkes   So we're gonna have the audiobook coming out pretty soon. So that's going to be a nice addition for those who want to learn more about Scrum at Scale but don't necessarily want to read the whole book, but want to listen to it on the subway or on the car commute. For me, I'm very happy. I'm working with a customer where pretty much everybody from top leadership to the employees is completely bought in and so we're doing a full Scrum at Scale transformation in a hardware producing company with a lot of regulatory complications. So it's super interesting. That's it for me if anybody wants to reach me, I'm at tflow.net and Q. What about you?

Luiz Quintela   Well, one thing that's very near and dear to me besides the book, I mean, we did the podcast, the audio book is coming. You can find the podcast in places where you find your normal podcasts. It has a little bit from each one of the chapters of the book. I'm very fond of the coaching sessions we do every month. We are on the third year together doing this. We had hundreds of people in there. We get a lot of good feedback. I learned a lot doing them. We get questions that we'd never imagined somebody would ask, which makes us better trainers, better mentors, better coaches. You can find me at raskere.com. If you look under Resources in there, you can see all the coaching sessions. They happen every month; they are free. We've been doing this, like I said, for three years. We've helped a lot of people and I'm very proud of the work that both of us have been doing with that. I hope we'll be doing it for a long time. Beyond that, I don't know. I have a few ideas. Gereon and I are always talking about stuff. So stay tuned.

Alex Kudinov   We definitely wish you a lot of luck, great success, and hopefully you will continue talking and there will be a lot of great ideas that you will bring to life and whatever that results in, I'm definitely looking forward to it. Well, that was another episode of Tandem Coaching Academy's Keeping Agile Coaching Non-Denominational podcast. We had Q and Gereon today and we talked about Scrumming at Scale. We are your hosts today Cherie Silas and I, Alex Kudinov. Bye now.

About Episode Guest

Want to Learn More About Professional Coaching?

Explore Our Professional Coach Training Programs - parts of The Coaching Path®

Other Episodes