 and get started. Good morning, everyone. Good morning. You guys still excited? Yes. Yes? All right, great, great. So we're here to talk about value teams. And actually, Jeff, in his keynote this morning, who was there? OK, great. So it's actually a continuation on one of his learnings that there is a team around a product owner, not just one. So we're going to actually take a deeper dive into that. I didn't know Jeff's keynote was going to be about that, but he really set me up pretty well. All right, let's see if this clicker actually works. All right, so let me give a quick introduction about myself. My name is Ahmed Sidki. Basically, my background is a developer, started my career as a developer. And then after doing a number of years in that and helping deliver many different projects and managing them, I did my master's in requirements engineering, which was a very interesting shift for me. And I couldn't stand it really after I finished it because it was very theoretical compared to a very practical background for me. And that's where I found Agile. It was through my research, and this was in 2002. So I remember going up to my advisor and I told him, I can't continue my PhD on the same topic in requirements management, but I'd love to create or invent or discover a way of working that actually matches how people work in real life. And as you can imagine, a very old academic person looking at me and smiling, and he says, good luck. I don't know if that exists. And so I set out on this journey. And anyway, long story short, I did my PhD in Agile adoption and agility assessments from Virginia Tech. And then since then, I've been training and consulting with many different companies around the world. And recently, I joined Riot Games as their director of development in LA. Co-authored a book called Becoming Agile in a Perfect World, president and co-founder of the International Consortium for Agile and some of the other stuff. But anyway, let's get started. So before we get started, I'd like to make sure we're aligned on some of the basics, because maybe we're actually not aligned and it has a lot to do with what will be coming up. So one of the things I feel very strong about, and I hope you guys agree with me or else we're going to have to shift the topic of this session, is that Agile isn't a process. Agile is not a process. Scrum is a process, XP is a process. But Agile itself is not a process. So what is it? I like to define it as a mindset. So Agile is a mindset that in and what is this mindset about? By the way, let's go back for a second. So this mindset is about welcoming change, early feedback, learning and discovery, right? That's what really this mindset is about. It's not about trying to freeze things up front and trying to just deliver them. So this mindset in the software world is established through four values, which we take from the manifesto, right? Grounded in 12 principles and then manifested through an unlimited number of practices. And the moment you limit the number of practices is the moment you've limited your agility. So we want to keep the number of practices unlimited. And really if you think about scrum or extreme programming or your own Agile process, it's a blend of these practices in a certain way of working that works for you. But Agile is really this mindset, values and principles and that's where the foundation is. So you guys in agreement so far? Yep, just reviewing. A lot of people, for some reason, focus on doing Agile versus being Agile. And that really comes from which orientation you're looking at. If you're starting from the practices, you usually end up doing scrum, doing XP, doing safe, doing whatever. But if you approach it from the values and mindset, that's our hope that you would internalize the understanding of what Agile is and then you tweak and adopt your practices accordingly. The reason I'm saying this is because one of the things we'll be talking about today is a practice that didn't exist before, right? And if we were more focused on the doing of Agile, people would tell me, wait a minute, what you're doing is wrong. And the whole point is it's about being Agile and changing the way we work, depending on constraints that came about. And basically the idea of value teams, as I'll talk to you guys about them, came from real constraints that I found as I worked with organizations and therefore, again, sort of living the idea of being Agile, change the way we work accordingly. Now, all this Agility stuff, why do we really need Agility? All right, and again, I was gonna spend a little more time on this, but I think Jeff really nailed it in the morning. So I'm gonna show you a short video and then we'll get started. You guys don't get, no. Ooh, ooh. I lived for 15 years in Washington. But it really sucks to be him. And I think this is what Jeff was talking about, which is one of the things that's interesting about Agile, we're getting really good at output, right? And getting more efficient in output, but really outcome and impact and are we delivering the right product is really the most important part of it, right? So we need Agility in order to make sure we're not delivering the wrong product. And why do you need Agility? Because you think you're going to build something that's valuable to the user and you plan based on that and then you can validate or check or you get information that, guess what? That assumption you had was wrong and now you need to change. So that's why we need Agility. Now, how do we discover what we need to build? How do we actually do that? And there's interesting, when I show you this picture, what do you guys see? What do you actually see in this picture? A lot of rework. What else? Changes. Does your work look like this sometimes? Most of the time. Is this good or bad? Very good. Would anyone say it's not so good? Like, that's a lot of changes. I mean, isn't there a cost to this rework? Well, is it rework or is it refinement? Yeah, I didn't hear a consistent answer there. This is definitely done after. Like, the guy wrote it on a typewriter and then started editing. So it's done after. So would it be rework or refinement? That's rework, refinement. I'm just gonna sit down here and have you guys debate this. Because this is actually at the core of it because rework is good or bad. Rework is bad. Like, you did work and now you have to rework it? That's a waste of time. Minus one on your performance. But refinement is good. Refinement is innovation. You're actually finding a better way to do something. So it's actually really important that we align is this rework or refinement. Now, let's ask this question. Could the guy have actually predicted these changes before he wrote what he wrote or not? Okay, who's written things in the past? An article, a book, a long email, yes? You know which ones I'm talking about. Which you read for ages. Yeah, okay, so if you've written something in the past for school or for work or for venting, whatever it was. All right, you have an idea of what you want to write, but do you know the words? Can you sit down and plan? I was like, okay, I'm gonna say these words in this sequence. Or is it when you write it and you look at it, you discover what you want? Okay, are we all aligned? Are you sure? So there's no way this guy could have predicted the changes that he wanted to do till he actually did it. Are you guys in agreement? Anyone write differently here? And then, by the way, if I gave him more time, what would he do? Keep refining, right? And there comes a point where there's like, okay, it's good enough. Or if you remember back in the days when we wrote on paper, right, you would look at it, even if you found a better way to write something, you would look at it and it's like, oh my God, I'm gonna have to erase this. It's good, it's good, let's just ship here. The cost of change was actually really high. And so, you know what, it's good enough. Now, this phenomena has a name, and you may have heard this name before. It's called, I don't know why this clicker doesn't like me. It's called icky wissy. Okay, can you say this word with me? Icky wissy. I hope it doesn't mean anything offensive in Hindi. Does it? It's good? Okay, so icky wissy stands for, I'll know it when I see it. And that really summarizes a lot of the kind of work we do, right? You don't know if a user interface is gonna work or not. You don't know if a capability is gonna work or not. I mean, this is, like I said, Jeff really helped me out this morning, right? All these things we're talking about are unvalidated assumptions. And it doesn't matter how long you're gonna sit and plan for it. It's only when you, actually, it's not even when you see it anymore, right? It's when you experience it. Now, if you try to change the acronym, it doesn't sound as good. So I keep it icky wissy. The other one is icky wee wee. And I don't like that. But anyway. So all this to say one thing, there's a lot of discovery that is happening. There's a lot of learning that happens and needs to happen as we build things. Fair? Are we aligned? All right, so let's start on the value teams. The world pre-agile looked something like this. Siloes. We had developers in a silo with the development lead. And then we had analysts and testers and poor old project managers were in the middle, right? Had to sort of figure out the coordination between what these guys want and these guys want and any project managers in the room? Project managers. So you know these nice days. I see tears in the back. It's okay. It's okay, guys. This is pre-agile. It's okay. And then, of course, the famous matrix, right? Where you took one project manager and you assigned them. I was like, you, you, and I don't know you, but come, right? Let's just bring you. We're gonna make a team out of you guys and let's deliver awesome stuff, all right? And this was sort of how the world worked. Now, one of the fascinating things that Agile brought and specifically Scrum was this idea of a team instead of a working group, right? So we changed what the picture looked like on this side and said, wait, wait, wait a minute. Forget this. Let's actually make them a team, a real team with a common purpose. So right back here, your purpose and your sort of affiliation was still to your silo, right? And in some organizations, to talk to the tester, you have to go up and down, right? That's even if you knew who the tester was on the team. Because sometimes they separate them in a different building or because of quality control. But anyway, the point being is we created a team out of that group. What are the values of having a team? What benefits did we get? This was an interactive session, right? Just making sure. Better communication, collaboration, what else? Unity of purpose, team identity, excellent. Now, all these things, are they like the touchy-feely stuff or did they really have that? Seriously? What is it about? Outcomes, okay. Learning faster. How did that happen? How did we learn faster? Uh-huh, excellent, and? Very good. Better flow of ideas, yes. All of this, perfect. And we had this nice role called the Scrum Master. What was the role of the Scrum Master? Facilitator, great. Now, we picked someone from these affected stakeholder group and we said, you are the product owner. I like you, so I'm gonna make you the product owner. And whether he's on the team or beside the team, that's a debate I don't wanna go into right now. Doesn't make a difference. But the product owner is sort of with the team, okay? And, but do we know how the product owner gets his or her information? Do most teams know that? No, but we have our product owner, right? And we ask him a question and he says, let's do it this way, okay? Are you sure? Yes, I'm sure, why not? What do you think of the priority? Let's take number five, put it at number one. Are you sure? Yes, I'm sure, okay. And he's the product owner, right? So he's accountable for these priorities. But we actually have no idea. Like, dude, are you talking to the other people? Right? Yes, I am. And we have all these trainings on how to have good product owners and all that kind of stuff. The challenge really is, and you know, the punchline is where does most of the discovery need to happen? Here or there? More, right? The discovery happens on both sides. But we're really focused, this team helped the flow of ideas, collaboration, all this awesome stuff here. What about the other side? Is there any form of collaboration that's needed on that side? Right? So the basic idea is, let's create a team out of them. I'm done with the presentation, any questions? No, really, that is the basic idea. I'm gonna go into a little more of the mechanics of doing this, but this is really the idea. So we want a team on the other side. Now, imagine if all the benefits of what we got out of the delivery team, we actually got out of our stakeholders. Because sometimes, just to go back to slide, and tell me if this has ever happened to you. We're getting direction from the product owner, but this governance guy, right, steps in and says, wait a minute, that's not gonna work. And you start having multiple product owners. Does that happen to you? How does that work out? How do you prioritize? How do you, who prioritizes actually at that point? What is prioritization? Why do we exist, right? Now you start to think about these deep questions in life. So the easier aspect to do is to create a team out of them. Now, first of all, I wanna abstract up from scrum terminology. So from this point on, I wanna use generic terminology. The reason I wanna use generic terminology is we're not mapping to scrum anymore. And if you try to think of this in terms of scrum, and what the typical roles of a product owner or scrum master is, it's not going to work for you, right? So I'm gonna abstract up, and I'm gonna call this a delivery team. I'm gonna call this a value team. I'm gonna call this guy. I'm gonna give him a totally new name, right? And if you wanna give him an acronym, it's DTF, or come up with something cool. But I'm gonna call them delivery team facilitator. Because you're not a master of anything. You're a facilitator for the team. And I'm gonna call this guy value team facilitator. Is that fair? Right? Equal opportunity on both sides. Now, the other thing to understand is what I'm gonna call the project team. The project team is both teams together. Both teams together is the project team. So we're not actually creating a rift here, but it actually looks like that, right? Yeah, so we're gonna actually fix that. So we don't want this distance between the two teams. So I've seen teams sort of bring them in together. Actually, that did nothing. To just say that you're a team doesn't do anything. But actually, you want to create a joint team out of them. So there has to be overlap, meaning the delivery team facilitator is a member of the value team. The value team facilitator is a member of the delivery team. Simple? Questions? So far, so good? So let's take about, let's explore a little more this term facilitator that I just sort of introduced. And what are we actually talking about here? So let's talk about team facilitators. So we're primarily talking about these two roles on AT. Now, I still have the word scrum master up there because I wanna actually bring the definition of scrum master from the scrum guide. So a scrum master service to the development team is coaching the development team in self-organization, okay? Helping the development team create high value products, removing impediments, facilitating scrum events, coaching the development team in organizational environments, blah, blah, blah. I've summarized it in two. Coach team an individual, facilitate practices and events and then help the team progress. Fair? Okay? Now, let's actually really take a deep dive into this. Process authority and content neutrality. The definition of a facilitator is the following. Facilitation is the art of leading a group of people through a set of processes, okay? To get them to an agreed upon outcome. But here's the key. In a manner that encourages, number one, participation. From the introverts and the extroverts, from the loud people and the quiet people, participation from all, right? Number two, ownership. The decision or the outcome that we actually come with is not like, okay, you made the decision, product owner, it's your problem, right? No, it's an agreed upon outcome that everyone feels ownership for. And then third, creativity, okay? So the role of a facilitator is to do this. Now, everyone stand up. Everyone sit down. No one talk. I have a lot of authority standing up here. I just made everyone in the room stand up for no reason. And you all did it. Now imagine if we were trying to have a conversation here. And I get to pick who talks. And I get to pick who actually doesn't talk. And what if I have a strong opinion about what's being discussed? What happens? Well, not influence, I become a jerk and just dominate the discussion. It's like, you're wrong, let me tell you why. And then I talk for 25 minutes. And then you try to say, hold on a second here. Everyone stand up, everyone sit down, right? You have so much authority as a facilitator. Now, this is why we say, yes, a facilitator has process authority. What I said was process. If I'm actually trying to solicit ideas from you guys, I can actually tell you, everyone take an index card and write three ideas, blah, blah, blah. That's process authority. But if I start to take the cards like this is stupid, this doesn't make any sense. And I am actually not neutral when it comes to content. What happens? Do I encourage participation from all? Do I encourage creativity? Do I encourage ownership or is it about me? It's about me. So there's a real interesting danger to give content and process authority to one individual. Do you guys know of individuals that have managers? Those damn managers, yes, who else? Do scrum masters have those authorities? Not on the slide, but in reality, sometimes they do. Do product owners have that authority? Now, it's gonna get more complicated. I still have 30 minutes, I'm gonna make it a little more complicated. But anyway, let's keep going. So the TA true facilitator needs to maintain content neutrality, fair? So effective facilitation skills are critical to help teams be collaborative. That's why we have technically the role of a scrum master or a team facilitator. By the way, this is why I like to call them team facilitators because it actually points them to a whole discipline that they need to learn about. But when I call them scrum masters, it points them to scrum, which is a process, sure they need to learn about it if they're facilitating it, but that's not the skill set they need to learn. They actually need to learn facilitation, proper deep facilitation. An agile team facilitator facilitates by creating a container for the team to create the content in. Because if we truly believe in self-organizing teams, if we truly believe in the 10th principle of the agile manifesto that self-organizing team, the best architectures, requirements, and something else emerge from self-organizing teams, if we really believe in this, then I, as the team facilitator, don't need to inject content. I actually need to create the best environment for you as the team to be creative. And if you're the architect that keeps interrupting everyone, I need to actually make sure it's safe for everyone else to talk, right? That's my role. That's the role of a facilitator. So if we take a look at a delivery team, the delivery team has everything and everyone they need to develop a piece of working software. That shouldn't be new for you. So the delivery team facilitator as a role on that, again, this shouldn't be new, is responsible for engaging all the team members to identify the best way to deliver value. So it ensures that the team is healthy, yeah. Educating and protecting the adoption of certain practices, process authority, supporting the team clearing impediments, facilitating critical teamwork, blah, blah, blah. All that makes total sense. Now we also have the tech lead here. The reason I bring up the tech lead is sometimes we make both of them the same person. Now, does the tech lead have an opinion? He better. That's why they're tech lead. So if the tech lead is shepherding technical excellence and answering technical questions end and end, and we're asking them to be the team facilitator, do you see the challenge here? What about the project manager? If they're the team facilitator, do you see the challenge here? So it's not to say that they can't be, I've seen instances where they are really good at taking these hats on and off, but there's a time and place to be content neutral and a time and place to not be. But unfortunately, people mix those. And when they mix those, they're actually, and this is the part, right? They're actually sort of nullifying the whole purpose of having a Scrum Master or Team Facility. Because once you have that team, the whole reason we created this structure of a team is so that they can be more collaborative, but then you put something poisonous inside that prevents collaboration. So we actually achieved zero. Now, it's important to talk about, remember, on this team, there is another facilitator. They're called the Value Team Facilitator. Remember when we put the two circles on top of each other, we actually said, yeah, this isn't a outside role, you're on the team. But here, in this capacity, they are not content neutral. Because they facilitate when they facilitate the Value Team, but when they sit on the delivery team, I don't want you content neutral, I want you, I want you, yes, I want you to have content authority, I want you to tell us what the Value Team wants to be done. Okay? So let's move on and introduce the other circle, right? The Value Team. So same three things that Jeff talked about this morning, valuable, usable, feasible. So the Value Team is a team that has everyone and everything they need to identify, prioritize, and slice business value increments. Let me pause here. You guys heard of the concept of slicing, yes? Now, I've seen so many teams that the delivery team is the team that actually slices. Now, when a bunch of technical people slice, do they slice technically or by business value? It is a problem. And the reason is because the Value Team doesn't exist and or the product owner is overwhelmed that they don't have the time to slice. So they ask the beautiful teams like, can you slice this up for me? It's like, sure, we'll slice it up. Architecture, right? Database, not that bad, but they still don't slice based on pure business stuff. So anyway, you need a team that has everything and everyone they need to identify, prioritize, and slice business value increments and make decisions about functionality and prepare the roadway. I talked about prepare the roadway because there's a lot of discovery that needs to happen, right? To validate certain assumptions and do some market research and all this stuff before I turn to the delivery team and say, hey, let's build this, right? Or I may be turning them to build it for a prototype. That's a different situation, but I'm talking actually delivery here. So this, and I put this right here in red, this is one possible configuration. Please do not copy this slide and say, here's the structure of a value team. No, right? It totally depends on your organization. Who needs to be on this value team? I'm showing you sample. So the first person is the value team facilitator, right? There's a team of people that are gonna collaborate. Do they need a facilitator? Does this team need a facilitator? When you have a lot of opinionated people around how to build something, do this group of people need a facilitator? I would say yes. The delivery team facilitator is on this as non-content neutral, right? He's representing or she's representing the team. You may have your analysts on this team. Could they be on the other team as well? Maybe, right? Some organizations have business analysts and technical analysts, right? That's what I'm saying. It totally depends on your organization. You may have a champion or visionary who's not the team facilitator. This is why I'm not using terms like product owner, right? Because the product owner could be this, this, and this person altogether. We're breaking them down into roles now, and then I'll leave it up to you to say if a single individual can fulfill multiple roles or not, that's based on bandwidth, skill set, ability, all that kind of stuff, okay? But you may have a champion or visionary. You may have different stakeholders. User experience definitely falls in here. UAT, governance, and project management. I put project management over here, not on the delivery team side. Because if you really think about it, the delivery team facilitator is sort of managing the dynamics of delivery. The value team facilitator is managing the dynamics of value and that team. There is a third entity called the project, and someone still needs to manage that, right? Who's gonna sign contracts with vendors? Does budgets, forecasts, all those kind of things. When we kill the project manager under the banner of Agile, my big question is who does that work? And usually there's not a clear answer. So what we end up doing is putting the project manager right beside the Agile team. It's like you're not on the team, but please manage it. Anyway, now, this is what gets complicated. There are three aspects of a value team you really need to think about as you design one. Number one, who is the champion of the idea? The champion of the idea, the person that had this spark, it could be the VP, it could be someone else, it could be a lead, I don't know who it is, but it's someone that had the idea. They're the champion of the idea, they're the visionary behind it. They may not be the best person to be the value team facilitator because it will be very hard for them to be content neutral, okay? Number two, facilitation of the team. Someone needs, there needs to be a role that facilitates this group of people. Now, whether you want to separate that role, whether you want to make it some one of these other people, doesn't make a difference, but this needs to happen. Why? Because that group of people specifically with very strong opinions on the business and product side will need a facilitator, this one. This is the biggest pain point I've seen within organizations. Who is accountable for results? Who do you guys have right now accountable for results of a project? Really, the whole team? I have not reached, in all the companies I've worked with, I have not seen when hits the fan, right? They don't bring the whole team into the CEO's room. There is a person that comes in. Okay, that's the guy I'm talking about. Not the, who's accountable, the team, yeah. No, no, no, I'm talking really who's accountable. Who gets fired? The whole team? No. Project manager? Maybe. Product owner, sometimes, right? So, this is a notion that I wanna separate from the role. Like, being a, I'm going to SREM terminology, being a product owner does not necessarily mean that you're immediately accountable for results, right? Or maybe it does in your organization. I don't know, right? But what I wanna say is, yes, there needs to be an accountability structure for results. It, unfortunately, in many corporations today, it is still a single, a single ringable neck, right? I hope to see days in the future where it is two, then three, you know, then the team. But in reality, in all the corporations I've worked with, big or small, doesn't matter their agile maturity, there is a person that someone can say, you come into my room, let's have a talk. Not y'all come into my room, let's have a talk, right? So, the point here is, will it be the value team facilitator? Maybe. Is it the visionary? Maybe. Separate these. The role doesn't necessarily automatically give you any one of these, right? Not because you're the value team facilitator. Now, I facilitate, I have ownership of the idea, and I'm accountable. Actually, those three things are in a little bit of conflict. All right, so I'm the champion idea, and I'm accountable, and you're facilitated. Could be. All I'm saying is it's deliberate thought, okay? Let's find out who needs to be accountable. Maybe it's the project manager. Maybe it's the value. I've seen the value team facilitator accountable, which gets really interesting because you are neutral when it comes to facilitating activities, but the power of your accountability is can you actually get a group of people to agree on something and move forward with it, right? That's an interesting servant leadership model that some organizations may adopt or may not adopt. I'm giving you, there's no recipe for this, right? So that's what I hope is coming across, but these are things you need to think about. The value team facilitator does this stuff, right? So the value team facilitator is responsible for engaging the necessary stakeholders and user of system to identify what needs to be built, blah, blah, blah. They ensure the value team is functional and productive. That team is very hard to become a high-performing team in my experience. It is much easier to get the delivery team to align on a common goal and mission and actually execute than it is the value team because a lot of times you're having someone from finance, with someone from marketing, with someone from security and legal, and you're putting them on a team and say, please all care about this product. And what they all care about is their aspect of the product. Facilitating the definition and refinement of the product backlog, release planning meetings, prioritization meetings, blah, blah, blah, meetings, meetings, meetings, right? So they're doing a lot of this facilitation. By the way, all these slides I just uploaded just in time before this session on the conference program. I actually cannot remember if I hit save or not. Now, it just came to me as like, I know I put the link. So anyway, I think it's up there. If it's not, I'll double check, but all these slides are there. Project manager. Project manager is focused on the project, not the value team, not the delivery team, but the project. The project is an important entity and someone needs to provide upper management with visibility, information needed for decision making, manage budget resources, manage communication, dependency management, manage risks, all these manage vendors, contracts, all this stuff needs to happen. So all we're trying to do is create a structure where people understand the roles clearly without trying to, because what I've seen is we focus so much on this one team structure and then we don't know what to do with the rest, so we scatter them around them and say, figure it out, right, but still deliver. And I don't think that's a healthy setup. So here's the real story. So I was working with this one organization, Big Telco, back in the US. This is actually one of the origins of where this came from. We had a project and I kid you not, there was probably 40 different people that had a say on what's going to get built. From revenue assurance to security, to retail, to legal, to marketing, to marketing operations, to point of sale, like all these people, it wasn't like they were like, yeah, we'll consume whatever you get. No, they were like, we have a say in this and you're gonna listen to us because this was a project to actually make all the stores for this Telco operator paperless. So can you imagine the number of people you're talking to here? So who's the product owner? Became the question. I want you to seriously try to imagine this situation. Who is going to be the product owner? Of course, this started creating a huge tension between the departments because the first suggestion was marketing. Marketing operations is different than marketing, it's like nope, it's us. Point of sale said, wait a minute, this is all about us. Product owner should come from our department. It was like, the Hunger Games, who's gonna nominate a product owner to be sacrificed to this team? But that shouldn't be the case. That really shouldn't be the case. So here's what we created. We created a value team where we started looking at, and this became, and again, a team can't have 40 people. So when I introduced the concept to them, it's like, great, let's put all 40 people. I was like, no, that's not a team. That's just a big mess of people. So what we did was we created a team. A team is seven to 10 people, plus or minus whatever your favorite number is. But what we created is this group of people that were really about governance. So this was more legal, security, some of those governance folks that needed, and by the way, their say trumped the decisions of the quote unquote product owner. Because if legal said no, you're not gonna do it. If security said no, you're not gonna do it. So the reality of this elusive power given to the product owner was actually really very fake in the first place. So we created this group of governance and we had people rotate in and out depending on the phase of the project. Like where we were in the project, what are the next crucial features going into the next release? Depending on that, we nominated, like if it was something really major based on security, we'd have people from a representative from security on the value team, right? If the next release was more about, I don't know what, we would pick people based on that, okay? And then we had stakeholders. So again, these are working groups, so they met outside, but they weren't purposefully designed to be a team, right? We sought their input. And then the business stakeholders, we actually had four of them as we defined the major stakeholders. And then we had them, we had a different sort of work system where they went and got feedback from the wider pool of stakeholders. The power of this is, when you put all these people in a team together and you give them a good facilitator, a good facilitator that could get these people together and say, okay, let's build a unified backlog. Let's actually collectively prioritize it. For this company, what is the highest feature? Not for what your department wants or your department wants. And that's actually how we did it. So anyway, that was the story. The way I like to design these are the following. I start with these two circles. Now let's hope the pen works. And if you can't see, I'm basically drawing what's on the PowerPoint here. So I start with these two circles and say, I know we have a value team and a delivery team, okay? And I know we have a value team facilitator and a delivery team facilitator. Question, does anyone else need to be in both teams? Could be, right? So I'm not gonna say yes to any of your answers because yes to all of them and no to all of them because it totally depends. Could put an architect in there. Who else? Business analyst. Project manager, could be. I prefer them on the value team but hey, if you have a valid reason they should be on both teams, tell me, right? So that's the first thing I start with. I say, okay, I know this team's gonna have a facilitator, that team's gonna have a facilitator. Who else is in the middle? So we start to identify who's in the middle. Who needs to be on the delivery team? Let's talk about that. So we start putting, these are the people that we need. Now, there's two interesting variations of this. Let me draw them out on this last piece of paper. So can everyone see, by the way? Yeah? Guys in the back, no? Okay, so the project I was telling you guys about had a, we had almost 40 stakeholders and then we had a delivery team of 100 people. That's not a team, right? That's a bunch of teams. So how do you structure that, right? So we basically had from the delivery team, exactly, multiple teams. Now, here's a different variation of this. And let's talk about when to use which. So here's another variation, where you have a value team and multiple delivery teams versus a value team, a delivery team and multiple feature teams. When would you use this? When would you use this? You'd use this one when all these things needed to be integrated. You'd use this one when actually things fell apart and didn't really need to be integrated. But they needed to be business integrated but not technically integrated, okay? Now, I would rarely have multiple value teams. Actually, I would probably say I will not have multiple value teams because that goes back to the same problem we had before, cool? Now, here's what we're gonna do. You've been listening to me talk for a long time and I believe learning happens when you guys talk, not when I talk. So I want you in your tables to think about the following question. This is not time to leave the session. I'm just making sure here, right? We're not done. This is part of the session. So stay. So you're gonna go around the table and discuss whether you think value teams would be beneficial in your organization. Now, the reason I say this is I actually, while I heavily believe in value teams, may not be right for every organization, right? If you have a small team of five people, you're a startup, please do not create a team of three and a team of two. It's just, no, right? That's where you can have the product owner, that's where you can have a simple scrum team and just get to work, right? But I'm talking about true situations on an enterprise level where I can't have a product owner. The other product owners will, or you'll start, hidden product owners will start to emerge. So talk about this. Those who think value teams will help share with the team what problem you think they're actually gonna solve in your environment. And those who think value teams will hurt. Let's talk about those. So I'm gonna give you guys, what time does this session end? 12.30? We're done? Bye. Really, then it's 12.30? All right, this was great knowing you guys. Any questions? So I want you to think about this at home, right? And don't email me the answers, but at least, you know, think about it. I am so sorry. I thought we still had 10 minutes. All right, we probably have time for zero questions, but I'll take one. Sure. When you look at a customer vendor kind of relationship, they have most of the company. Sure. So let's talk about services for a second, because I've done this with services companies as well. Who would be the value team in a service company? The customer. The customer. Yep. So basically, what you're doing is you're actually helping the customer create a structure to give you good input, and you would probably have people on the value team in that intersection. So yes, you are mostly the delivery team, but again, it all goes back to, are you interfacing with this mysterious product owner that you don't know where the input is coming from, right? And when you have people on the delivery team sit on the value team, they get essential context in the discussions that are happening that they can bring back to the delivery team. So I actually think in remote operations or in BPO operations or in outsourcing operations, this actually becomes a more essential, because if we don't, then we're actually having the old sort of school of someone think someone do. So let's take questions. I'll be here, but I wanna call this official to dismissal, because I think I'm competing with lunch at this point. That's never a good position to be in. One quick thing, and we didn't get time to do this, but we actually did cover learning objectives from the ICA Agile Learning Roadmap. If you want a profile with all the different learning objectives you need to learn, I'll talk more about this at my session later today, but here's what I want you to get right down this code. This is an attendance code. India, under scroll 2015, under scroll VT, you attended. So let's get credit for what you attended. And then basically all you have to do is go to the website, click on the big yellow ugly box on the right, and it put the code and you'll get started and you'll gain credits. We covered these three learning objectives today. Thank you very much. I will be here for more questions. See you at lunch. I'm here.