AA175 - Why You Need to Make Space Learn: Cognitive Load in Agile Software Development

welcome to the Arguing Agile Podcast, where Enterprise Business Agility Coach Om Patel and Product Manager Brian Orlando argue about product management, leadership, and business agility, so you don't have to. In this episode, Om and , I are going to be discussing the term cognitive load. Anybody in the agile space understands the term cognitive load. Here is the original paper. That coined the term cognitive load. The title of the paper is called Cognitive Load During Problem Solving Effects on Learning by John Sweller from the University of New South Wales. Australia. Not to be confused with the University of Old South Wales, but this is the paper the paper's honestly relatively short is the 29 pages total, including the title page and the references pages. It reads pretty quick. For the purposes of this podcast. We're going to use the conclusion section to start our discussion. Because the purpose of the paper is to suggest that contrary to current practice, many cognitive theories, some forms of problem solving interfere with learning. And since knowledge work is essentially all problem solving, the challenge presented in this paper, where you can derive the challenge to our line of work is, While you're trying to solve the workday problems of the business that is inherently interfering with the process of learning. So let's see if we can find a better, while we're still on the internet, so we'll, I think, I think we all agree. We can use Wikipedia as a reference. You're, you're welcome. School teachers all around the world. in cognitive psychology, cognitive load refers to the amount of working memory resources used. Cognitive load theory was developed in the late 80s out of a study of problem solving by John Sweller, which is the paper we're reading right now. Sweller argued that instructional design can be used to reduce cognitive load in learners. the reason I thought this would be an interesting topic for us is because you hear about cognitive load. On development teams a lot so the team has to manage the environment, especially small businesses, right? The team has to manage the environment. The team has to manage the changes. The team has to do feature development. The team has to do support work. they have to be involved in discovery. They have to do their own UI UX. They have to think about architecture and systems view, et cetera, et cetera. Everything on the previous podcast that we talked about for product managers being overloaded and having to do all these additional tasks. All this is cognitive load theory that it goes back to. Yeah. So I think one of the things to recognize is this isn't new. Obviously you see that from the paper, right? This was known back in the eighties. But I think people are now starting to relate that to really knowledge work and say it's having a real impact. It's not just theory. This actually has a real impact on the work that we do. Yeah. Let's go to the paper and kick off this podcast. Bam. There it is. All right. So we're on the paper. we're going to hit the conclusions of the paper. 1988, by the way, this paper. He lays out five claims in the conclusion. let's start with number one and then we'll go down this list. Okay, so number one. He says, both experimental evidence and theoretical analysis suggest, What we think and what we observe. That's right. That conventional problem solving through means ends analysis may impose a heavy cognitive load. So means ends analysis. So if I'm going to give a like 10 second description of means ends analysis, like there's whole videos you can go watch on YouTube about means ends analysis. Trust me. I watched them all. They're really bad. I will tell you right now, not surprising means ends analysis basically the process of saying, Hey, this is our goal for the development team. And I'm going to write down our goal in the form of an epic. And the team will come in and write a bunch of stories that fill up that quote bucket of the epic until we achieve the goal that the epic was shooting for that the process that does that is means ends analysis. So it's basically breaking down an objective or something like that into actionable pieces as agilists know, you know how to do right. Epics feature stories, now, sometimes like in the, if you read this full paper again, it's only 20 some pages. So I encourage you to just read the whole paper. He has several diagrams and whatnot that says like, well, you'll start breaking down the work and you won't know what the goal in mind is. So there's a different process for that. And he has flow charts and he has diagrams and he has the red strings and the conspiracy diagram. But basically he's saying if you don't know the goal, you have to get through all the work to find your way to the goal and the sub goals to be able to reach the goal. But there's a whole process to go through, but that the claim, I have to go back to the claim. The claim is the traditional methods of doing your means ends analysis imposes a heavy cognitive load. Well, I think that's on the money, right? Obviously, cause you've got this thing that is very nebulous at best. And then you're asking the teams to break down the work and still maintain integrity with that objective. And as they're breaking down the work and they get further and further away from that stated objective, they may or may not. Be in line with what was originally intended by that objective. Yeah. So the cognitive load is always going to be there thinking, are we on are we actually fulfilling that or not? See the way that I read this was if you're actually trying to code things while doing discovery work at the same time that will enact a heavy burden you will move much slower. Because you're not clear about what you're trying to build. I think about the world of the 2000 software development where all the specs were delivered and developers wanted to go sit in their little cubes in the dark by themselves and not be disturbed for weeks on weeks at a time without delivering anything. if you are like the opposite of that it's like you're building something as the customer is using it and changing and learning. I think that's the kind of world that he's. Shining a light on Just in time. Discovery of what's needed. that is pretty heavy because you're actually trying to deliver something and yet learning more about what's next or even what the whole thing is all about. It requires more skill and is more difficult than the world where you just handed everything and told to go sit in the corner until it's done. Mhm. And it also means divided focus because you're developing and also trying to do discovery work. Yeah, right. Yeah, I think you're right. So That's his first claim. Is that when you're trying to do both of these at the same time, when trying to problem solve through means ends analysis, it imposes a heavy cognitive load., an example of Problem solving through means ends analysis you know, extracts a heavy cognitive load would be in during sprint planning, like the act of sprint planning, where you're taking the goal and you're breaking the goal into stories, most likely the stories maybe have already been But now you're actually playing your implementation details. So think of it is like creating subtasks from stories in any, any tool, but my particular tool of choice is Jira. I haven't done that in a while. if you're creating subtasks, In that tool, then this is a time where you look through and you plan how you're going to build each thing. Like you're actually opening up database tables, you're opening up pieces of code to look at functions that are there to see if how they would have to change or what particular pieces of code would work. Maybe you're coming up with different deployment strategies and whatnot. You're actually planning the low level work here. So this is like if it's done, right, this is where you're cutting through all the ambiguity. So that when the rest of the sprint begins, it's generally a lot easier to implement the work. I think you're right. So what was the alternative to this before? Oh, the alternative. I know exactly what the alternative is. The alternative is you don't do sprint blending together as a team. I just, I, the architect from the ivory tower, I just assign you the work. And then you have to figure out the architecture. You have to figure out where all the pieces of code are that even interact with this thing you're being asked to change. And you have to figure out how these are using it. And you have to figure out all this stuff. maybe nobody even writes the story for you. Maybe you have to write the story itself. Yeah, absolutely. And then you have to document it down and maybe you got to do your own documentation while doing your own stunts maybe you have to do it all. You know, maybe you're in one of these shops that say we see no value in a scrum master and why can't the product owner do all the B. A. tasks and why can't development do more? Right, right, right. Yeah, these are the sorts of organizations that basically hand you a P. R. D. and say all the analysis has already been done. Yeah your tech lead took care of it all. That's right. Just go code. Yeah. Don't come out until you have something that works. So that's not a good alternative, first of all. We just want to contrast that with what this cognitive load topic is. Alright, let's look at number two here. So, cutting back over to the document. Conclusion number two. The mechanisms required for problem solving and schema acquisition may be substantially distinct. Schema acquisition in this context is learning new methods of working or new talents or new skills, new ways to approach and deal with problems. This is a good point to stop in the podcast to point out if you read the paper, some of the examples in the paper where he's inflicting cognitive, cognitive load on, on his, on his Test subjects who I think are like high schoolers, basically like 15, 16 year olds are taking math tests basically. During the math tests they not only do I have to get the right answer, but they have to identify and use the proper formula or schema, right? That's his academic term for it. They have to identify the correct schema to use to solve the problem. then they have to actually solve the problem and they have to come to the correct. So if you read the paper, the paper is actually interesting because he gives like a mathematical breakdown of the load that was applied and how difficult it was and when they came to the right answers and when they had the right schema, but they came to the wrong answers and all kinds of stuff like that. So in our day to day life, the word schema might be replaced with patterns learned by experience. Yes. So an experienced developer would recognize. Something they come across as Oh, well, I've seen this before. Here's how it was solved. See if that could be applied here that's what I think it is. a pattern also would be the steps you go through to release things to prod. And a pattern also could be when a blow up happens in production for example, all of the devices start blue screening all at once the steps that you take to go through the troubleshooting, to bring things back up,, the more times you've seen and dealt with that, the better your schema is for recognizing and resolving that. Yeah, exactly. And we're not even going to get into the stress factor that comes in when people are yelling and getting upset that's not even included, in the study. He didn't say anything about that. No, this study is very objective. He doesn't talk about those sorts of things. Very sanitized. Yeah. it doesn't include any of the factors that anyone listening to this podcast will deal with. In their day to day work with egos and personalities and all that kind of stuff. You're right. I mean, the work of this paper was really centered around, high school students. So, they didn't really consider all of these You know, there's such a feely type of things. But they're real, right? I mean, Oh, not in the eighties. They weren't real then too. I seem to recall they were real. It just wasn't, we weren't allowed to talk about them. That's anyway, there's a few nuggets. I leave in the editing of the podcast. That's a great, great. Let's see. So the mechanism for required for problem solving and schema acquisition, AKA learning are substantially different. So the skills that you use to solve problems versus the skills that you use to learn things or acquire new patterns to recognize. So where, where else can we apply that? The mental processes, developers use to complete sprint tasks versus the mental processes that they use to engage their systems thinking about architecture or about. Team structure or team topology, right? Like how should we scale? How, what's the best way for us to talk, for teams to talk to each other, to figure out the work between the inter team, the inter team, inter team, I don't, I don't know. Inter team or inter team. Yes. We'll settle on that. Hit us up in the comments. that's a great example of this. the work that you do in sprint, like going from work item to the next work item to the next work item, that skill completely different from that. I'm not making that claim. This paper is making the claim, but I have to agree with the author here. I mean, if you're too busy just doing the work of the sprint, we've all seen this, where teams say it's been a long two weeks. Too busy to improve. We're tired at the end of a long sprint. Can we just skip the retro or if you say no, we have to have it. Can we have a 10 minute retro? I've heard all of that before. Too busy. That's an excuse. We're too busy to have an hour long retro. We got to get back to work. We can cut that into a half an hour retro. Right, exactly. We're too busy. Exactly what we talk about at the retro, right? Yeah. So those skills are different because you have to introspect and you have to see how your processes were suboptimal and where you can improve. Those skill sets are totally different than sitting there, punching out code or testing things or whatever you could be doing so yeah, I mean, I agree with the author. So another claim is that senior developers are more effective. Not because they can complete tasks faster or complete tasks on their own without peering with anyone. They're more effective because they have this deep understanding of the pattern recognition that we were talking about. Oh I know I got to go to production this way. I know that the check in process worked like this. the better way for us to share between teams is to get everyone in the room or whatever to, the better way to resolve issues with customers just to get the customer on the phone. You know, you don't really need to convince them of these things. they already know these things. They've learned it through their experience, right? So it can even be simple things, but they're not so simple. If you don't do them, I guess things like let's get ahead of it. We have a deployment coming. Let's go ahead and start getting on the radar for Our legal, if that's applicable, compliance teams. So developers may not necessarily think of these things. Because their vision is down to the actual problems, right? How to fix this issue or how to develop to a story, right? so yeah, I mean, tech leads, people like architects that have been around the block a bit, they think ahead a bit. They'll say, let's create a story to make sure that we can talk to this other team now, instead of doing it at the end, right? when you gave the examples, those are the two, I thought of two examples immediately, which is, Talking to another team to align work, like in advance of something, Right. And the other one I thought of was, let's start contacting all of our customers now, before the sprint review, to see who's going to be available to make sure that we have at least one, maybe a couple for the work that we're about to get done. And then like the team being well in advance of that, that's cognitive load of, it's not development work. Some people might listen to this and be like, Oh, it's totally development work. But if your claim. is it is different than development work. I agree it is different than development work and it requires a different skill set. And it's equally as important as development work. So yeah, I agree with that. So yeah, that's true. Conclusion number two the mechanisms for acquiring schemas is different than the mechanism for problem solving. the developers completing stories in a sprint is not the same as developers improving their individual expertise or a team. Some kind of team expertise skill. does the team have a skill? Yeah, they do. I mean, collectively, I guess doing the work takes precedence usually, right? Sprint is a finite time box. They got to get stuff done. Meet your sprint goals, whatever else. So that's all they do until the sprint ends. Where is there time for experimenting and learning and innovating? Right. I know some frameworks build that in. But I've yet to see that in practice where it's actually used like that, like a whole sprint for innovation and planning. It tends to be that sprint that tends to get used for regular work, carry over maybe a little planning for the next PI. But no innovation. I have seen not had the fortune to work in these environments, but I have seen some teams where what they do is they just carve out the time and they do this either on a regular schedule. Some companies are better at this than others. I know Google and all these big some of these big FAANG companies. They actually allow their teams to do things like code camps or those kinds of things, right? Hackathons. Hackathons, yeah. So that's where the team learns a lot. They're not under pressure to deliver a product as such. Although, if something useful came out of it, maybe they'll get a little reward or something, right? But they learn a lot through that. Because again, it's different. They're kind of decoupling from the regular sprint work. So if you're not doing that, you definitely are suffering this bullet as it's described here. I'm going to go back to the document because number three and number two are very related. So number two was mechanisms required for problem solving and schema acquisition may be substantially distinct as a number three, as a consequence, the cognitive effort required by conventional problem solving may not assist. In schema acquisition. So the cognitive effort required in conventional problem solving. This is what we were talking about with the work done inside of the normal sprint so that that work may not assist in learning new patterns. This is the interesting thing about this one is the claim here that I feel I can make and be in line with this paper's findings is. I could have a team working on features like adding stories to the sprint, having the team bang through all of them and work for a year with that team. And the team has not improved a single thing. With regard to learning new things, basically learning how to tackle different styles of problems. they've executed on all the things I've asked them to do. But anything that comes up that is outside of the wheelhouse of exactly what I've given them, they've learned no new skills. Unfortunately, the way we're working today exacerbates the problem. So what I mean by that is oftentimes development teams are dispersed. They're offshored. And These people are asked to do the work of the sprint. They're not asked to go learn something new. We don't pay you for that, right? So go develop something, and that's it. When you're done, go develop something else. And unfortunately, that kind of feeds on itself over time. they're looking for experienced people that have these patterns, but at the same time, they're not providing opportunities to gain these patterns. Yeah. Which is quite, quite unique. Very weird. I mean, you say very weird welcome to Arguing Agile. Thanks for coming. Like and subscribe. But I also say this is part of the, the bipolar corporate America over here why train someone when we can just you know, cut you and replace you with it's not half of your salary. You're not getting two people for half you're getting two people for half. 1. 25 times what you're paying the other person. They're actually, they pay more when they replace you, even when they offshore you. Sure. But anyway but yeah, the corporate America is just refusal to train people and to make space in the, either in the velocity or in the budgets or in whatever, 7 months will be 20 years in software development. And , I feel like companies haven't learned a single thing. Like they're still doing the same thing they were doing at the beginning of my career. they're trying to get experienced people at beginner rates. And Work them for two years until all their ideas are terrible. And everyone outside of the organization's ideas are great. And yeah, I don't get this one. It's crazy. That one's crazy. That's a whole podcast. And then some, it really is. so number three, cognitive effort required by conventional problem solving doesn't assist in scheme acquisition. So your normal day to day work doesn't help you learn new things. Even if you're setting sprint goals, even if you have a good product function and you are setting good sprint goals, those sprint goals may never, you may never learn anything from those, you may never acquire any new skill. Basically, that's what I'm saying from those sprinkles. I mean, like think about shops where the sprint goal is like, do all finish all the work items. You know what I mean? Like that kind of stuff, everything in the sprint, everybody's been in a shop like that. Where this the, the, their product function doesn't really function. it's like a tech lead stepping in and playing the product role or as a CTO basically that owns the product owners basically. So they're incented on how many widgets they punch out. so maximum more widgets, the OKR. Are more 10 percent more widgets this year at this time than last year at this time. Like that I've seen real software development shops like that. Absolutely. So I absolutely right. But those developers who are being judged by the number of widgets they deliver, they've learned no new skills. They've not improved their process. You know, they don't have a better understanding of customers or anything by that. they're just punching out widgets faster. Not even necessarily better. And because they've not been given the space to figure out a better way to work. Absolutely agree. So, this item is very similar to the previous, so I feel we're going to spend less time on it. Alright, so moving on to conclusion number four. Since schema acquisition is possibly the most important component of problem solving expertise, again, schema acquisition is learning new things, new patterns, new skills, new whatever is possibly the most important component of problem solving expertise. The development of expertise may be retarded by heavy emphasis on problem solving. So the development of this expertise may honestly may be paralyzed completely by heavy emphasis on problem solving, a heavy emphasis on problem solving, I interpret as a heavy emphasis on knocking out stories and sprint goals and going from focus incessantly on the work of the sprint, right? At the expense of everything else. So where is there? Any slack to build up those patterns and learn those. And I've said this on a previous podcast where I, this is where in my ALM again, it could be whatever ALM, it could be a good ALM and it could be um, but in my ALM, I use components. So every work item has a component. They're kind of like, I guess you can use tags, whatever the Microsoft Azure DevOps has a field for this and you can use tags there too. But basically I will designate a story to say this story is a feature meaning feature development, meaning, capitalized piece of software development that'll be, new and meet some criteria which is a problem solving. Basically it's a, it's a problem to be solved, the feature and also I have a category of capability. Basically the team needs to learn a new skill. So that's what this work item is. This work item is a team learning how to do something else or exploring a new technology or figuring out a Some kind of not not figuring out a problem meaning like solving a bug because there's a different category for that Sure, because that kind of stuff goes on the OPEX. It has to be categorized differently, but I Strongly believe in backlog and spending Part of my velocity or forecast or however you plan spending, spending part of that of those planning dollars, right? We'll call them planning dollars, right? On this, because it, it lets us bake time for exploration, time for alternative approaches. It lets us bake that into the normal planning process. And if it's just baked in the normal planning process, It's a lot easier to manage because all the planning is flattened. So you'll say, sprint velocity is 20 this sprint eight points is on, on these features over here maybe two or three, whatever stories that equal eight, whatever, 10, I don't know, whatever You know, so I got eight points over here for feature development. I got two points over here for this other thing. And the rest of the sprint is, whatever bug fixes. Maybe we have problems. Yeah. I think the field, there are a couple of fields in Azure DevOps. There's a category and then there's a value area. So you could use those, but definitely agree. a lot of times I've seen teams not even use them properly. just default to whatever. So that's just a bad use of the tool itself. But if you're just focused on the work of the sprint and that's going to consume all your time, all your cognitive attention or load, and you've got no space to learn, you've got no space to discuss things. So I lump into this lack of avenues to learn even like lunch and learns or. Communities of practice, right? Who has time for that? Just go code, right? Come on, right? One of the things I like doing is having a weekly call for half an hour and focused around different areas of work. So I might have a product session for product managers, product owners. I had that regularly every week. And the agenda is usually something topical that the teams are struggling with, right? And then there's also, if there's no agenda, then there's just open discussion where people can brainstorm ideas. And some good things came out of that. People brainstorming ideas, Oh, I thought I was the only one thinking about that. I didn't want to say it loud, but now that you mention it, perfect. I mean, half hour a week, you should be able to do that. Same thing with Scrum Masters around process. You know, things like DevOps. I had another session for DevOps, where they can come in and talk about how to improve the practice of delivering, right? So, if you're not doing these things, Things are actively investing time and effort in our learning.. Yeah. I mean, that's, that's, that's the implication here is that the grind of the day to day, that skill is a different skill. Or maybe I, maybe that's the reason that he uses this. Academic sanitized language of schema acquisition you're, you're acquiring a new schema because it's not necessarily just skill. I mean, it's a, it's a little bit skill that you have to go get. It's a little bit pattern recognition that you have to go get. It's a little bit of what we would call experience that very nebulous. It kind of is meaningless to be honest, it's hard to explain. He just labels it schema acquisition. I wonder what Taylor would have called that because there's nobody's business. I mean, management knows everything and they'll just tell you what to do. All you do is do right. Let's just do the work. I don't know what, I don't know what Taylor would have called it. I think you would have called it a. Nonsense. I mean, Taylor would have been so far in the past he would have looked like a caveman compared to this research. Well, sure. It would have been an analysis of his own work. You know, of how he was solving the problems. He wouldn't necessarily see that as negative, though, because for him it wouldn't be cognitive load it would just be, this is what I do. If you invoke the, the old first principles you know, rule where you say, well, let's break the test down to its basic stuff. I think what Taylor would have done is say, why do you have one person doing so many of these separate jobs? They're all separate jobs. Either you have to serialize the jobs and do them all. S serialized. Sure, yeah. Or you have to do all the jobs in parallel and then give them the separate people. So I think, I think from Taylor's perspective, I think it actually would be very simple. He would say. Hey, don't have 87 jobs for one person, have one job for 87 people. And then you can write down the checklist and have your disciplinary walk around and smack people with clipboards. But you know, he would look at it very simplistically, which again, not knocking him he was in that era. Right. Yeah. I mean, but the modern eighties manager, , who's trying to squeeze maximum profits out of people and not, and you know that, which is actually the modern managers, I was gonna say. Yeah, exactly. Hasn't changed since the eighties. They're gonna they're gonna. Load people down to the to the to the max until they can't breathe anymore. Basically. Yeah. Yeah. This also talks to The old waterfall way of working where you just load up people to 100 percent utilization You know, so they have no room to breathe, right? Yeah utilization. utilization is a good point because this If you really take this to heart, his conclusion section the indication here is you need some sort of overhead percentage. Businesses do this with financial metrics for their people. They, they have a overhead when they even when they bring you on and onboard you, they pay you the salary they pay you, but then there's an overhead costs what your benefits and what everything else costs to the company. in product management, for example, when you have resources, certain people are overhead and anyway, it's a normal thing. And so it's surprising to me that there's not already something to figure this out. in order to have this schema acquisition, there should just be an overhead. And then we can negotiate what that overhead is. Sometimes it's slimmer. Sometimes it's a little more or whatever. But generally speaking, there is an overhead percentage you should shoot for. We know it's about fifteen to twenty percent. Somewhere in that region. I mean, I feel like it should almost be a A GL accounting code by itself, right? But you can, you can assign that time to, if you're doing what I was suggesting , you now have evidence to track that stuff back to you. You can say this much time is spent on learning. I'm going to account for that in the sprint. This much time is spent on whatever specific skill development or whatever, I can account for that. You can build it in, but it requires commitment, right? and approval from those that are Hawkeye managers, basically. it does require approval from whoever's doing your books cause, they have to roll the low level stuff from JIRA all the way up to the GL. that is a bit of a task for a typical finance person because they don't really understand. They don't even really know what development does. So it's, it's, it's already an ask. To them. Everything's a GL code. You're right. All right. let's finish out this document number four, we just finished since schema acquisition is possibly the most important component of problem solving expertise, the development of expertise. It may be slowed by heavy emphasis on problem solving. number five the last one, current theories and practice frequently assume problem solving is an effective means of learning and consequently may require modification. So the, the idea. The idea that on the job training, just throw, throw you into the fire. Oh, we're going to throw you into the fire. That's a, that's a great way for you to develop skills. Like he's he's kind of questioning that as a theory. I mean if, if I'm throwing you into the fire, I guess, I guess if I'm going to, if I'm going to argue agile, my own, my own, what I just threw out right there, right. If I'm going to put you on a team, but not expect production from you, And just ask you to take everything in and learn, right? So you don't have, capacity goals or utilization goals or whatever, when you start then you have a little bandwidth to do this. Like what he's, again, if we go back to the mathematics example where he's given the students a bunch of math problems to solve, he's implying that maybe like giving you a bunch of tests and then screaming at you to finish the That you may not learn anything just by failing to do the problems. Sure. So I can relate to our, our day to day, right? So if you're going to throw somebody in a team sink or swim and not expect any output from them, right? Yeah. I mean, they're going to learn what they're going to learn by osmosis, observation, et cetera. But this is talking to, I think, for me, this is also talking to, Doing things like pay programming or mob programming, right? We oftentimes that's frowned upon by management. What do you mean? Why does it take two people to work on that thing? Right. That's like, you're going to get much better output in the long run. You're building quality in whether you realize it or not. And so I think part of that is, is speaking to that as well for me. Yeah. So there's a couple of things in here that are Even 1988, they're still quite radical and even if you just look at the examples he did in the paper Hey, this this may not be the best way to teach people math. Our math level in the country is just plummeting. It probably isn't in retrospect, but also, like exactly what you just said, like pairing, pairing, just like. Pairing a apprentice plumber with a master plumber or several, right? Pairing a junior developer with one or more senior developers day to day. So they're not doing anything by them truly by themselves. The boy corporate America is like XP came out. Well, before the agile man, it did. I'm quite honestly, I'm surprised that the pushback of working like this, cause I would say the majority of places that I've been at it's anathema to think that two developers would sit down together and solve one problem. They would rather one developer knock out some code, even if it's dodgy, and then have somebody catch the errors and fix them Right. And it's actually costing you more in the long run. Right. They just don't know it. So the implication is we should rethink our assumptions of how developers work. Learn if they learn through their daily work, how they take time to learn while doing their daily work. And then whether we should. carve out opportunities for them to learn. Yeah, absolutely. And you know, again it's hard to have this conversation without also pushing back on the general Western corporate American culture of like, Hey man, learn on your own time. You know, that's why we got this training budget that you gotta jump through hoops and write your congressman to request any money from or whatever. Yeah, right. but also like something that is not apparent here is we really have no tools. I mean, there's no Jira while they're coming out with their products to extract maximum amount of dollars from people as a service or whatever, like they're not helping you. Measure how mentally taxing the different types of tasks that you complete during the day. Oh, these are planning tasks, and these are discovery tasks, and these are interviews, and these are people development, and these are one on one, and these are whatever all the switching, and the use of a different skill set to do those different things. Like, how mentally taxed you are if you look at the paper, He puts some weight on the cognitive load of different problems and he measures whether they get the answers right. And it's, it's actually quite interesting. And, the thing to bring back to our line of work is Boy, we just have nothing like that. What there really needs to be is there needs to be an AI that's reading from my email, reading from Slack, reading from Jira and reading from whatever, I don't know, maybe you Git or maybe Jenkins or whatever I don't know, basically your systems for checking and releasing code maybe your bug system or whatever, and kind of assessing a cognitive load value. To your development teams to say like, Hey, this slow down, slow down. Exactly. Slow down to speed up basically like, like a risk level or something like that and say, Hey, this team is not learning. That would be a cool thing to come up with. It doesn't matter what your ALM is. It doesn't matter what your science is, because whatever you're doing, you're using the same method for everybody. So whatever errors you have, wash out it would be cool. It would be really cool to see that. But yeah, actually you probably could do it just with a plugin on your ALM tool. Just start with when you install the plugin, it installs the components to suit the measurement of this stuff, kind of where it's talking about the capabilities, feature development, maintenance, development, bug fixes, whatever, right. Just some capabilities. And then it's up to you to integrate those into your work. So the tool will have to tell you like, Hey here's a report about what has no capabilities assigned away. Maybe you need to do better about assigning them. But once the majority of your work items in the system have this thing assigned, You can start pulling reports to say, Hey, by team and the work items I see completed, I see you guys doing 95% 99 percent feature maintenance work, bug fixes, and I don't see a lot of capabilities in here. I don't see the team being assigned tickets to go improve their skill set. And you might see something like that and say, Oh, well, they could, they're doing that on their own time. Or, Oh, I don't track that in the backlog or, Oh, I don't, you know. But it would be really cool to see it on a report, you know? Well, yeah, I agree. It would be really nice. And you know, it would also arm you with some evidence to go up to leadership with and say, this is needed. Or you could just blindside them and say, no, we're just going to do it anyway. I think the difficulty here is number one, a lack of an overhead. A generally accepted overhead of developers this much time, generally speaking, should be put aside for planning, but that time varies based on the skill sets you already have, right? Yeah, it varies. It's not gonna vary a lot. I think you said earlier somewhere between. pick a number and go with it and then adjust it as you need to. Well, you probably could also adjust that number depending on people's skill levels. when you're junior, maybe you need 30 percent or whatever. When you're way more senior, maybe it falls all the way down to 10%. I don't know. Maybe it changes based on the skill level. Volatility of the business that you're involved in and whether you're a startup in a new field, et cetera, et cetera, there's probably more factors. It'd be real interesting to take this work, apply it specifically to Agile software development, and then do the study again. Yeah, that would be good. So instead of students, you're going to get developers in and yeah, that would be really interesting. So if anybody's listening, you want to take this on. Get in touch and we'll, we'll collaborate on it. And if you're a PhD student, you're looking for a problem. Yes, we have a solution. All right. Well Om, take us away. All right. Well, thank you for staying with us thus far. And let us know what else you'd like us to talk about. Remember, you get these topics only at this podcast on Arguing Agile. Don't forget to like and subscribe