 Can you hear me? How people at the back, can you hear me? OK, everyone's there. OK, I guess I shall start. I'm Jason Yipam. Yes, you can't hear me? If I talk loud, or how about now? OK, I'm going to just shout at the people at the back of the room. And sorry for everyone up here, but that's too bad because you've set up here. OK, so I'm Jason Yipam from ThoughtWorks. This particular session is what I call Think Like an Agilist. If you are getting ready to sit down and do nothing, you're going to have to switch because this is primarily an activity. So I will cover off some initial context concepts, but most of it will be you doing something. So make sure that you have something to write on. I know that there's these kind of sheets of paper there, but you'll need probably, it's going to be groups of maybe two or three, that sort of thing. You can do larger groups, but it's something like that. So just make sure you have something you're prepared to do. If you actually don't want to be part of a group, that's OK. You can do it on your own as well. That's fine. What you are seeing as well, I forgot my laptop at my apartment back in Sydney. So this is my sketched-up version of it, but that's OK. The basic idea is still there. OK, so raise your hands if you think culture is important to Agile. Raise your hand. We all think that's good. OK, so what I want you to do right now is think about what you mean when you say culture. So when I say the word culture, think about what that means to you. So what's the definition of that? So I just want you to get that in your head. And when you have sort of a thought, OK, that's culture. That's what I mean when I think about it. Raise your hand. This is a little bit harder because you have to think about it for a bit, but you say, OK, this is what I mean when I think culture. That's this. Then raise your hand when you're ready. Some of you might take a long time and I'll just not wait for you. OK, so if you had your hand up and you go, OK, for the rest of the room, obviously people didn't put their hand up, didn't have an idea, so that's cool. But for the rest of you, raise your hand if you think your definition is the same as everyone else. You think it's the same? Ooh, over-optimistic. Over-optimistic, interesting. OK, we know we kind of laugh because it's very unlikely. Like I go, I haven't talked to you, so I don't know. I'm going to think culture. You're going to think culture. We're not going to be thinking about the same thing. That's just kind of a natural thing. So this is what I call a logical inconsistency. We all raised our hand when we said culture is important, but we have no ability to have a shared understanding of it because we don't mean the same thing. So how could it possibly be that we consider important, but we can't actually behave that way? So what I'm going to try to do here is create, do something that try to help us do this, create that shared understanding because if it is important, then we should respond to that belief. How many people are familiar with Edgar Schein? Edgar Schein? Has anyone heard of the phrase corporate culture? Yeah? He would be the first person who came up with that phrase. So that was his term. He wrote several books about that. So the way he describes cultures and these kind of three... Oh, I have a laser pointer here, let me see. Ooh, yeah, three stages. This is too small for the people back. Okay, three stages. The top level is what he calls artifacts or behavior. So what are the visible things? If I look around and say, okay, what's culture for, especially for an organization, I could say, what's their dress code? Okay, that culture, they like to wear suits and this one, they like to wear t-shirts, whatever that. That's a visible thing. They could be other things like when you look at some companies, they have ping pong tables or they have plants in the windows, all that kind of stuff. You go, that's all visible culture things. Underneath that, you have what are called stated values. So if I have a value statement, if I do a culture book, all those sort of things, those are stated, they're kind of presented culture. I call both those things what you can see when you go somewhere and what they present to you, that's culture theater. It's what they try to convey is what their culture is about. And I would say that that's not what I mean and what I would suggest, we don't think of culture that, we think more at the bottom level here, which is about underlying assumptions and beliefs. Okay, so I call that the actual culture, the essence of the culture. Okay, so I was having a discussion with some people and one of the breaks about this. And I was saying, it's like a belief in gravity. That's culture for an organization. So those things that you don't question, you just assume them to be true. If someone doesn't believe it, you're not talking, it's not like a value discussion, it's more like you don't believe in gravity, you're an idiot, that's culture. When you're in your organization, there are some things that anyone who questions it, they just look like they're stupid or something cause it doesn't make any sense. And that's what when we say, we're talking about agile culture, what are those things that are underneath there that we just assume. Like they're not questioned, they're just there and working out when we get to that point. Okay, so what I'm saying is the essence of culture is not what we see, it's what lies underneath it. And what I'm going to do with this exercise is try to expose what lies underneath by using a technique called thinking aloud. So is anyone familiar with thinking aloud? This is kind of like, yeah, not informally. But think aloud protocol, I would say. It's like if you've ever done user testing, you would do something like this. So you get people to talk about what they're doing. This comes a little bit more because it's more about what they're thinking. This idea came from a kind of a, I guess a technique or an exercise, a prototype that the US Army did. They called it think like a commander. So they were using scenarios for their tactical leaders to try to teach them about how to think adaptively in different scenarios. So with US Army, they go, I can't train you for every single scenario because there are too many of them, but I can train you how to think through multiple different scenarios. And then I can trust that when you're, even if you encounter something that we didn't expect, you know how to deal with it appropriately. So this is the kind of thing that we're doing. What I'm putting out here is think like an Agilist is really using scenarios to help us practice thinking in an Agile way. So when I originally came up with this, this was more to try to highlight to people what the difference between, let's call it an expert Agile person versus a novice Agile person, how they would actually approach a scenario differently and try to expose the difference in thinking because the problem was that given a scenario, someone could still respond visibly in the same way, but their thought process was different and you couldn't see it. So I did this to try to show that and then we could help the, usually the junior, the novice people learn because they could say, oh, okay, this is what I'm supposed to be kind of working how I work through it. And then we could trust they can put more difficult scenarios and they could deal with it. Okay, so, there's really two things that come out of this exercise. And I highlight, I point this out because even though, like I put this out as intermediate level, I sometimes I think about it and go, maybe this is more on the advanced side is that for some people, especially if you just kind of actually, let's do a quick check. How experiences everyone in terms of agile, would you call yourself, if you raise your hand, if you call yourself like a novice, this is kind of a new thing for you. Okay, how about like intermediate kind of a practitioner? If you are more advanced, so you would, you train people, you teach people how to do it. Okay, I would actually say that last group, this probably helps you more practitioners. I say this is something you need to do. So even though it might be hard, that's useful. The novices you might find is very difficult, that's okay. By the time you get to practitioner, you'll go, hey, this is easy because you're already ahead of the game. But this might be a little difficult. So this is why I kind of point this out. There's two things that will happen. One is you're practicing metacognition. All that means is that instead of just thinking about things, you're actually observing how your thought process works. So observing your cultural assumptions, if you will. And if you just learn how to do that, that's great. What I'm really trying to do though is help you learn how to practice agile assumptions as in highlight what are the underlying agile assumptions and then say, how does that change how you start responding to a scenario? The first thing of course is to say, expose how you currently respond to scenarios and then see if you can start adjusting that, okay. Feel free, if this starts going over your head or you have questions, feel free to interrupt me and we'll work it through. Because I do want you to get ready for it so that you can sort of get the most out of the exercise. Okay, so two roles. One is the thinker. So we'll have a person, I will provide a scenario and you as a thinker will respond to the scenario by thinking aloud to expose your assumptions, right. So what that means is I'll say, hey, here's this thing that's going on and then you'll go, oh, okay. And as you start thinking about it, you start talking, right. So kind of stream consciousness, like so you say, oh, this scenario looks very interesting because I have this question about this and I think that's important because so therefore I'm thinking about this or that guy's distracting me with his water, right. Whatever, just expose it, okay. Does that make sense? I throw that last one in because when you actually watch yourself think it's not a linear process, it kind of goes around in circles, but that's fine. We just want to see it all, okay. The kind of key thing here is don't filter what's there, try to see it for what it is, okay. I joke, this is sort of like, I'm trying to teach you meditation to some extent but this is kind of, there you go. Okay, the other one is the scribe. So it can be one person or like if you have a group of people that's more than two people then just you can might have multiple scribes. So every, those people will capture what that person is saying. So given that they're just saying things, they can't write it down so you have to capture it for them and then what you're trying, and I will also use you later on to reflect on what's going on there. But so all you do is if the person's saying this and that you just scribble it down. So does that make sense? So we have one role which is this person just exposing their thought process and the other people are capturing it, okay. That's basically it. Okay, is everyone ready? Does anyone have any questions before we start? Oh, okay, yeah, let's prep. Okay, so look around here and select your team. So who do you wanna work with? You can do the entire table if you want. Like the thing is if you have the entire table you have one thinker but if you could like split up into three and then you could have like multiple thinkers if you want. Okay, yeah. Okay, so is everyone clear who's gonna be the thinker and who are gonna be the scribes? You can use the, so I just said if you want to you can have one thinker per table or you can split it up so you can have more thinkers and then you just, it just depends on why you wanna play it. Okay, is everyone ready? Yes, yes you can. It's just, you just have to split the group, that's all. Sure that you are comfortable exposing your flaws, okay. So if you go, oh I don't wanna say because I look like I feel like I'm really bad at it. You will get someone else, right? Because this has to, you have to be comfortable just saying everything that's going through your head. Okay, and if you go I wanna make myself look good, you won't learn anything. So, okay just make sure, yeah only the mature people can be thinkers, yeah that's how I should put it. Only the mature people. Okay, is everyone ready? Is everyone ready? Is that all good? Yeah, okay, okay. Okay, so let's swap. Okay, I should also warn you, I'm gonna make this bigger. Can everyone see that? How about that? Is that visible? I'll describe it, I'll say it out as well just so people in the back, you can't read it. Okay, I should warn you again, I haven't warned you yet. These scenarios are not designed to be winnable, okay? So you may not be able to respond successfully to it but I don't, we don't care, right? We're just saying how do you approach it is the problem, not whether you can solve the problem. Okay, does that make sense? So don't feel bad if you go out, there's no way to resolve this, that's fine. I don't actually care whether you resolve this but I do care about how do you approach it even when it's winnable. Okay, so I'll read this out just for people who can't see it. So scenario one, you are the new development manager in a web startup, the main application was hastily written in pure PHP, no MBC, no OO, no templating, no framework. Note that other good options were available when this was created, Rails, Django, PHP-based frameworks but they weren't used. A new customer has signed up and expects an implementation within three months. They were sold on features that the product doesn't actually have. At the same time, the company is targeting a larger market where development speed is very important. So you are the development manager, you have to work out how to meet the short term need of launching to the customer, ensure that you're set up to succeed medium to long term from a product development perspective and get executive buy in on whatever strategy you decide. Before you start as a thinker, what we wanna know is everything including what questions you have, what information you want that is not currently there, what information you consider important, everything. So if you say, hey, I would want to know this but it's not there, say that so they can capture that because we're even picking that up, okay? It's gonna tell us about how your brain is working. Okay, it's good and you're off. We'll give you about five minutes to do this. I guess I'm gonna walk around. Complete it because it's a fake problem so you don't actually have to solve it. You don't have to really worry about it. It's just really working out what people are thinking. Okay, so what we're gonna do now is try to use based on how they responded. We're gonna try to understand what kind of assumptions the thinker had, okay? So first I'm just gonna leave this open initially and then I'm gonna do a little bit more guided thing just to, because I'm gonna try to point out certain things. Okay, so does anyone wanna share a kind of response that they heard that they go, okay, that was interesting. I think this means the thinker believes this or something like that. Anyone wanna share one? Okay, yes. I think it's a very much pressure. What? It's a very much pressure like I need to do that. Yeah, it's an odd expression. What? Thinking is an odd thing to do. Okay, yes, anyone, there. Interesting, so what he said was that the thinker was trying to deal with all the problems and thought he had to solve, he or she had to solve everything. Now, there's an assumption here that in order when you see a situation you need to do everything and go, if we think of from an agile perspective the reflex should be that I'm not gonna solve everything, I'm gonna pick the important things and do it that way. And that should be reflex, right? So okay, that's interesting, what else? Good, okay. Okay, so what she was saying is the thinker thought about breaking down the problem into smaller steps and then working how to deal with that. So this ago, does that reflect an agile assumption? Yes, it is one where we go, by reflex, we say I don't do with big stuff, everything that's big, I make it small and I do that for everything, even under stress. Okay, next. I should really go to the back, I'll go to the back, the furthest back person there. Oh no, her, she's just all the way back there. I'll take you next. That's not very nice. Okay, yes, but that's fine, right? But again, we go, what timeframe are they default going to? So under stress they go, oh, I think about what we need to deal with the current situation, but what about the long-term one? Now this from an agile thing, it's kind of interesting because we have probably a little bit more sophisticated view here, because it is deal with what you need to deal with today, but there's always, especially with the refactoring stuff, there's always this view for how you deal with the future, but you don't necessarily do like a lot of extra stuff there. So it's a little more subtle. Okay, there was someone in the middle. I think that everything is not equally important for the customer. So we need to prioritize what is important for the customer and what is less a priority for them. Good one. Okay, raise your hand if your thinker concerned themselves with what was important from the perspective of the customer. Raise your hand if they didn't, that instinct, right? So, but okay, this, but I go, I kind of make these jokes, whatever. It's not so that you go, oh, I feel bad about myself. It's so that you go, now I can see what I can correct, that there is some gap here. My reflex, my assumptions, my culture is actually giving me an answer that maybe doesn't really line up with what I might say that I wanna do, okay? So this is a good one. When you see a problem, you are first, kind of an instinct, again, is what is the purpose of this? In a market situation, it'll be what the customer is, but it could be anything. Like what is the purpose of this? Before I decide how to break down the work, I'm saying what am I actually trying to do as an overall outcome, okay? I'm going to keep moving, okay? The basic thing, whoops, that's not gonna work. The what I'm trying to show here is really how this particular exercise is trying to show, highlight this stuff. So let me show this again first. Actually, while I am trying to do this, who's, anyone else have another thought? Well, I don't do this, over there. You know, basically I had certain assumptions around what are the resources that I wanna be required on the SIFT skill sets that will be required considering the new things that are required in terms of framework and a few other things. Yes? Plus, there was something around Delta. Is it the same thing that the customer wants, or is something more apart from for its business expansion? Okay, let me see. So that's more like trying to understand, yeah, looks like my machine just locked up here. This was more about understanding what resources are available and sort of the characteristics of that and whether that's changing, right? Because you have different skill sets. We have probably different technology, et cetera. And then you're also talking about what? Also from a... Okay, I'm gonna shut this machine and turn it back on. Okay, what we can do is, I know what the next slide is, so I can just talk to you about it. So what I want you to do now is, so you got a feeling for what I was trying to do here, right? So what I want you to do is take a look at what the thinkers, so together all the scribes and even the thinker themselves, right? Get together, look at the stuff that was said there and try to get a quick summary of what you think their assumptions are. And then have maybe a brief discussion talking about how would you modify this so that it's more of a, this more reflects agile culture and then we're gonna try another round, okay? So it'll be a little bit more controlled now because then I'll say here now you've sort of deliberately you're trying to guide your assumptions now to respond more effectively, okay? Does that make sense? So take a look at what you've done, describe what that is, work out where the kind of the holes are, adjust it and then I'll give you another scenario. What you're doing right now is try to make sure you cover up these type of questions. So how did they approach trying to think about what the essence of a problem is? What is, again, what's the assumption there about what do I do to find the essence of a problem? Anything that they did that was about who should be involved? So I didn't ask the question, you know, who did they, again, reflexively get involved in working out what to do? Did they tend to say, oh, I just, I should be solving it myself. Do they have that assumption or do they have this assumption of I should get other people involved, all that sort of stuff? And how should solutions be approached? Even like when we talked about the sort of the thought that I should generally break things down, like that, all those sort of things, okay? So make sure you cover those aspects, okay? And I will give you another minute before I talk about something else. Actually, I'll show this too, okay? So this is a couple sort of thoughts, if you will, of some assumptions that I think are part of Agile culture, okay? So, and this is the first one is about who do I get involved? I get the people who are closest to the problem should be involved in the problem solving. I don't really want to comment on other speakers, but let's say if I present something where I go, the way to solve this problem is I will get a dashboard at a, you know, and I'll be sitting in my office and I'll look at stuff and I'll work this out, that doesn't reflect that first assumption. I reflexively have a problem with it because it seems wrong because I believe a particular thing. I go, that's creating distance, cool. I create distance between what's going on and who would know how to solve that. So I go, that's wrong because the assumption's wrong. That's kind of a cultural thing than anything. The second one, it's better to take smaller stuff. As you mentioned, that thing, which is a nice one because I, you know, we didn't prompt it, but that thing is that reflexively occurring and I know that is a sign that someone has done it for a while because they just do it. They don't think about it anymore. It's always break it down. It's just reflex. And the next one, validate after each test. So if people are, you do test-driven development, all that kind of stuff, when your reflex is you don't do anything until you know how to check it and you always check it, you don't just kind of run. Then again, that's reflective of an assumption. It's a cultural thing at that point. And the cleanup as you go is kind of the refactoring thing that you don't leave a mess. Okay, so those are things I might propose as how you might frame things, but use whatever your particular table came up with. So before we continue, is everyone comfortable that they kind of have an idea, okay, this is now agile culture defined by, you know, three, four people? Is everyone good? They're ready to go? Because I'm gonna throw another scenario. The next one may be harder than the first. Okay, is everyone ready? Okay, so this time we'll use the same speaker because I wanna show what happens when you start deliberately changing it. I sure hope this thing didn't just block out again. Oh, this is very annoying. Oh, no, it worked. Okay, excellent. So yeah, we'll use the same speaker this time. If we have, I think we have enough time is that we'll rotate so other people can try it out. It's actually interesting when you are being observed. So it's always good to go through. Okay. And enter. Is it gonna show up? Because some people might not be able to see it. Oops, let's make that bigger. And number two. Okay, this one's called specialist. So you've had a recent attempt at planning but it's gone very poorly. You tried setting up two week time boxes by first getting idea of capacity, so kind of velocity. Then you ran some estimates and you chopped up the features to fit. Then you were gonna run the iterations. Okay, the problem though is that your team of five people, they don't have a lot of skills overlap. So I have one person who only knows how to put together reports. Another one only does drug data so that you are working for a biomedical firm. And she's the only one who can or knows enough and is authorized to do it. Okay, another is strictly a database developer setting up non-drug data but spends 50 plus percent of the time dealing with ad hoc requests from the business related to that. Okay, another is a manager slash business analyst who can write a little sequel and a little C sharp with help. And finally you have a .NET SQL server developer. Okay, a lot of your work ends up being so individual dependent that it's straining your team as one unit approach. So it's hard for them to feel like a team because everyone's doing their own thing. Even if something is a priority for an iteration we can't devote our full capacity to it because we'll overload a particular team member. So you're getting an individual kind of constraint. You've been brought in to help fix this situation. In this case you're not the manager you're kind of brought in to sort of problem solve it. How do you respond to this? Okay, any, everyone ready? So again use the new kind of culture you've developed to try to respond this which will make it a little bit different because you kind of think about it a little bit more but try that. Okay, I'll give you five minutes. Although these are actually real problems that I kind of pulled together. So and some of them they didn't actually solve it in real life so that's why some of them are not winnable. Or maybe they're not good enough to solve them. Okay, so any again same thing as we did before does anyone want to share anything where they say that was an interesting response that also highlights a particular way about how what their assumptions were what their culture is. Yes. I think of some big questions. Yeah. I'm not really looking at what the best solutions can be done. Okay. Here the thinking was like I didn't have to do a solution they're just having questions and also questions. Okay. This is kind of interesting so what she was talking about is the initially in the first scenario the thinker had a lot of questions but they didn't kind of move from there. Yeah, so this time they actually said okay I can still move and try something, right? Now this reflects something. So typically in an agile sense we'll have this thing where you go I will move with partial information. Okay, that is a again an underlying assumption. I don't need to know everything before I take action because the action itself will teach me about what to do. That again you'll see this where some people don't believe that. They don't, it's not a sort of built in and they won't act. They say I need to gather everything first. This is the whole, you know I need to know everything before I start, right? And so again you get to that reflex where you will change your behavior, okay? Anyone else? I saw a lot of hands shoot up but I didn't catch them all. Next table here. Here the thinker was thinking, first of all she was thinking about the person being involved in the outside for solving the problem of the day. Yeah. And it was because he had one of the problem areas and then for what he used to do that. Okay, so it just kind of broke down the particular. Yeah. Okay. Did anyone, I'm just curious, anyone again think about customer here? Okay, can someone provide an example of what kind of thoughts relate to customer? Sure. Oh, yes. Okay, get the customer involved, right? So you say, hey, we're a team we're producing something for somebody. Why don't we get them involved in designing this, right? Because eventually we're talking about an outcome produced for them, right? It's not actually just the team's problem per se. It's actually the system has a problem and we'll get the players involved to say, okay, how do we play this out? Because there could be something else here that we don't know. Because this as presented, it's just presented as an internal team issue. And I'd be very skeptical based on what I was described here that that's the case, right? There's set of clues of that. What's that? So from planning perspective, what is potential shipable product after the spring? So that comes with the customer perspective. Yeah. Yeah, it's a kind of interesting thing because there's no specific thing there that says that. But if you have the right instinct, it'll just come. You'll just do that. Okay, someone else had another thought. How about there? So we also talked about perspective because we get together with the team and then understand what is working well versus what is not. And then maybe seven of them is interested in moving to other side, et cetera. So you can ask them shagging, et cetera, et cetera. I'm gonna have to answer that later. Yeah, so the kind of thing which I kind of alluded to which is why I mentioned the other stuff when we talked a little bit about it is that your reflex shouldn't necessarily be, okay, I'll solve the problem for you, right? Because then you go, yeah, what happens when you walk away? Then the next one will come up because it's not like they won't stop having problems. So what do I do to help enable them to kind of work that out as opposed to do this? Now, again, there might be context here if they're in an emergency, you might say, okay, we'll just deal with this but from here you don't really pick that up, so. Okay. Think about thinking about pairing. What? Pairing, yes, okay, so this comes down to how would I resolve the sort of specialization problem? Okay, I'll jump back to the table to the back first. Stripe shirt. So thinking about in an agile, everyone should be multi-talented and if they are not reduced about the bottlenecks, introduce their program, do multiple attempts, coaching should be there so that it should be, anyone can handle the problem, it should not be at all the like, it should not be SQL or something, like you are an expert into that, but it should be, someone is there to deliver. It should be rules-based. Okay. So that was, that one was about, sometimes a little bit wary of this one because it is almost saying, what should happen in agile is we have people that are generalist, cross-training, can do lots of stuff. Now, in and of itself, that's kind of, so okay, that's not controversial. The thing is with this particular scenario is that how I would think about it? Because let's say at this moment, the amount of time necessary to get them to that state might be too long. So this is where we say, hey, can I get the right people involved to work out for this moment, what do we need to do? So you still have the collaboration, but that particular solution, which might be a more medium to long-term thing, we have to kind of might have to defer that or we'd have to work our way, we have to do something in the meantime. Okay, I'm just gonna grab, there's someone at the back there and then I'll come back to you. Yeah, you've been holding your hand for a long time. Okay. Yes, did anyone think, is this actually a team? Did anyone make that ask that question? Is this actually a team? Anyone ask that question? Yeah, a couple of hands there. Yeah, because that's one of my first instincts is they, they have a bunch of people that happen to be grouped together, but they're not really a team per se. Like they don't really work together. They just kind of, they just do stuff that maybe they sit together, but that's about it. Okay, yeah. Come from a different skill set. Yep. So the thinker will also see how, how that brings the best or the strength of the team and the weaknesses of the team. Ah, good. And to enable communication between the team and to see what best can be delivered by each individual within the team. Okay, so that was about trying to understand, it's almost like understanding the individuals of the team as like people, as opposed to this role thing. Like who are the people do I actually have? What are their strengths and weaknesses? All that kind of stuff. And then saying, then design something with those real people that will work. Okay, I normally talk about when, like I think sometimes when we talk about roles, we think those roles are real as opposed to something we designed. It's a construct. The actual people though are different. They don't fit perfectly in that role. And if we are dealing with the actual situation, we need to design for what's actually there not for this kind of theoretical construct of roles and whatever. Okay, so again, that's a good, again, it's a kind of an instinct type thing where do, will you naturally recognize that? Where you say, hey, people are real things and these things are constructs. Do you do that? Or do you kind of go into this kind of almost like a conceptual thing and you're dealing with all these abstract concepts. Okay. Any other questions? Otherwise I'm going to move on to talk about some other stuff. Okay, cool. Okay, let's see. Yep, same thing. Okay, so it's kind of like an overall debrief. So this is the kind of exercise I'm talking about. If I was doing this in like, this is supposed to be workshop and, but it's not really training. If I was training, we would be smaller group and I'd be much more focused. I'd probably be, I'll call it meaner than I am here because I'll challenge you more because I'm trying to get you to go to that edge. But this is just a taste. Does anyone have any thoughts on this type of approach to help people kind of learn about things? Does anyone have any thoughts on that or questions? No? Yes. This helps to know different people, different thinkers are having different parts. Yes. And how, like, what is a real focus on this kind of problem that we have? Yeah, so the, he was just saying that this helps you see how people think about things. So, like, I could talk to you and I don't know how you respond to a scenario, right? Because we'll just be talking about things. We can talk about concepts. When I expose you to scenario and then you expose your thought process, now I know a lot more about how you respond. I can, I have actually a much better ability to predict what you'll do in a scenario that we haven't even described yet. What I've done previously is I have people at different skill level who can do this so you can also see, oh, I wonder how Jason would respond to that. I can show you. And then you can say, hey, I responded differently. I did this, what's going on here? What am I, sort of, what's underneath what I believe that turned into this response where they respond to different things and get a better sense of what's different and it helps you learn a lot more quickly. Yeah. Apply this in a workshop like scenario. Yeah. But how would you apply this in a real world Excellent, good question. Excellent question. Thanks for asking it, because that's what I want to talk about. Okay, so. Can I ask you this, I mean, you defined some couple of scenarios and then it's up to you to bring those to the difference. Yeah, that's good. So, like what I did this originally, it's all designed for workshop. It was designed for training small groups of people. So you, I would normally say, I don't like using any more than about five or so when you're doing it as a thing because there's a lot of discussion that happens within that group. Actually, even now, there's a lot of discussion that happens within the groups of the tables. But you have, it's still similar sort of thing. You put up the scenario, you do this thing, you may not do it like this. So the approach I use now is you have this kind of two roles to think or scribe. I can also have a mode where I just say every, because I'm training everybody, everybody is, they're not thinking aloud, they're just writing down everything they're thinking, right? So you capture it. So I like have, everyone's at a whiteboard and while they're hearing this thing, they're just scribbling down everything that's passing through their head. And then we'll go through each person, they start talking through that. Okay, so that's a different scenario. The, and then you have more of this, more close interaction. So here I'm kind of standing up here watching. I might be with you there and then we'll be going through each thing in more detail. Okay, then, and I would also pretty much challenge every point. Like every assumption you have would be going, okay, what's going on here? What's going here? Have you thought about this? Okay, and then that helps you bring it up. Does that answer your question? Oh, this is not a, it's like, let's say what I'm describing here is more of a, an exercise for you to practice when you're not in the middle of something. Now, if you want to, you know, we want to solve a problem per se, then you could still do this, I guess. And they just have everyone, it's just more like solving a problem, but talking more fully. So exposing everything that's going on, but that's just more like saying, instead of just saying, hey, we should do this. You say, hmm, this is the situation. I'm thinking this, this and this, so therefore I think we should maybe do that. You could talk like that. That's kind of weird though, because people don't talk like that normally. But it is a way to, so when you're having a dialogue about how to solve the problem to make sure that we're on the same page about underlying things, not just the specific action. So you could do that. I've never done that before though. So, I don't know. If you try it though, you tell me if it works. What would, so what, how can I tell whether the assumptions I take are useful? You're saying such an exercise can ask you to be useful. If you're making some assumptions, like you know, the rules of engagement are the same, right? What if you have an idea about saying that that's not going to work in my work place in my life? Ah, yeah, so okay. I'm not going to go to this takeaway because we actually have enough time for another scenario. So I'll do another scenario first. So just to answer your question. So what we'll do is I'll answer these questions. We'll do another round just so we can try another person, get it tried out. And then I'll talk about takeaways. So, the question was about how do I know the underlying assumptions are applicable across scenarios? Is that, is that pretty much what you asked? So different scenarios, how do I know the assumptions that I'm going to hold across them are going to hold like are going to be good? What I'm, the only thing I say that'll help the team is if they are metacognitive, if they are thinking about what is underneath their thought process, if they do that, I'm very confident that they will perform better, that they will be more reflective. Their ability to respond to new things will be better. The other thing is, do the particular assumptions that I say or agile assumptions, will they help in multiple scenarios? Again, that's, I would say yes, that's why I kind of put it up there, but could I be wrong? Could it be that what I say is underlying how you sort of approach agile is that maybe those, maybe my thoughts are wrong? It's possible, I wouldn't bet that way though, but I'm speaking here, so I'm not going to say that, right? Like I wouldn't propose it if I didn't believe that it would work, but it is entirely possible that my assumptions are wrong, right? But that's why we have the first part. As long as that team is sort of reflecting on itself, I expect they would correct it. You would notice over time that it's not working. I'm relying on my experience to say, okay, this is what I think can help you survive independent of what you see. I don't even need to describe this scenario. If you think about this in a particular way, you will survive it. And you'll do well, because that's how I do it. Yeah? Yeah? Yeah, just a comment, which is pretty much a comment on this metacognition thing, the what Chris Argeris calls a double loop learning as well. This type of thing is useful in general. When we get into the specific kind of cultural things that you can argue with it, you could say, hey, I don't think that's agile culture. I think it's this. And we can talk about it and then we see who wins at the end. But when we're talking about practicing culture, when I propose that as what this is about is practicing culture, I'm effectively saying practicing metacognition. So how do you kind of get inside yourself and then see what's going on and getting better at that so that anything could be happening out there? And it's okay. I can deal with it. I don't, I'm not pattern matching. Okay? So, yep. Of course they are. Right? So it's a thicker influence by agile knowledge that they have. Yes, of course. But that's part of it, right? There's influences all the time. But what we're checking is I can actually succeed in, the reason why some of these scenarios are very, all the scenarios are very difficult is because I don't want to give you an easy one. Or I say, hey, in this scenario, what do you do? Well, this is an A to B type thing. When you do this, oh, create user stories. That's, I don't expose anything about your assumptions if I give you an easy thing because all you do is pattern match it. Right? So that's where the knowledge kind of kicks in. But all of these are complicated, complex enough that you can't do that. You can't, it's not an easy fix. You have to get down into how do you think about it to deal with it? Okay? So everyone's sort of filtering out. So does everyone want to do one more round and then I'll do some takeaways? Ready? One more round? We'll pick a new person now. So who wants to step up to be the new thinker? Okay? And and it decides the blackout just when I was gonna do that. Do, do, do. Oh, scenario number three. So new thinker now. Scenario number three. You are, you've been assigned to manage the transition of a company with an established waterfall mindset to agile development. And this transition impacts several groups. The business analysts have been writing very detailed use cases that in their eyes meet the needs of the company but were too mired in how a story would be implemented without providing the why. So that just means their use cases are very implementation detail oriented but they're not really about, you know, what's the motivation and intent, all that. And very little of the what. Quality assurance is used to, is used to writing test cases based on the use case. In their eyes, once the test case is written the code has to match it in order to pass. The business wants to fix a budget and delivery date for the expected functionality ignoring the constraints of the project management triangle. So, is everyone familiar with project management triangle? Kind of like scope, quality, cost? Yeah? Okay, how do you respond? So now you are responsible to manage this transition. Okay, this one's a little harder. Off you go. Give you five minutes. Our thinker test is like will-do pilot which is trial environment. Okay. So with a particular means, bunch of features we will take a few parts and a smaller team. Okay. Try to show it, yeah. It's kind of a, actually the thing that I picked up as well is it's hard to talk about the abstracting so showing someone something is usually a nice way to do it. Okay, anything else? More detail here. What else? What, is that all they said? Of what? Go out of the pilot or not. Okay, I was thinking you were gonna suggest something about why are we doing the agile transition in the first place? Anyone ask that question? Yeah, that's a good question because most people don't ask. They go, how can I tell if I can, how can I validate this? How can I tell if I've done it well if I have no idea why we're doing it in the first place? Okay. Again, that's reflex. It needs to be reflex. You know, built in like gravity. Don't question. Always ask why. Okay, anyone else? I guess we can involve business too so that they don't come back and fix the project. Good, yeah. So this is kind of the indicator here that are the right people involved in this because you go, why are we getting this kind of weird thing because there may be another not involved? Okay. I'm inspired by a lot of the various steps that you can see who just developed in the same way that they might develop in the kind of. Okay, so you just kind of do, you start laying right in, yeah. Lots of feedback cycles. Yeah. You probably done it before. Yeah. This one is a little bit harder than the other ones because the scale is much larger. It's much more open as well. There's not as much information. So it does expose, you know, how do I approach something like this which is even more vague? So it's not as easy to do. But yeah, that's interesting. So you were just talking about spiraling through this problem just as you would like a delivery. You just kind of go work your way through steps. Okay. Yeah. Yes. What's the context? Okay, so that was just talking about understanding the context, like what are the factors involved here? What are the constraints? What's the size of the organization? How many people are involved? Probably industry, whatever, like whatever. All this stuff. And also saying who are the stakeholders? How much buy do you get from them? Similar to the why are we doing it perspective? Yeah. Yeah. Yeah. Okay. So that was just talking about understanding the context, what are the factors involved here? What are the constraints? What's the size of the organization? What's the perspective? So like if you go, hey, half the state, let's say all the business stakeholders have no idea you're doing it and have no interest in it, you're probably in a bit of trouble, right? Versus, you know, and you, that changes how you're going to respond to this because you know, in different contexts. Yes. There was a thought on taking small steps towards breaking the values to the thought process. Are you switching from waterfall to idea? Oh, just breaking down. Anything in particular though? No, I'm just trying. In, I believe culturally, so to get them in the same room and get them to discuss the same requirements. Okay. Again, try to get the players, all the people who are involved in the problem, get them together and kind of get that first before we then we work out what to do. Okay, yes? Got one dilemma or one question. So can we run in a model of say half waterfall and then continue with Haji? For example, business analysis is done in some sort of waterfall model or architecture is done in model. So that's, that typical questions are actually also come on the floor also in companies and projects. So what you're kind of, yeah. So this is, let's say the question that's coming up from the thinker is that how do I break up this problem? Can I split this in a particular way? Could I split it up such that it's split by role or do I have to do something differently? Okay, Ash, I'm gonna ask the question. Can you split this up by splitting by role? Is that gonna work? Why not? What's coming to mind? Why do you believe that I don't want work? Feedback loop, right? So this is a, you could still probably do something, but yeah, you're gonna be constrained in terms of how you, that feedback loop will work because you can't complete a cycle on your own. Yeah, does that make sense? I can't complete a product feedback cycle on my own, right? Because I'm only one piece of it. So, which means my view of whether what I'm doing is effective is, it's very difficult to pick that up. When the requirements are very course-defined and you start building, say, architecture or design for that, and now the things are getting changed, your architecture undergoes lot of iteration changes and that is whether what we started with is going to work or not. So rather, come to some level, have some basic requirements ready, then you start working on the. We're getting into almost trying to solve this problem, so I'm gonna step away from that, right? Because again, I don't care about solving this problem. We can talk about how I would approach something like this in detail. The main thing is what do you think is important? What comes out? Because that's talking more to about what's happening in your head, okay? So let's just close this up. I'm gonna just close this one a little bit earlier because there's no point in extending it. The kind of takeaways, and I have a whole series of these, so there's lots of scenarios. When you actually do this yourself, if you wanna do it yourself, you don't need to, I can share these scenarios if you like, but the more interesting thing is use scenarios from your own situation. You can ask every all your agile teams or whatever ask various people and just say, just tell me the most difficult scenarios you have to deal with that are kind of agile related and we'll collect them all up and then yeah, we'll just work them, right? Because your own scenarios, you can kind of play through them and work out what's going on. Again, I should point out, it's important, I think, to make them difficult ones. You don't want the easy ones. You could sort of say, hey, can we deal with easy ones? But I just don't think there's enough value there because you can just pattern match your way out. You can just say, if A, then do B for those and it's not hard enough to force you to think about, okay, how am I approaching it? Okay, so that's what I would recommend. But the takeaways, the ones I wanna point out, things if you wanna remember anything. When we're talking about culture, so when I talk about culture, it's not a throwaway term. I'm always thinking about fundamental underlying assumptions. I don't care as much about the theater. If you want to annoy me, talk about culture and just talk about theater and I'll be going, ah, it's crazy. Right, because there's something underneath that that's more important. All those other things are just side effects. They are generated from that. Okay, you can expose those assumptions now. I should say, you can expose them by thinking loud. Obviously that theater is a reflection of the underlying culture, so you can use that to indicate what's underneath. It's just not, it's not perfect. So you can expose those assumptions by thinking loud, either in this kind of group type work or even just yourself. You can just do it yourself. And changing our assumptions, otherwise known as the culture, changes our response. So when we start being much clearer about what we believe, what we assume, we start being able to change how we behave. Okay, sometimes you won't go that direction. This is more for when you are actually more familiar with the activity, like for the skill and you're trying to go to the next level. Okay, and I think that is it. So, any final thoughts or questions? Yes? It was based on the assumptions, but assumptions from the values that you thought. Oh, now I'm saying the culture are the assumptions. Yeah? Let's see. Okay, so formally, so if I fall, shine formally, culture is all three levels, everything. Artifacts, behavior, state of the values, underlying assumptions, all of that is called culture. I tend not to talk about this as culture, I just talk about this as culture, but you could call it, that's the essence of the culture, but culture is actually all of this, right? Now, when you say values, it depends. If you say values as in, here's my value statement, or even agile manifesto, if you show that out, I say that's not values, that's the stated values, that's what I tell you what my values are. My actual values are what we expose here. How I reflexively respond, what do I normally do? Like under stress especially, that's my actual values. Everything else is just me talking about it. Does that make sense? Are you ready to be aware on the end result, is that one? And then you start saying, okay, yeah. I will tune that. Yes, then you start tuning from there, yeah. Yeah, yeah, no, that's okay. Can I even ask you a follow-up question? So, we talked about one very important takeaway for me is that first decide how would you check something before you even start doing it. First have your validation measured in place before you do it so that you will know whether it's working or not. So if I take this exercise and say that if I would have, see the whole thing, you started off saying that if you're the army, you should train yourself to think like a commander. Yeah. That's what you're trying to think like an Aguilist. Yeah. So a validation would be that the values, because under my assumptions, once I'm aware and I'm thinking it, it would get reflected in my behavior. Yes, if you want to think about that. Yeah, that's one part of it that I could say, because the visible behavior does give you information about what is probably what their assumptions, what their values are. It's not enough because there's usually a lot of situational factors involved. So they may not have particular assumption, it's just the system, the structure causing them to behave that way. But if I switch that context, they might do something that just doesn't make any sense because they didn't have, that culture wasn't strong. It was just, you're just seeing the result of situational forces. So the behavior itself won't be enough to check that. If you put them through situations and vary it, I just throw them through a lot of different situations and they still go, oh, okay, it all tells you this and you go, yeah, that's kind of validation. That's just some, like that's one aspect of it. The other one I go like, which is also like similar to the army one is that the ultimate validation of course is that they perform better. That from an outcome perspective, you know, why are we doing this in the first place? What is, why are we doing the agile thing? Are we getting the outcome? That's another thing. Again, sometimes the situation overwhelms it where you go, it's not like, did I succeed in this one scenario? But in general, am I generally succeeding? Because, you know, you get variations just due to market forces or whatever as well, okay. Any other questions? Otherwise, that's it. Okay, thank you.