In today’s episode of the Agile Coaches’ Corner podcast, Dan Neumann is joined by his co-host and colleague, Sam Falco. They are joined by special guest, Gene Gendel—an agile coach, trainer and organizational design agent. He is a proud member of the Scrum Alliance Certified Enterprise Coaches (CEC) and is certified in agile leadership (CAL), Large Scale Scrum (CLP-LeSS), and Scrum@Scale (S@S). Gene’s focus is on helping organizations and teams with improving system design and organizational structure and overall efficiency—which he engages in at all organizational levels (senior leadership, mid-level management, teams and individuals).
Today, Dan, Sam and Gene will be exploring the Large Scale Scrum framework also known as LeSS! They’ll be giving an overview of the framework, going over some of the lesser-known aspects, debunking some of the misconceptions around it, and highlighting the types of organizations and organizational challenges it is best suited to address. Gene also provides many key insights and tips for the framework.
Transcript [This transcript is auto-generated and not completely accurate in its depiction of the English language or rules of grammar]
Intro [00:02]: Welcome to Agile Coaches’ Corner by AgileThought, the podcast for practitioners, man leaders seeking advice to refine the way they work and pave the path to better outcomes.
Dan Neumann [00:11]: Welcome to the Agile Coaches’ Corner. I’m Dan Neumann and today I’m joined by Sam Falco and a guest from outside our organization, Gene Gendel, who when we were talking about titles to use, um, we came up with organizational waste manager like driving around in the little green truck. Thanks for joining Gene.
Gene Gendel [00:32]: No thank you. Thank you for having me. And that’s probably like I mentioned, this is probably the worst thing, not not the worst thing. People call me behind my back so I’ll go with the waste manager?
Dan Neumann [00:44]: Have you been called worst Sam?
Sam Falco [00:46]: Oh, I’ve been called worst today.
Dan Neumann [00:49]: Maybe before we clicked record. So we’re going to be exploring LeSS today and probably dabbling a little bit in leSS huge. There’ve been a few episodes on scaling topics. There was a one that touched on some beliefs about safe that were busted during the training. And we’ve talked about Scrum at scale and so today we’re going to be exploring LeSS. So maybe for folks who, who aren’t familiar with LeSS, can you give us a little bit of a, an overview of that Gene?
Gene Gendel [01:24]: LeSS, which is a, an abbreviation for a large scale Scrum is Scrum. So I think I’m done guys. No, I’m just kidding.
Dan Neumann [01:32]: Thank you for joining us. What have you been reading lately?
Gene Gendel [01:36]: So, yeah. Okay, so large scale Scrum. Uh, first of all, historically it was initially called LSS. Um, as in large scale Scrum, the, the small letter “e” was introduced there just to rhyme with the fact that LeSS is more and that’s why we like, uh, you know, the, the, the, the name, the name, uh, abbreviation LeSS so large scale Scrum. First and foremost is Scrum. And I wasn’t joking when I said this, people who understand Scrum, basic Scrum, um, by one team, uh, working for the same Product Owner on this, out of the same backlog, on the same product, they will understand LeSS people that did not, that did not understand Scrum will have a lot of challenges understanding LeSS. So now LeSS is, um, not, uh, multiple teams doing their own independent Scrum. This is in fact something that we refer to as copy paste Scrum, uh, like a bunch of ad hawk teams doing their own thing. And the actual, the term, the term copy page, I think it was introduced by the gentleman, um, Sisera Rameau, if I’m not mistaken, and I apologize if I’ve got his name incorrectly. One of our LeSS, uh, colleagues, uh, so LeSS is in fact, uh, multiple teams working in the same Scrum for the same Product Owner on the same, a wider defined product. Obviously in a very customer centric way on the same cadence. So I think of a horse carriage of six horses carrying the same horse carriage. Um, that would be the LeSS versus, you know, six or seven jockeys, um, riding their own horses in different directions. Maybe I’m trying to beat each other to the punch. So the, for my, his analogy of last, the latter is not okay. So that’s in a nutshell. But of course LeSS is also an organizational design framework. And, um, incorrectly many people think of large scale Scrum, a large scale Scrum as a way to scale up, make things more complex, uh, make things, uh, more convoluted, bigger. Um, it’s not true. In fact, large-scale Scrum is often referred to as at these scale in framework, uh, because it effectively requires removal over organizational overhead Moda, which is mud in Japanese mud waste. Jeez. In order to scale up agility. So in order to scale up Scrum, uh, you have to remove a bunch of stuff that sits in between, uh, and, and creates a lot of residual drag, residual pull back and it comes in the form of roles, processes, um, you know, internal organizational dynamics that challenge agility, um, and make agility and adapt in this impossible, at least very hindered. Okay. That’s in a nutshell.
Sam Falco [04:44]: Okay. I have a question about that. Um, so typically when we introduce agility of whatever flavor into an organization, you get a lot of fear from the people in that middle layer that are not quite sure what’s my role going to be. And if LeSS is a de-scaling framework and aims to look for waste, does that generate more or LeSS resistance than, than some other ways of going about introducing agility?
Gene Gendel [05:15]: Um, so that’s a good question. So I’m going to refer to Larman’s laws of organizational behavior. And of course this isn’t a bad, um, you know, so we can probably spend quite a bit of time discussing, um, the history of the LeSS and of course the co-creators of it, but Bas Vodde and Craig Larman, but I’m going to specifically refer to you Larman’s laws of organizational behavior and there are five of them effectively. And uh, what they’re all about is, uh, exactly what you just described Sam. Um, mid and first level management oftentimes is in general very resistant to anything that is, um, a revolutionary, um, do anything that is, um, bringing, bringing about change or uncertainty. In fact, the, if I were to paraphrase what, uh, Larman’s law says, um, organizations or local optic implicitly optimize to protect status quo of a first and middle level manager. And of course, anything that us as you know, um, organizational change agents bring around would be considered as purist theoretical, revolutionary, religious, et cetera, yada, yada, yada. So of course in large scale Scrum, uh, where we, um, do a challenge exist in organizational design and organization complexity. Uh, we do, uh, often get a pushback from the what’s called the frozen middle, uh, that interim middle layer of individuals that may potentially feel, okay, well what am I going to do? Um, if my organization becomes flatter and simpler and thinner and leader, um, I guess too much stuff will be exposed, I guess too much bureaucracy and overhead and complexity will be exposed. And of course, for someone who, um, you know, who is local optimized to produce this, um, uh, I would call it organizational, um, on unnecessary complexity would feel challenged and perhaps, uh, uncomfortable, so LeSS isn’t, uh, while broadened, um, um, broad and shallow one big bank, um, approach or a framework that will just change your organization. And a very superficial, very, um, you know, very, uh, peripheral way LeSS, uh, LeSS is a deepened narrow, uh, LeSS framework. Uh, is, is, is, is meant for deep and narrow organizational changes that take months, sometimes years to, to succeed. So we don’t look for big bangs, we don’t look for organizational flips. We don’t look for, um, you know, um, early, early successes that we can, uh, you know, uh, communicate and, and, and, and do Bravada, uh, about, um, to the entire world. In fact, LeSS adoptions are not meant to be overly widespread, uh, at the moment they are meant to be selective, uh, and only, um, uh, those companies that are really, uh, looking for meaningful, deep systemic organizational improvements. And usually those are the companies that, um, have what’s called the sense of urgency. Okay. If a company just wants to check the box, uh, or if whoever drives the internal organization transformation is just for another, um, you know, project management fad or, or, you know, involved in a box checking exercise to get to the next level and, and, and, and be put, put themselves in the spotlight, LeSS isn’t for them. At the same time. If you are serious about changes and you want to improve systemically, LeSS would be an amazing way to do so.
Dan Neumann [09:04]: You’d mentioned the, uh, the analogy of horses pulling wagons and so I want to kind of see if I can kind of use that as the bridge for the next question. So, you know, scaling with LeSS isn’t about getting a bunch of different wagons all headed the same direction with their own horses. It really is about getting kind of all the horses pulling in the same direction. And I was curious what types of organizational challenge to see you see LeSS fitting in particularly well, so within that context of we need to get many teams working in the same direction to deliver on a product or a project or a, a significant capability. Um, are there particular organizations or challenges that are best suited to applying LeSS? Um, you know, when you talk about the, the coordinated Sprint planning, coordinated Sprint reviews, uh, coordinated overall retrospectives, those types of things.
Gene Gendel [10:03]: Sure. Uh, so in my experience, um, and I spend quite a bit of time in Fintech in um, uh, with insurance companies, uh, uh, also with product companies and service companies. Uh, I’m going, I’m not going to delineate, delineate too much between different types of industry, although it is a fair say that in Fintech and investment bank and perhaps, uh, in the financial sector, um, usually in general, uh, making any kind of changes is more challenging, more difficult than elsewhere, not necessarily impossible, but it’s somewhere more challenging, more difficult. However, uh, it is really more about types of type of people that are involved in type of type of products that are, um, uh, involve because, uh, in order for a LeSS, um, um, uh, in, in order for LeSS product group to be properly formed, we need to properly define the product. Now this is a very important exercise that has to be done carefully and methodically and with care. So if we define a product, uh, wisely, properly in a customer centric way, and if we are able to, um, I either identify an internal user, uh, if it’s an internal development or a true external customer, and if we’re able to identify, um, a real product on and not a fake Product Owner, not a surrogate, not a proxy, not a, you know, semi quasi empowered BA, if we’re able to do that, then, uh, we will be much more successful. Um, um, adopting a large scale Scrum. Now, uh, it isn’t something that happens overnight. So a good large adoption, large scale Scrum adoption requires a lot of prep work and it usually takes a couple of months. It requires taking a very, you know, very, um, very close look and very, um, uh, what’s the, I’m looking for the word when you are not merciful, not, not a merciful stab at the existing organizational blueprint. So you really need to take an organizational chart and scrutinize it, um, a lot when you, when you, uh, when you’re, uh, trying to go about and uh, and adapt LeSS because existing organizational structures may not be supportive of those dynamics that expected of large scale Scrum. And although I would argue even for basic Scrum, uh, organizational design dynamics, existing, uh, or design dynamics could be challenging in large scale Scrum, things become even more obvious and problems get amplified. So it’s not a really, it’s not no longer a linear dependencies. It’s a super linear dependency because we really, you know, so we go from a component central teams to feature central teams with challenge, organizational sphere, spheres of control. We move away from departments and, uh, first-line management in fact, in LeSS, um, managers, uh, optional and oftentimes are not needed, uh, because it’s about self management. It’s about, uh, self designing teams. Um, so there, there’s a lot to do, to consider. So my answer may be probably is a little longer than expected. So it is really not so much a bad the type of organizational, although this is also a fact that it’s more about what are you trying to accomplish by, uh, instituting, uh, LeSS because if it’s just a to relabel existing teams into, um, you know, Scrum teams or, or LeSS teams and by relabeling existing, uh, quasi-fake portfolio into something that as you know, LeSS like it is not going to work. You might as well not use LeSS, you know, we in fact we recommend, please do not scale. Please do not, um, you know, just try to unpack and install something that doesn’t fit you do something else.
Sam Falco [14:09]: So it’s interesting to me because as you said at the beginning, you know LeSS is Scrum. Okay, now we’re done. Uh, and what you’re talking about, uh, with the way LeSS highlights organizational problems and asks you to solve them at all, these could come out of a book on Scrum itself. So I’m wondering what does LeSS add to then? Uh, how does LeSS help teams coordinate across their, uh, their, their, their boundaries in order to pull together in the same direction?
Gene Gendel [14:39]: Well. Sure. So I’m going to say something about coordination. So in fact, in LeSS, uh, there should be no need for coordination or if there is any coordination, it should be super minimal. Here is why: um, for example, um, in LeSS, uh, we, uh, recommend not to exceed the limit of eight teams. So maybe something I should have mentioned at the beginning, any anywhere between two to eight teams. This is the recommended, um, gap. This is the recommended range of, of, of LeSS product group. That’s the proper term to use up to eight teams. Uh, and by the way, I, if you wish, the basic math, three to nine people per Scrum team multiplied by eight. So we’re looking at roughly at 50, 55 men operation, uh, of developers that constitute, uh, LeSS, uh, product group. Now, the point a, what does really LeSS bring to the table? Uh, I mean, first of all, about coordination, I’m sorry about dependency and coordination. Since there was so much transparency and so much visibility and so much ad hoc and informal, uh, communication between various teams and the different channels and different events that we Institute in LeSS in fact there was very minimalistic add on to basic Scrum. There was almost no additional need to coordinate outside of those events. Like for example, every LeSS, every team in LeSS product group is almost a clone of another team. Now there could be some degree of, uh, there could be some differences in, in levels of um, expertise and domain knowledge in, in certain, in certain areas. But it’s still, um, relatively minimal. Every team in a LeSS product group should be able to work out of the same backlog and take any work item and complete it from soup to nuts from, from to do to done in a Sprint and there when we go, uh, when LeSS teams go to spring planning and product back and refinement sessions, uh, there was some, um, on On-Point onsite communication, I actually don’t like the word coordination right then and there just because everyone does so many things together as opposed to separately the need for additional excessive coordination, um, really is trivial. If, if any would that was certainly do not expect additional coordinators or orchestrators or manipulators or whichever you want to call them to run in between teams and, and do coordination and additional management or of any sort in of course Scrum Masters are not for that either. They have a very specific and very full time-ish responsibility unLeSS, which is the whole different conversation which we can entertain as well. Yeah, of course.
Dan Neumann [17:33]: Yeah. One of the things, a different scaling framework, but one of the things that I saw particularly valuable in it was when the team members all got together for planning because um, it allowed for so many different channels to emerge. It allowed for relationships to be built in addition to the actual planning that went on. And so the act of getting many teams together kind of all pulling in the same direction was super valuable and kind of goes against some of the efficiency mindset that traditional, um, management structures might, might find valuable or they say, Oh, let’s have coordinators and let’s have representatives and let’s have proxies and they’ll do the coordination. So we don’t have so many people in that activity. But a multi-team planning with lots of representation from the individual teams is something I would imagine in LeSS is also extremely valuable.
Gene Gendel [18:31]: And in fact, let me just add something and then just write them what you just said. So coordination and, uh, unnecessary, uh, almost mandatory um, you know, uh, synchronization, we strongly discouraged and LeSS so. Uh, we have a very secret tool in LeSS it’s called just talk and people, you know, I’ve probably encouraged to speak to one another. And there was a, there was an extreme, uh, uh, version of that and it’s called just scream. So if you really need to communicate with someone, you can do that. Uh, we actually do discourage, uh, so we, we, we say you use Scrum of Scrums for as an example, a very old, a very well known, um, approach or, or a method to coordinate. Uh, we don’t say do not ever use it, but we say use it very mindful and try not to use it if you don’t have to because this additional orchestration between the Scrum Masters could be very, um, um, unnecessary if teams are properly involved, engaged in, um, our crossed multi-team events. Okay. So for instance, we don’t recommend, we strongly discourage, in fact, let me rephrase that. LeSS rules will, will quiche against having, um, as, uh, every team, uh, and individual Product Owner because that defeats the whole purpose. That’s how you create this fractal. Fractal isn’t right. And you have a Scrum of Scrums and Scrum of Scrum, of Scrums and Scrum, of Scrum, of Scrum, of Scrums. And now you end up with this, you know, uh, very archaic, uh, organizational communication structure. And as we know, uh, you know, companies tend to produce, uh, uh, products and services that are as complex as their communication structures right as Conway’s law. So we actually try to stay away from that in fact, in LeSS we also, um, uh, have the concept of, of, of um, uh, of a, attache or a representative, but it’s usually not a Scrum Master. In fact, I’m going to rephrase. It is never a Scrum Master. Like for instance, for an overall product backup refinement session or for, um, a Sprint planning that requires of each team we send off one, maybe two, uh, uh, hands-on developers. The Scrum Master’s role is not to coordinate, is not to uh, you know, be a delegate of a team, uh, towards another team, that’s just a bad misconception. In fact. And that’s something I wanted to mention in large scale Scrum. A Scrum Master is a full time role considered as a job. If a company implements LeSS, they should be prepared to go to HR and, and make sure that a Scrum Master is entered in the database as a, as a role on par with any other role. And in, in large scale Scrum, a Scrum Master may potentially handle between one to three teams with focus changing from, uh, teams and product ownership onto through organizational design and development practices over time. But it’s a full time job which will consume that person from, from head to toe. And this person isn’t someone who will be actually doing development. Unlike in basic Scrum, sometimes we see this pattern, so in LeSS, um, those people are coachers, are very senior, very experienced Scrum Masters and uh, we cannot allow anyone to trivialize this because then we end up with just very bad anti-patterns.
Sam Falco [22:03]: Yeah, I a I agree. It’s interesting you were talking about that idea of, you know, Scrum Masters not delegates for the team. And I remember the first time I was in any sort of scaled environment wasn’t any particular framework, but it was, Oh, we’re going on this thing called the Scrum of Scrums, so you’re the Scrum Master, you go talk to the other Scrum Masters about what your team is doing, uh, and if there’s any dependencies you figured out. Now I had some technical chops, but I was not that deeply involved. And so sometimes it was a bunch of people talking about well my team’s got problems, but we have no idea how to solve it. And we ended up having to go bring everybody together anyway. Um, and that caused some angst among the leadership that wondered why, why were we now having all of these extra meetings.
Gene Gendel [22:47]: So let me, I’m going to probably unpack a very, very toxic can of worms here, but I would be disservicing you guys and it will be the servicing the, the, your future listeners as well as we’ll be with the disservice to myself if I, if I didn’t say this. Uh, no matter how pretty something looks on paper, the implementation aspect of uh, the implementation aspect of it could be very different. This is what happens in real life when we, um, allow locally optimized people to step into poorly defined or inefficient in effective defined roles. More often than not. What I have seen is, and this is the scenario, the scenario you just described used to be first line, maybe second line project managers often misplaced because of agile changes find their way into a Scrum Master role. And needless to say, I’ve seen some ones with great, uh, capabilities and proper mindset as we call it. But I would say there were fewer of those. Typically you have very conventional people, very conventional PMs jumping on this Scrum Master role because that’s the only thing they can think of in Scrum and agile. And that’s why they end up doing the same exact thing they used the, they equipped their knowledge that they’re knowledgeable about, they have knowledge about coordination, orchestration, taking ownership. Uh, oftentimes, oftentimes they get sucked into, um, administrative or rally or version one or VSTS admin people. That’s how we see those poor guys or gals, uh, responsible for moving tickets. Updating statuses, total misconception and a flip side of is with Product Owners. Poorly defined structures will end up having a BAs or you know, some senior BA being drafted into a role of a Product Owner, but it’s really not a product on it. So some sort of surrogate Proxy who is not empowered, who’s got maybe understand some business but definitely is not someone who can set strategy and vision and mission. So those uh, the longer, you know, maybe my longer version to describe some of the dysfunctions that may happen, we may see if those roles are weakly defined or loosely defined.
Dan Neumann [25:24]: That’s one of the challenges that I see Scrum teams run into. Like you’d mentioned, we have Scrum Master Product Owner, development teams, self organizing development team, what do project managers do? And one of the activities that I’ve used in the past has been putting up four flip charts, one for each of the Scrum roles and then one for kind of managers or project managers or whatever the other role is. And then we go through an activity of taking all the stuff that has to happen to deliver one thing per sticky note and then distributing it amongst those charts. And some goes to development team, some goes to PM, some goes, I’m sorry, some goes Scrum Master, Product Owner. And some of it is for managers truly. And I liked the way the LeSS website talks about managers as capacity builders. They’re not task managers. And so I liked, I liked that, that notion there. Yeah, please.
Gene Gendel [26:17]: Yeah, I was going to say I was gonna, uh, resonated well with me. The the game or the exercise that you just described, I played it quite a bit as well. Even within basic Scrum, just to illustrate to people, Hey, those are the stickies, you know, let’s see how many actually end up in the project manager’s queue. And you end up having very few. And maybe there are some activities like, you know, uh, maybe getting, you know, hardware or in fact, I, I hate to say this, you end up having some, uh, rather administrative things, uh, that may potentially be given to someone else other than the team, a Scrum Master or a Product Owner. But those are trivial, right? In a large scale Scrum, you’re like you said, we expect these people, if they are, if they stick around, we expect them to be capability builders and, uh, those individuals that would be, uh, that would be also responsible for changing organizational settings to enable LeSS, to enable a large scale Scrum. What does it mean? Well, maybe you need to go ahead and close that site that is 5,000 miles away and it’s not really supportive of, um, you know, uh, LeSS work. Or maybe you should go and buy 5,000, um, you know, new computers or you know, 10, 10 new servers, those things could be their manager or maybe go to HR and enforce them to change job requisitions because what they have today isn’t supportive of, uh, Scrum dynamics or he’s not supportive. It’s not supportive of agility. So those are potential leftovers for people to do. For a second line manager. Of course, when we talked about senior managers, uh, that could be some different responsibilities they have.
Sam Falco [27:56]: So we’ve been talking a lot about roles. I would like to talk a little bit about the work in, in LeSS so, and correct me if I’m wrong, because I may have misunderstood something I read a while back that LeSS introduces a concept called undone work that is, that is tracked. And I know from my Scrum experience, we talk very much about getting to done and not having undone work. And so can you correct my ignorance and fill me in on what undone work means in an intellect context?
Gene Gendel [28:25]: By all means. So, first of all, the undone work or sometimes we refer to it in a funny way as an undone department is an unfortunate, it’s the unnecessary evil. We often are stuck with, uh, you’re in an initial steps of LeSS adoption. It’s more specifically, uh, so you know, obviously, you know, we, we know what a definition of right and definition of done is. So let me, let’s take a look at definition of done the tail end of sprint, uh, working agreements, right? So definition of that is what a team Q literally decides, uh, defines doneness of, um, a feature or a group of features since they work on multiple features, um, backlog items. Now, uh, it would be obviously inclusive of acceptance criteria and many other things that a team decides for themselves. They need to include, uh, test integration, uh, test automation, um, production deployment, anything that they are capable of including in doneness at the moment. Now, anything that prevents them from actually going to production, the delta between definition of done and production deployment remains to be undone. So this is an unfortunate, this is what we call a necessary evil. At the beginning. So the goal of large scale Scrum is to gradually and hopefully sooner rather than later, shrink, minimize, nullify, reduce to zero, such undoneness. So undone is not something we are proud of. Not something we are happy about as it’s something, it’s something we often see with teams, um, that are not yet mature. For instance, if they don’t have a test automation yet, if they are not capable of deploying to production than their own, if they need to take, um, to talk to an external group of people to take care of it, that would be undone work. And ultimately over time as sprints progress, um, we want to absorb and while we expand the definition of done we naturally shrink definition of done. So ideally just like in basic, just like in Scrum, we want to be able to go to production, uh, on the last day of our sprint and just by clicking a red button and shipping the code. So that’s really, uh, what, um, what undone work really entails. And of course the different ways to handle it. Um, unfortunately, sometimes, uh, every time we finish a sprint and we’re talking about worst case scenario undone work gets shipped to a undone department and someone else handles this and it gets accumulated over time. Well guess what? Some, so many, so many companies totally misunderstand the notion of DevOps. They think it’s a, it’s a department. No, no, it’s actually developers doing operational work. This is the engineer practice. So we want to suck it back into the definition of done a, another way of doing it due to sprint, sprint, sprint, sprint, sprint and accumulate a bunch of undone work. And then unfortunately, and I’m going to stress, unfortunately, we need to have a hardened sprint or establish, you know, buck fixing sprint. Uh, we do know a new feature development. We just care about getting our, uh, accumulated code shipped to production. So again, this is unnecessary evil. And of course with engineered practices, uh, such as, uh, test room and development except test room development, um, continuous integration. Uh, we are, we are in a much better position to minimize undoneness undoneness to know all the time.
Dan Neumann [32:12]: Yeah. Okay. So I think what you’re describing is it’s not a desirable state. It’s an acknowledgement that just like in kind of quote regular Scrum, as your definition of done matures, there’ll be less and less follow up to do after the increment is completed.
Gene Gendel [32:31]: Correct. That’s an accurate statement. This is not a desirable state. This is unfortunate initial state and Oh, by the way, there’s so many companies that are intoxicated with metrics and, and states of maturity. Well consider definition of done as the best way to, one of the best ways to measure your maturity, right? If you, if your definition of done is so thick and doesn’t change, you’re not changing. It doesn’t matter what metrics you’re going to put in a PowerPoint deck.
Dan Neumann [32:59]: At the end of our episodes, we ask folks what’s on their continuous learning journey. So I very much appreciate that you have, um, educated us and shared perspective and some experience on LeSS. And I’m curious where kind of where you’re a learning these days.
Gene Gendel [33:18]: Uh, so, uh, okay. So my learning, uh, so my reading if you will. So I, I, I’m a continuous learner. I never stopped. And maybe it sounds like a cliche, but I truly do. I mean it kind of feels, I feel guilty if I don’t read something new every day. So at the moment from coming from structured learning perspective at the moment, I’m actually rereading, rereading for the second time, The Green Book, uh, the, the third last book, there are three books. Oh, by the way, we never talked about it, right? So large scale Scrum wasn’t created proactively. Uh, I’m sorry of reactively to meet market demand. And so that, uh, you know, we can meet clients’ needs and you know, make gazillions of dollars. It was very proactive and it has almost a decade of experiments and experiences documented. Uh, and that’s why I mentioned the third book. The first book was published in 2008. So I’m reading the book because I need to polish up a few things, uh, for my personal needs. I will be speaking to the, to the cofounders of LeSS and there will be probably immensing myself even deeper into structured uh, LeSS training. And for that I need to know almost, you know, and just more for consistency of my language, uh, more so than, uh, for anything else. It’s just we are, we are very, very lean and very peculiar with terminology. We don’t like overloaded terminology. We don’t steal from anyone else, but we like keeping our terminology very lean. And the second book is by Taiichi Ohno, uh, Workplace Management. Um, it’s written more as a memoir. It’s more of a like notes by Taiichi Ohno, someone interviewing the guy. So it’s kinda, it’s a course read. So it’s a little you know, challenging to digest. But it’s very useful because it’s coming as it’s very authentic. The guy who, you know, the forefather of TPS have, they’ve got a production system. Um, and of course I also love Kanban and understand Kanban well and these guys is a great person to learn from. So those are my two main sources.
Dan Neumann [35:22]: Outstanding. And that reminds me, Sam, you mentioned reading the Scrum guide on a pretty regular basis. I forget your cadence and maybe you could expand on that cause that resonated with what Gene was describing.
Sam Falco [35:33]: I read the Scrum Guide roughly once a month. I spend a lot of time on planes, so I will frequently pull up before I get, uh, you know, and go through it. Um, I, that’s the cover to cover read. And of course I spot check my understanding and knowledge of it frequently. Oh, I need to speak or coach on a particular issue to make sure that I have it, have it fresh in my mind so that I don’t miss quote it because our brains do odd things to texts that we think we know. So about once a month I hit it cover to cover so that I make sure that, and I always come away with, Oh, Hey, there’s something I didn’t notice before.
Dan Neumann [36:12]: And I just, you know, it’s, we’re not a political thing, but it reminds me that Biden might want to go watch his John Wayne movies if he’s going to quote them. I don’t know how timely or how sticky that will be by the time this is released. But, uh, you know, it’s important to really understand the things you’re quoting, whether it’s LeSS or Scrum or John Wayne movies. So on that note, thank you for joining Gene, Sam, always fun to do the collaboration. I appreciate it very much.
Gene Gendel [36:42]: Thank you very much, Dan. Sam, thank you for having me here. Hopefully I did not introduce any additional confusion. I think it was a very conversational event and, uh, I really enjoyed it. Thank you for having me here.
Outro [36:58]: This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. The views, opinions, and information expressed in this podcast are solely those of the hosts and the guests and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips from this episode and other episodes at agilethought.com/podcast.
Contact us to share the challenges you’re facing and learn more about the solutions we offer to help you achieve your goals. Our job is to solve your problems with expertly crafted software solutions and real world training.
For a better experience on the web, please upgrade to a modern browser.