SE Radio 701: Max Guernsey, III and Luniel de Beer on Readiness in Software Engineering

This is software engineering radio, the podcast for professional developers on the web at sc-radio.net. SCRadio is brought to you by the IEEE Computer Society by IEEE software magazine, online at computer.org/software. Welcome to software engineering radio. I'm your host, Pradesh Amanath. Today I will be discussing readiness and software engineering with two guests, Max Kernsey III, and Luniel DeBeer. Max is a software architect, educator, and co-founder of Prodicor, a consultancy dedicated to fixing delivery failures through structural and technical rigor. With over two decades of experience in object oriented design, refactoring, test-driven development, and design patterns, he has both delivered mission-critical systems and coached engineering teams at scale. Luniel is a creator of requirements, maturation, flow, a practical system for fixing the gaps between product intent and engineering execution. He has over 15 years of experience leading agile transformations, bridging product and engineering, and helping teams deliver with clarity and confidence. Luniel also originated Prodicor's capability management system, a traceable and scalable approach to modeling product capabilities. Max and Luniel are co-authors of the book, ready, while most software projects fail, and how to fix it. Max and Luniel, welcome to software engineering radio. Is there anything I miss that you'd like to add? No, thank you for welcoming me. Yes, thank you for welcoming me too. Nothing to add there. Thanks. Before we start, here are a few related episodes in software engineering that we've covered, similar concepts around software methodologies. So episode 420, we had Ryan Ripley talking about making Scrum work. We had episode 543 where John Smart talked on patterns and anti-patterns for successful software delivery and enterprises. And we had episode 389 where Ryan Singer talked on base cam software development process. Let's start with some background. Can you tell me what drove you to come out with the readiness concept? What was the team doing? What were the failures that triggered the idea of readiness? So there wasn't just a single particular incident. I would say that the drove for this. What I saw was a pattern of behavior or a pattern of practice that lit to the concept of readiness. I would say probably the earliest example of this in a Scrum or agile software development setting was when I was a technical product manager. And we had to develop lots of different internal solutions for the loading of data, the management of data, as well as the consumption of data in the organization's massive databases that we had. And in classic Scrum fashion, and this was also my early days of learning Scrum, we would be told that you have a sprint to write up all of your user stories. And then you'd go through sprint planning and maybe spend a half a day to a day in sprint planning to try and task out all of the work in a user story. And then we commit for a two-week sprint and there you go. Hopefully we're successful. But my early work in software development taught me that you need a lot more understanding and discussions with your stakeholders or your customers to really understand what the problems are that they're trying to have solved and what their expectations were. And so pretty quickly I realized that we were struggling in the classic application of Scrum and this user story format that doesn't really have all of the details in it typically as a I want so that format. So to combat that what we would do as a team is in preparation for an upcoming sprint, I would pull the team as well as other teams that we might be working with or be depending on for something that we were going to have to consume that they had to create as well as my stakeholders. And since it was a technical product it was usually all internal stakeholders and what we would do is we would sit down for a day sometimes even longer in a conference room with lots of whiteboards and half the conversations about what the problems are that we were trying to solve what the expectations were etc. And then the team would go through ideation of how to potentially solve those problems because before that they were really struggling in delivering solutions that actually satisfied the needs of the problems. And when we started doing this we realized that the teams were set up for success because they understood what the problems were they had the ability to actually negotiate back and forth with the stakeholders and the other teams and figure out how are we going to solve these problems and in a way that's going to meet the expectations of the stakeholders and ultimately solve these problems. So that was not what was typically being taught in scrum but I realized that it also didn't go against scrum it just was the type of thing that we needed to do to actually be successful in doing software development even while using scrum. So that's kind of I would say the closest thing to an origin story of that realization but then over the years I saw this pattern repeat over and over that helped I guess support the notion that teams really needed to have this time to be able to gain the shared understanding and negotiate back and forth in terms of scope and the exact nature of the solution that needs to be built. Before we actually commit to implementation, that's quite interesting in terms of how the importance of readiness was realized by you how did you then bring that all together and build that framework of requirement maturation flow. So we went to this client together and it was a bank and I'm not going to say which bank it was because this isn't the kind of story you want to like have your name associated with we got there. We were actually brought in by another consulting agency that had come to the conclusion that perhaps among other things that the team couldn't deliver and so they brought us in to help the team learn to deliver I think officially we're supposed to. Teach them behavior driven development BDD and then get them doing that but then I was brought in for like technical skills technical practices and I was immediately asked to do a code review so when we got there we were told like first thing these guys can't quote unquote commit it can't execute it's been three years that they've been working on this basically this rewrite and they haven't delivered anything and by haven't delivered anything what they meant was nothing had made it into. A sufficiently advanced deployment environment like I don't think they'd even put anything in their u a t environment certainly not into production so then one of the first things I was asked to do was review their code and I reviewed their code and I saw lots of evidence that what was being said about the team might be true massive redundancy massive like just copy and paste I mean it was bad and yet when you talk to the team you get a different story. The different story was well no the issue is that product just can't tell us what they want and so we don't really know how to build what they want doesn't really even matter if we're doing a good job or not because there's nothing. They never can tell us what they want and so then we go and we talk to someone else they say well actually it's this person in leadership that's the real problem is this person in leadership has this kind of like pathological behavior and as we proceeded through the organization talking to more and more people we keep getting these stories about how someone else is really the problem and these reasons why and so then we go and we start to invest. And we start to investigate the veracity of these claims and here's the weird part they were all right like there's one exception there's one guy and product it was pretty solid he knows who he is I'm not going to name him either. But they all had problems with their ability to perform the function of their job the developers were not writing good code one might have argued that maybe they didn't even know how to code because when I delivered them a report with recommendations of what to fix they were genuinely grateful for that. It said things like instead of having 93 copies of this algorithm put it into a function or a method and then call that and their response wasn't like a sarcastic. Would you think buddy it was like wow that's actually really good idea which to me meant they never considered that idea before so that's the level of developer we're working with and then with product it was like people who kind of didn't even know the domain and didn't really know how to learn the domain and didn't know how to articulate it. And so on and there were leaders who were putting just crushing pressures onto the teams and product that added energy to chaos right so everybody's standing there pointing fingers at everybody else and they're all correct that the other people have problems that had a bearing on their efficacy. And so then well naturally you've been brought in to like help with skills and we've identified all of these skills problems so what do they do they say okay so go help right and we did we help the engineers change their engineering approach. No impact didn't move the needle at all we helped the product people change how they captured requirements and changed how they articulated requirements didn't help. We even at least for a short period built like a little bubble around the team and the product people to protect them from that just crushing pressure that was presented by the organization and it still didn't help now we noticed that this team had a tendency to do something completely other than what was requested. We're not talking about like a product person said I want this and then after you build that they say well I meant I wanted in green. We're not talking about just a misinterpretation or an assumption that one side made that the other didn't make or that the other made differently we're talking about like they said I want a skateboard and the team made a dog leash right I mean it's just like completely random different thing that I can't even fathom how they got from what product asked for. To what was actually delivered and nobody could and so that started making us dig into as a first point understanding. And then once it was clear that the team wasn't understanding it kind of like was this we needed a way to make it happen and that kind of was like this wedge driven into their process where we needed to put something in their process that forced understanding. Before they actually started implementing so that when they built something if the product ordered a plate of corn they didn't give them a hammer right and so then we went on and on and on and said what else is the problem what else is the problem what else is the problem and we drew on. Luneel's vast experience with addressing the general problem of readiness and my experience as a developer and my tendency to apply structure to things and we built out this whole process for maturing requirements before implementation begins and then validating them at the end of the implementation cycle and then we slap the name on it. I have something to add to that story. I think we'll add more color to it as well or fill in some of that so one of the things that we found that the teams would do and the product managers would complain about something similar to this is that the teams would at the end of a sprint they would close the user stories or the product backlog items. They would claim that they had implemented it to the specification and so the product team had a really hard time actually validating that that was true because the system was not deployed for them to be able to use they had to trust that the team had done that and as we started working with them we started producing behavioral specifications at some point with them. And then the team would go off developer so they claimed and then come back and said okay we've now implemented the specification and then we would go into the actual dev deployed product deployed into the development environment and actually go and see if the product behaves in the way that we specified only to realize that there wasn't even close to the specification we put in and so we needed to find a way to ensure that the team actually implemented the specification. As it was codified but we realized very quickly that the team. I think they had an assumption that they understood the requirement but it became very clear very quickly that they really did not understand these specifications slash requirements so one of the things that we had to put in place was a forcing function to make sure that we actually could verify that the team really understood what these requirements were and what they meant and how to interpret it that they are only to. The interpretation actually was the same thing even though we ended up doing that they still ended up many times delivering something other than what we had expected so we had to put many different pieces in place including the definition of done definition of ready the time upfront to do the shared understanding but also the readiness create the requirements to a point of where they truly were ready for the team to actually take on understand scope understand what's not in scope very explicitly. So this is not in scope. This is not in scope. Only thing that's in scope is this in this and then to measure that at the end to make sure that exactly what we had asked for was actually delivered precisely the way that it was asked and only that had nothing more and then also to be able to measure when they didn't do that and a mechanism to be able to take something that they had claimed was done back through the system when we found out that it wasn't done in a way that made it very visible that no they had not actually. Achieve done this with that work item and we have to take it back through the. Sprint view if you will through the cycle to actually get them to go and fix that and so. Is all of that as well just thought I wanted to get it also cuts the other way we had product owners who were doing things like giving a requirement to a team and then when the team would go build that and then not build something else she would say it was implied. That was implied right you should have known how to handle this was like one of her favorite things to say and so that part of the team would have the opposite experience where even if they did deliver something it would be held open indefinitely at the whim of their product owner and so. Solving that problem was also a factor here like giving developers that kind of shelter so it made things clear for everyone made things controlled for everyone. Now I know that we're saying something or giving this example that it might sound like it's almost a damnation of this particular environment and the people in the company in it but the fact is that we have seen this type of. Results in this type of behavior throughout the industry we have so many clients that we've worked with we've worked with hundreds of teams and dozens of organizations right and. This particular example was just one of those situations where all of these different factors happen to be in place all at the same time but all these different dysfunctions I have experienced myself across the industry and across my career working with teams in one way shape of form. I completely agree and I've seen this happening and the organizations are worked as well so just recently I had an experience where a senior leader said the requirements might teams get I usually a one line requirement how do we deliver against those so I think what you have. Developed the requirements maturation flow rm allows teams to basically ensure that does not happen that they do not start work before they're ready and then you've got those gates to ensure the work which is complete is what was expected. I think to summarize those three foundational pillars the first is shared understanding the second one as you have developed a bespoke definition of done and a bespoke definition of ready what we'll do is we'll double click on each of these concepts. And get a better understanding of those so double clicking first or you know diving a bit deeper into requirement maturation flow one which is arm of fun. Can you help explain how is that different from say backlog refinement which is already done by the teams. Yes so there's a common practice in scrum teams and that is to have this backlog grooming or backlog refinement meetings and my experience is that depends on the team and who the scrum master product owner is but it tends to be maybe an hour maybe two hours a week sometimes two hours per sprint where they're essentially trying to do a lightweight refinement of the backlog where they discuss okay this is the backlog as it is now these are the stories that I think we're going to be taking up in the analogous role play we're going to take up in the next sprint and let's talk about the priority. Let's talk about the details because in the end I need to make sure that they've been estimated and in order for the team to estimate it we'll have to have some quick conversations do you understand. The story makes sense we need to have anything else other story taken up before this and give us an estimate and so the teams maybe they'd go through the practice of planning poker to come up with a story point estimate or something like that but the problem with these particular meetings is that it echoes what I've seen a lot. It's what I've seen a lot in the scrum world and that is that there's this practice that's not even it's an event I think a meeting that has become part of the practice but it's not even part of scrum scrum talks about refining the backlog and that it's an ongoing thing that has to happen but in adopting these I guess practices that have become the norm in the industry. The teams adopt these backlog refining meetings and you know they'll spend maybe an hour to hour per week on that and that's about it. That's about the only time that they really sit down with the teams to actually go through the requirements and essentially give the teams the opportunity to ask questions and discuss the details, discuss the scope etc. Then they're supposed to come up with an estimate and the problem is that it's not taking each item and spending as much time on that particular item backlog item to get it to a point of readiness and to a point where the team will succeed in actually being able to implement that in the sprint. It's this generic thing where people are doing this almost hand wave itself. I mean, yeah, people talk about the backlog and they talk about priorities and they do estimates but they're not focusing on each item independently. So it's almost as if a story as a story as a story is a story product backlog item or PBI is a PBI is a PBI is a PBI all we need to know is do you understand it can you estimate it and is it the next priority. The problem is that these backlog items can be vastly different in complexity in what is required in terms of the scope and the discussions that might be needed and many times the teams have to go and do some research into the current system. To even understand what it would take to implement the backlog item the change in functionality added functionality that is being asked for in this before they can even come up with a really good estimate but in many cases it's just assumed that the team is going to spend their time looking through these backlog items and analyzing them and ask all the questions that are needed and magically they're going to become ready for the next sprint. And I think part of this it's kind of like a cargo cult behavior that I have noticed in the software development industry and if you're not familiar with cargo cult I highly recommend going and looking that up but it's a fascinating thing that I see happen all the time. But that's the type of thing that I've seen where there is these practices are adopted but they're not really dealing with the actual readiness of individual items explicitly. So what we have found is needed is yeah, you can have your backlog refinement meeting backlog grooming meetings and you can have these one or two hours per week, a couple of times per sprint or whatever it is but each item needs to ultimately have the quality of time and quantity of time spent on that to actually get that backlog item ready for implementation. And one hour two hours a week just doesn't cut it and in the example that we gave with the bank it became very clear very quickly that in order to create that shared understanding and to be able to really understand what ready meant to really understand what done meant and to make sure that everybody understood what they needed to go and implement as part of this backlog item would take sometimes days I mean we would sometimes spend. Half a day sessions a few times during a sprint just on a single work item to actually gain that level of understanding and that level of precision I guess if you will and definition and some of them would only take a half an hour or an hour and so trying to treat these product backlog items as if they are the same and you can just do an entire sprint with the backlog items in these short backlog refinement or grooming meetings. Just I'm sorry it's just absurd and I'm not saying it because I'm trying to attack the people who do that I'm saying this because it's just not a true reflection of reality of what is needed and therein lies the reason why teams fail to implement these requirements implement these backlog items in a single sprint why they also end up having defects why they end up having rework that they have to go back. So if I got a try what you're saying is backlog refinement we just take the entire backlog without appreciating the complexity each task or each pbi will have and just put estimates against each of them not really understanding whether each work item is ready whether it's too complex to be picked up and so on and what your framework does is basically separates this out so that it's thought through and analyzed as part of each. PBI rather than collectively is that right yes that is correct it dedicates the appropriate amount of capacity to each work item okay and maybe haven't seen it in many teams but there are teams which. Along lived and have been maintaining a product for a long time so they have the shared understanding what they don't have an understanding is about the entire stack of technology and the product because. It's legacy in such cases where you already have shared understanding about the work that needs to be done do you still see a need for a separate readiness activity to be done for each work item. Yeah I do so I have worked on teams where shared understanding was already established before even considering readiness or at least it was believed to be established you wouldn't have been able to go to those people and say you need to establish shared understanding because it's that we already have it and instead what their big problem was they had changed their ways recently but they'd gone 5 10 15 maybe even 20 years building up a code base using different practices and so they had a large body of legacy code. And those teams can still use the readiness work item is mechanism that's proposed an rm f1 to help them so rm f1 really has two key parts in my mind one part is managing readiness work which is fundamentally an estimable I mean if you could estimate it then you could just call it work right but this is work that you need in order to get to the point where you could do something like as to me. Managing readiness work it provides a mechanism for that away to show progress to decide what readiness work you're going to do to be transparent about all that to control it and to fit all of that within an agile development pipeline. So that's one part of it is providing the mechanism and then you can't really just say we're going to have this mechanism in an organization and have everybody kind of pat themselves on the back. You have to have some kind of work flowing through it and so the work item type that we propose is shared understanding which as you said is very commonly a problem right in most teams they don't really have that clear crisp understanding of what to do. But if you imagine these other teams would don't imagine them I mean I don't have to imagine them because I was on them but if you imagine another team with that they do know what they need to do they do understand what they need to do but they don't necessarily know how they're going to do it because they're trying to be disciplined in a code base that is the product of perhaps decades of undisciplined coding they could still use the rm f1 mechanism but instead of shared understanding being what they manage with it. They could use it to manage refactoring work so they could say look I know I need to build this and I know the design is not going to support it or the architecture in some cases is not going to support it and so I don't know how long it's going to take to get the architecture to the point where it actually will support this new functionality. So I'm going to start scheduling work to prepare the way to pave the way as Kent Beck says make the change easy and then make the easy change right so I'm going to start doing the work for making the change easy and I don't know how long that's going to take so I'm going to use this mechanism to fit it within my sprints and just make progress and show progress to that effect and eventually the code will be ready as it were right and so then you could schedule the work items. So in that environment I would actually propose that we switch over because they think they've already solved the shared understanding thing now the reality is they might not really have solved it they might just think they've solved it but they might get so much benefit out of doing the readiness work of transforming their legacy code into something they could actually work with in a managed way so there's not pressure to like I'm going to radically change this design by this deadline and implement this feature by this deadline. They might get so much benefit out of that that they decide maybe I should go back and revisit the shared understanding thing and see if we really have understanding and see if we're really building the right thing right we'll talk with the product people and not just make sure that we're building what they say that we should build but that they're saying the thing that really needs to be built the correct next thing so whatever item you start flowing through your system with RMF one whatever type it's really just a foot in the door for readiness work. And once teams start seeing the benefit of it it paves the way for RMF 2 and RMF 3 right maybe to bring it to life can you give me an example of a readiness work item and how it's implemented and says crumb. So readiness work items are essentially a category of work items right so we have what we call readiness work items and then we have the actual implementation work items. So readiness work item would be a work item that is trying to reserve capacity for a team in an upcoming sprint in order to make an implementation item ready. So depending on what that nature the readiness work is that needs to be done that readiness item will then do that so an example of that would be what max had just said would be a refactoring work item or be a readiness work item to do some refactoring of the existing code base in order to make it ready for the implementation work to be taken on. And another one would be you know if I'm writing specifications and I need time with the team to actually review that specification I need time to review the work item itself to have us define the definition of done for that work item define the definition of ready for the work item and also have the time to discuss the requirements the specifications the scope of that work item with the team. I'm not just going to go and randomly call them into a meeting I'm going to be respectful of the fact that all the teams time in a sprint must be accounted for and it must be reserved for particular work. And so as a product owner or requirements author when I have a work item that I need to discuss with the team then I will have automatically I will put an analysis work item on the backlog that's one of the readiness work items that we would schedule as with the team would go into me try to schedule that into reserve capacity for that in a sprint. I would decide how much of the sprints capacity I think I would want to give up of the team not developing software but the actual implementation stories if you will implementation items and actually spend some of that capacity on working with me to review this work item that I'm trying to get ready and will then plan that in a upcoming sprint and then I will be able to utilize. If you will the time box that I have set aside for that the amount of capacity of the team that I've set aside for doing this readiness work item the analysis and actually schedule the meetings with them to try and achieve readiness on that those are two examples I guess one would be like Max talked about refactoring another one would be in my case for trying to get the implementation item ready. Maybe to make it a bit more specific so if I had a work item something along the lines if the effects rate is outside of the daily range sure warning message box if that was the work item. Would you change that particular work item itself or would you add a new work item what would you call it could you give details around that to bring this to life. Could you just repeat what that work item was for. So the implementation work item was if the effects rates entered by the user are outside a specific daily range sure message or a warning when you say effects you talk about foreign exchange or something like that. Yeah, yeah, somebody for an exchange rate. So that would be the implementation work item what I would then create is a redness work item to do analysis with the team on that implementation work item. I would whichever tool I'm using let's say I'm using JIRA I would create a user story that is a child user story of the implementation story and the aim of that readiness analysis story would be to have time with the team to actually review the specification that I have in the implementation story. And make sure that we are going to do three things we're going to make sure that we have a definition of done in the implementation story and if you're following the guidance that we've put into the book and the guidance we provide for RMS I would most likely pick an appropriate definition of done template and copy and paste that into the implementation work item. I would then do the same thing with the definition of done and copy and paste an initial definition of done into the implementation work item I would do that as a product owner prior to even meeting with the team on that. But I know that I need to have time spent with the team so that I can review with them the definition of done and the definition of ready so we can identify what done really means stipulate that and then actually document that in the implementation work item. The same thing with ready we need a definition of ready we would need to discuss what will it take for this work item to be ready are their external dependencies are their internal dependencies just the team need to go and do any kind of analysis on the existing code base for the existing implementation. Do they need to do refactoring of the existing code base etc and I would have to also understand that part of the definition of ready would be that the requirements themselves. The same thing that I want them to actually go and implement that that has achieved a level of maturity to the point of way we can actually move ahead and implement that. So this initial analysis work item or readiness work item that I will schedule would be to do all of these three things to make sure that we have an agreed upon and documented definition of done agreed upon and documented definition of ready. Other readiness activities that need to be done and I get to discuss the actual requirements with the team to try and see if we can gain shared understanding in that. If we take that into a sprint and we allocate time for that and we actually sit down and do that work with the team it doesn't mean that the implementation work item is automatically going to be ready for the next sprint. There are many things that might need to be done to get that work item ready and when I say the work item I mean the requirements I mean the code base ready for the teams understanding for it etc. So as a product owner I might have to evolve the requirement based on the discussion with the team which means I might have to go and have further conversations with my stakeholders or the customers and ask questions and evolve the requirement to a point of where it actually is ready and mature enough for us to actually implement. The team might have to go and do additional work in like I said either refactoring or research into what the implementation is going to require what is the existing design in the system etc. And there might be external dependencies that we might have to work with and I might as a product or might have to go and talk to an external team to actually get them to do something for us that we're going to depend on to be ready for us to actually implement this work item. So the implementation work item will stand aside and it will sit there in the backlog in a state of trying to get that ready and I will spin off raideness work items that we will either take through the current scrum teams sprints to mature the work item the implementation work item and I might take to work to other teams as well to help with achieving raideness on that. Does that help? It does let me just rephrase that in my own words and see if I've understood right. So if I had a work item which score a specific requirement. There were three things that would be expected to be done one is an additional work item would be created something along the lines of analyze and ensure we have shared understanding of this implementation work item. In addition, we'll also change or modify the implementation work item and add the templated definition of done and definition of ready so that we are clear in terms of what requires to be done so that it fulfills the needs of that requirement. Is that a right understanding? Yes, but just with one clarification, the template definition of done and definition of ready are starting points, right. We're taking something from the actual templates, but then we have to turn them into bespoke definitions of done and definitions of ready. In other words, we have to make sure that the definition of done truly reflects the definition of done of that specific work item which means we might have to add things, change things or take things away that are necessary for it. And the same thing goes with the definition of ready. Yes, we start with the starter, but then we have to refine that to get to that. We will double click on both those concepts, but before that, is it true then for any team to implement RMS, they need to implement all three foundational concepts which is shared understanding definition of done and definition of ready for them to successfully transition over. I mean to implement all of RMS and to get the most kind of juice out of that orange sure, but you can start getting value just by implementing one piece of it. That's why we broke it into three pieces rather than just providing it all right. The three units RMS 1, 2 and 3 shared understanding bespoke definition of done and bespoke definition of ready aren't merely like organizational structures. They're actual units of value. So a team can take just RMS 1 and apply it. So in the example you provided, a team could say, well, we're not quite ready to handle the full definition of done definition of ready stuff. Maybe we don't have the capacity to actually do the transformation work within the team to get all of that implemented. You just the shared understanding. So if you create a backlog item with the FX rate boundary thing, right, even without all of the details, like, you know, how are they going to get the data, how are they going to do this, all of those other things that come from the definition of done and definition of ready. There's just the question of, do they really know what that means? Do they really know what show the user warning means? Do they really know what all of these things mean? So they could take just RMS 1 and use it to solve that problem, use it to give them the full understanding of what is really being asked of them. And what that looks like is like a miniature version of what Lunille just went through. They would create a readiness item and the readiness item would be a time boxed allocation of capacity if they're using scrum within a sprint. So they say, we're going to use eight man hours of our sprint or whatever, right, and we're going to get smart on this. I actually heard people use the term get smart. And so then eight man hours, that is, translates to a one hour meeting with stakeholders. So they then have that meeting with the stakeholders for that specific item. They don't care about stakeholders for other items. They don't care about, you know, the people who are going to be there for the demo for some sprint eventually. It's not a big list. It's just the people who really have skin in the game for that one item. They'll spend an hour talking with those people about that item, getting answers to their questions, getting a deep understanding of it, documenting that understanding in a way that maybe is useful later. But even just the act of writing it down sometimes helps people write note taking helps people learn, even if they never read the notes, they gain that understanding they fill themselves up with a model in their mind of what it is that they're producing. And if they actually get a complete model, then the work item is done. And now the implementation work item is ready. If they don't, if they still have questions, if there was someone who couldn't join them for that meeting and they need to talk to that person or whatever, whatever it is that standing in the way of them getting that shared understanding that that's having the same aligned understanding with the stakeholders about what that work item is then the implementation work item is not ready. And what they do is they schedule another one for another sprint or if it's con bond, maybe they just schedule another one for the next day. I don't know, right? But the point is these are time boxed allocations of capacity to do work that you cannot commit to a timeline on because you do not know how long it will take you to get understanding. Sometimes it takes five minutes, sometimes it takes nine hours, you just there's no way to predict it. So you just start carving time out to get that understanding and you're done when you're done. And that would give you RMF one that gives people better results. That's useful. Thanks for explaining that. How do you know you've got shared understanding when do you know it's enough? You know, you don't need to spend nine more hours and we are all on the same page. When does that get picked marked? So the way that you know is we have a kind of a transfer of responsibility mechanism. We have a model for that. It's like a big thing that we can install in big organizations, but we kind of created a little slice of it, a sliced down version of it just for teams to use in RMF. And so you know that you have shared understanding when you meet the standard that the team is willing to put themselves completely in the product or stakeholders hands like be at their mercy for when the work item closes. That's kind of one of the main standards. So what we say is responsibility starts off with product starts off with business starts off with the stakeholders or whatever. Right. Eventually responsibility for the work item is going to transfer into the team at the end of a cycle or whenever it is they go to close that work item. Responsibility is going to need to be taken back by product and product isn't going to do that unless it actually meets the standard that they had envisioned. And so the team needs to be sure that their understanding that they're envisioning of the output of that work item is the same as products envisioning of the output of that work item. And that way when it's time to close the work item, it will run smoothly. If the team isn't sure of that, then the team will keep saying, no, this is not ready. They don't have the understanding. Now, I'm not going to pretend that just saying that like there's a magic wand where you say that and it's true. You have to sometimes for some teams, you have to go through some kind of like painful retraining cycles where they say, OK, yes, sure, we understand they wave their hands. And then we get to the end of the sprint or whatever, you know, whatever the end time marker is. And they say, OK, well, we did it, you know, and then product says, yeah, but you didn't do what I asked. So I'm not going to give you credit or I'm not going to close it or I'm not going to let us move on to the next thing and we're going to make you go back and do it again. And that happens in a visible way where it's clear that the team didn't do what was requested of them by product. And after one or two of those cycles, then the team gets it. When I say I understand, I have to be so confident that I understand that I'll be held in the crucible of that understanding at the end of this story. You know, depending on the organization that I'm in, the consequences of saying I understood when I didn't really understand of not ferretting out hidden assumptions and whatnot. Those will range between being a little embarrassed and having egg on your face versus, you know, in some really like toxic organizations, maybe you get castigated or something like that. But there's some kind of skin in the game. Something is on the line if they don't have that understanding. Right, caught it. So we'll move to the next section where we'll double click on definition of done. So I understand you have developed a bespoke definition of done. How is that different from the normal definition of done, which is used at the project level. And it's standard across the teams, right? All the tasks use it and we just make sure that it fulfills those criteria, which I mentioned over there. Why did you feel the need to create a bespoke definition of done? Sure. So working with teams that have a definition of done that they've already come up with. The typical thing that I've seen with teams is that they would have in the beginning when they adopted scrum or they went through scrum training or something like that. They were told to come up with a definition of done and so they might have spent some time doing that. But what is typically being taught in the industry is that the team has a definition of done of what it typically means for that work item or for implementation item to be done. And they would have a lot of general things in there. You know, we need to like coding standards and testing standards. The code had to have been code reviewed by, you know, a non-author or it might have had to go through some architectural review things like that. And these are great as far as making sure that you're capturing your standards or development standards, both coding and architectural and testing standards around that. The only problem is that what I have found in general is once teams have created that definition of done, it's a generic definition of done that's kind of a catch all for all the different types of work items that they take. Or maybe in the beginning because they only did the first time and never revisited it, it only contains a part of the criteria that they normally would have to take on, especially as they work evolved over time. But it's the typically it's the type of thing that is created and then just forgotten. So in so many cases, in fact, the vast majority of cases when I would work with a team, I would ask them, so do you have a definition of done and have the team wouldn't even know that they had one. And some people who might have been there from the beginning would say, yeah, we have a definition of done. And I would ask them, well, where is it? And then the half of those people might not even know where it is. And somebody would find out and they say, okay, here's where it is. We'll take a look at it. And then I would ask them, have you actually been looking at this definition of done at the end of the sprint and making sure that every work item actually adheres to this definition of done. And then the answer would usually be no. And then the question would lead to well, why not? Well, because it's because it's not most of those things don't apply to this particular work item or something like that. Or we've forgotten. So the problem with that type of thing is that it's like almost a safety blanket. We can say that we have it, but we don't really use it. It doesn't really serve a true purpose other than just making us feel warm and cut fuzzy that we've actually created this thing that have the people don't even know exists anymore. The problem is that each work item itself is typically different. Even in teams that do similar work and work on the same systems over and over and adding maybe making some small changes to the same piece of functionality over and over. Many cases, those work items are different in shape and nature. And so how many requirements do you have? What are the acceptance criteria in there? Do you need to create documentation? Do you truly need to actually go and do an architectural review? Is there something that we need to do that goes beyond just this discussion? Do we need to do something with a support team? Do we need to have user acceptance done on that? Do we need to have legal review of that? So when you take a look at a typical teams backlog of like the last 100 product backlog items or stories that they've developed and you look across them, you really dig into the details of each one of them. You'll understand that the true definition of done is so vastly different in many cases across that backlog of work items that the original definition of done that people have kind of internalized or maybe not even remember. Just doesn't even apply to it. It might have too many things. It might not have enough things in it. And they're in lies again, the reason why teams end up failing in actually completing the work items that they've been asked to implement because they don't really understand what done means for that particular item. So that's the one part of it. And the other part of it is that most of the time strum teams are asked to estimate the size, you know, the effort for that work item. And what I've realized over time is that teams don't really succeed in providing a reliable estimate if they don't actually understand what done means for that specific work item. So sitting down with a work item then and actually discussing and then eventually codifying, you know, defining what done really means for this work item gives the team a much greater clarity on what the actual work is going to be that they need to go and do not just from an implementation perspective, but also what other things need to be done as part of this. Do we need to create documentation? Do we need to go and have a review with legal etc. Right. And that creates the type of clarity for team to truly understand and be able to succeed with that specific work item. So it's really about trying to take every single work item and treating it as if it is a special case of its own and making sure that we have truly captured what done means for that work item. And over time we'll find that there are kind of categories of work items that have similar shape and size in terms of the definition of done and what needs to be done. So not all work is the same right. So sometimes says database work that needs to be done sometimes there's I guess an API that needs to be created that's different from making changes to an API which is potentially different from making changes to the user interface graphical design of that etc. And so these types of work items can mean different things that need to be done for that work item. And so as you start seeing that there are these categories, then you can say, OK, well, this type of work item is a path like that. And so that's what leads us to also sometimes creating different templates for definition of done with different type of work items. But in every case we want to make sure that the team has a precise and accurate understanding and documentation of what done will mean for that work item and not just assume that we understand what it is. It's like giving them the ability to at the end to certify we have done everything that we have agreed upon from the beginning before we started implementing that needed to have been done to be able to call this thing done and say we have implemented it. And that behavior as well as this not just the documentation, but the doing of this and certifying of that at the end creates a level of trust and acceleration in teams that is unlike what I see in teams not doing this. The challenges, you know, you've got various types of programmers, you've got junior programmers, people have just started off and you've got programmers who are lazy. And what stops them then because it's been say an organizational mandate or it's a mandate for that particular program that you need to have a specific definition of done for each work item. What stops them from just doing a copy paste for, you know, and not making it specific for that task or that work item. What do you look for in that definition of done to ensure it's a good quality one, which will ensure that it is can be seen as sign off. So it comes down to responsibility in my opinion, the definition of done isn't just signed off by one party, the definition of done has to be approved by everyone and everyone approving it becomes responsible for it. So the agreement manifest in the definition of done is that when all of these items are truly met, this work item will close and responsibility for it will transfer from the team back to, you know, whoever's in charge of product product owner product manager, whatever, right. The product manager then has an impetus to ensure that there are no for lack of a better term loopholes right that that definition of done is the right definition of done for that work item. So then when it comes back to them, then we get to point the figure finger at the team and say they did it wrong because the definition of done is what the team was supposed to do and the team did the definition of done right. So they accepted it. If something's wrong, they're going to be the ones that are on the hook for being wrong. So they're going to push back on accepting it on the basis of that definition of done, but they can't push back in this process, they can't push back on the basis of like, oh, I forgot something or whatever. So they've got a big driver to make sure that definition of done is right. The team has a similar driver, right. They want to make sure that the definition of done is exactly right so that they can use it to implement things in a way that will get the work item to be accepted and closed and move forward. So they're going to have some pressure if they're really lazy, which I mean, I don't know how many teams are really lazy, but if there is a team that's really lazy, they'll have pressure from outside that says, well, you've also got to have the architecture review, you've got to have all these things, right. You've got to have all of these standards be met in order for this work item to be closed and that way we keep our code quality higher and we can maintain the product over time. How do I get work started on it? Well, getting work started on it means everybody's agreed on a work item or on the definition of done. So that's one pressure and that pressure makes it so that people don't try to like throw everything in the kitchen sink in it. They try to make it just right for just that item. And then the other pressure is how are we going to get this handed off at the end and that makes sure that everybody has what they need in order to be able to later be held to account and kind of pass that test for that work item in it. It's the tension between those two forces. And this transfer of responsibility is what stops product owners saying that, you know, I thought this wasn't implicit requirement in the early example you had given. This is where it gets caught. Nothing actually stops them from saying it, right. All you can do is create consequences when they do say it. So when the team has an agreement, presumably management is in on this agreement. This isn't something you can do in a really grassroots way. You've got to have management involved. You might even need leadership involved and people from other parts of the organization other than engineering involved and on board. Once you have that kind of alignment and agreement. This is how we're going to do business. Then I guess if a product owner were to say, Oh, I forgot this piece. So we need to do more. It's the team's responsibility to say that's not how this works. And then, you know, I guess if the product owners really stubborn and holding it open or whatever, then there'd be some sort of escalation process where you get intervention from management. I really don't find that to be a very common problem because I mean initially like in the training phase it might be, but everybody wants to do a good job. Everybody wants things to go smoothly. And this makes things go smoothly and gets us a better job. Right, got it. Luniel, you had something to add. Yes. So like Max actually just said now is most of the times people are trying to do the right thing, but what this gives us is two things. One, so in addition to helping us solve a dysfunctional environment where people are not taking responsibility or being lazy or they have poor practices or something like that. It also helps in scenarios where teams are truly highly successful and highly capable, highly motivated, but just want to make sure that the right thing gets done. One of the examples that I like to one of the things I guess mechanisms I want to talk about is that in scrum, a good product owner understands that they are ultimately responsible for what the scrum team develops. They have a fiduciary responsibility to the organization to essentially put the right things into the team's sprints, the right work items, and make sure that the team ultimately is producing the value that the company is paying for. Because the company is paying a certain amount per sprint if you will and that goes here for how much they paying for facilities, but they're paying for salaries of the people involved the product owner scrum master this scrum team, etc. And so as the product owner, you are kind of like a mini CEO almost you have this fiduciary responsibility to make sure that the team is working on the right things and are producing the right things to create the value that the company is paying for. So as a product owner myself, I want to make sure that I am giving the team the best chance of succeeding in delivering this thing that I'm asking him to deliver. So having clarity on the definition of done what it actually means to be done is not just important for the team, it's important for me because I need to make sure that the team has this clear understanding of what done actually means, but it also means I have to have a clear understanding of what done means. And if I didn't think about all these other things that needed to be done, then I might be setting the team up for failure. If I don't get an opportunity for the team to point out this additional things that need to be done, I'm setting them up for failure. If I don't give them the ability to actually create a or to apply a reliable estimate, for instance, for the work of what they think is going to take in this sprint and one that they can feel absolutely that they can stand by and that they comfortable with. Then again, I'm setting them up for failure. So it works both ways. And so yes, this handoff of responsibility is an absolute forcing function to help solve problems when we have dysfunction in that. But it also helps us create the guard rails that even a high performing team needs to have to make sure that what's being asked for is clear that both parties agree to it and that we can actually succeed in delivering that at the end. Would you be able to explain what the definition of ready is and why it needs to be bespoke? It's similar to the definition of done wherein each work item is different or should be treated as potentially different from other work items. But an example of definition of ready week, we typically have two categories in our definition of ready and that is product exit criteria. In other words, what are the criteria that needs to be met in order for product management, your product owner, product manager to be able to say this work item and everything in it, the requirements, you know, the specifications that are listed in there. And everything that is needed to be provided to the team are ready. So, you know, everything is ready. So an example would be not just the requirements itself. So if I was to do behavior driven development, there would be behavioral specifications for all of the different scenarios that are in scope for this work item. But there might be things there that I have to provide the team such as UI design or creative designs. There might be a UI mockup or something like that. There might be additional information that I have to provide in addition to just the actual kind of specifications. So I need to make sure that when I hand this requirement off to the team to implement, then they have if I am comfortable that I've given them everything that is needed and I have to be comfortable that the requirement itself is actually representative of the stakeholders expectations. So I might have had some specifications that are not fully baked yet and I still need to go.