 Hello, welcome to this talk about the Purposeful Agile. My name is Juana. I'm very grateful to be here with you. I'm coming from France. So my talk is called Purposeful Agile. And when I explained that I have a way and approach to work with teams and search for the purpose to a better collaboration, the first time I've given this talk, they said, well, can you explain us, Juana, in this talk how business and technical units can collaborate effectively? And I said, well, I have a very simple question. If this is your question, I have the answer. The answer is very simple. They can't. That's the end of the story. If you want to do more research about it in a more expert way, you can say that stage of agile adoption are three, and you can stage one, stage two, stage three. And then if you ask me why is the cat in the slide, I have three serious reasons. The first one is why not? The second one, I like its look. I'm pretty sure that they could be good leader prize if you are in stage one, stage two, or stage three. So it can make an audit. And the third is the best reason is that if you have cats in your presentation, you will have more traffic. So if you could do a presentation, don't forget the cat. Oh, seriously. The sound? Okay. No. Do I need to speak louder? This is okay. I'm speaking louder. Okay. Well, putting in the middle, it's better, but it will be harder. Is it better? Okay. So, but I still have, so that was the bad news part of the presentation, but I have a good news also. If units can't collaborate, people can collaborate. And if people can collaborate, then we can have another look at those stage, stage of agile adoption from a people where point of view or journey. And then my stage one, stage two, stage three, where units are in the boxes are the stages I've seen and I would like to share with you before arriving to the purpose is the how-to stage, the therapy stage, and the purpose stage. So now it's louder. I feel so. If you don't hear me well, just raise your hand and we'll try to fix it again. So the how-to stage. Ten years ago when I started with agile, I started also with how-to stage. Agile and scrum is the silver bullet. Was or is. This is the how-to stage. Agile is the silver bullet method. And is the stage where I call is yes we do. I'm just putting in this description and how scrum works is my first slide ten years ago about how scrum works. I think it's pretty good right now also, iterations, ceremonies, etc. Nothing more than telling it that ten years after how-to is still the same, which means it's a good method. I'm pretty sure. But now in the how-to silver bullet method, when we do yes we do, there's a team, software developer team. Agile is for software developer teams. And what happens in that team? You have the team with a scrum master that protects the team. You may have a guy, a poor guy somewhere that's called the product owner. Don't exactly know who that person would be is a business people, a technical people, a manager. From my experience is someone that has her position a little bit in danger so that you know business. You might be the good product owner. And the business is far away. Product owner, a lonely people in a method that wants to be collaborative. For me this is one of the contradiction of Agile. And that product owner has to deal, still deal with requirements. Create user stories from requirements. A wall between business and the development software team. And then there's another person we maybe forgot but we remember her. It's the QA. I know you don't see it well but it's a written QA. And the QA struggles at the end of development to deliver working tested features. Or to another team that doesn't, it's not really in, called operation. So from crap to the fact we still have a wear pull, an Agile wear pull in a waterfall process. And in that moment as there is collaboration in the Agile team and there's this crumb master that protects the team. It's what I call, we form the Agile ghetto. The software team that is very separated from every other people in the organization. I have a question right now. Did you experience, did you experience that moment of Agile implementation only in software development? Does that ring a bell to any of you? Only software development team that is implementing Agile. Other people in the organization don't know anything about it. So yeah, if you raise your hand if you experienced that one, so thank you. I'm happy for the others if you didn't. But what I call it the Agile ghetto. There's an Agile team that is not understood. The others don't get it. And now we get to the point where this team feels they have, they've reached the source and the reason of all the problems in the world. Do you know what's the universal reason of all the problems in the world? Which one? Climate change. Climate change. Why is it climate change? What's the reason of climate change? What's the reason of climate change? Yeah, exactly. Climate change also has a root cause. Other answers? Requirements. Requirements? Where do requirements come from? Business or climate change? Who's responsible of climate change? Someone of the business. Other answers? People. People, okay. What people? Exactly. This is the universal reason of all problems in the world. The others are responsible for climate change, for business requirements. So that's what I call it. This is the Agile ghetto mindset. Those people, the good news is that those people in that Agile team that, well, things have to be different. And then we go to the second stage. I call it the attitude. So it's yes we are. From yes we do, a method, it's yes we are. So that's where Agile Mind Steps in for me. We have to be different. We have to collaborate differently. But still, there's that feeling that we are alone as a software team. There's a scrum master that protects the team and that the business doesn't get it. It's part of the other, isn't it? So we might get rid of them. And also operations, they are a little bit different, but they don't get it. So we might get rid of them. We'll bring in some coach to help us collaborate better. But within the team, so put in games, define what are our values, change attitude, having more awareness. Still things happen a lot at the software development team. We have a product owner somewhere there between the business and the team. There's still a QA struggling. But the walls are still there. The two walls are still there. It's what I call the status of Agile Despair. So Agile Mind said yes. But if we still are on this attitude of we don't get it. Are you comfortable with this light? Okay. So we're still in this attitude of we don't get it. We're not understood. And I've seen teams that we know to collaborate now. We have the Agile Mind set. Who's that? Is they resist to change? Change something on yourself. Just change something. I'm waiting. I'm doing this. No, this is easy. It's a weird change. Did you change something on yourself? You can do some other change, not that change. This was an example. Just change something on yourself. Change something. Now, the second part I invite you to look to your neighbor and change something on your neighbor. Wait respectfully. Don't change yourself and help your neighbor, saying that he changed it. You take something on your neighbor and change it. Please do that. You always can have a neighbor. Okay. Let me put this back because how was it? How simple was it to change yourself? Something on yourself. Easy. How was it to change something on someone else? This is a simple exercise. Maybe some of you just know it, but it's exactly the same thing with changing organization, changing business, changing the others. There's one quote I love, really love, is people don't resist to change. People resist to be changed if they fear for. The question stays the same. The scope is different. Usually it's a very complicated and uncomfortable question. It's a question that is not asked and not addressed in an organization. Do you have a question? You have an answer. The answer? Okay. Exactly. Yeah. It is. It is. It is with identity, of course. Of course. It's about identity. But identity is also what for. I can't have an identity. That's why I call it what I call the therapy. You decide values, but exactly. So we're going down to the purpose. From the purpose, if we reach this stage, there are several steps. The first one is what I call the intentional product. So identity, okay. But identity, also you can reach it. We talk about agile mindset and values. It's about identity. What I think is important is to have this what for. And one thing that I really believe in is this, throw a purpose in the middle of the crowd. They will self-organize. So if people know why, they will create a common identity. It's a question of all the usefulness. So then they can self-organize with business, with product owners, crumb masters, other methods, operation, whatever. If they all contribute to a common result that they share. So this is, I mean this was one of the epiphany. If the purpose is clear, that's everything that it is about scaling. Make a purpose clear. Then people self-scale. Organization will self-scale. And around what, what's the reason of life? What is the agile shared dream? What is your agile shared dream? And then you can use methods, whatever methods. So the first thing about intentional product, what I call the no vision status, it's not about creating a vision or creating workshops where you have a vision. Is, are you able as an organization level and each one in this organization to answer this question, what is your shared dream? What is the dream that your software team share with business or your business team share with the software team or legal? So if you're a software team and you're imposed methods upon you, my advice will be resist. Try to have a shared dream with all the teams that you have all over the world with business and try to work on that. Work on that. For doing for, so the intentional product, having a product with intention or service with intention so that this is where I step in the user, user customer centric approach is what is the intention, how that product will make your customer's life better? That's the basic question also to answer when we create software. How that software will make the life of your customer better? Are you able to answer that question? It's not about having the right wrong answer. Do you have a clear answer? You're good. If you don't have that clear answer, there's something to work on it. And yeah, we talked a lot about starting with why, which is an approach. Coach, I had an interesting discussion with a coach that said, well, the different people have different needs so the people that need to know how, upon over knowing why, other people have different needs so they know what to do, more than why. So the theory of why is just that because it put it so nicely is when you know why, you can bear almost any house. I mean, it works for me. I want to share with you. I think that knowing the purpose is a source of happiness of the team. And what's the purpose as a business and software team is to create a product. To create this intentional product, the second step after the shared dream is the usefulness. So I think I have a vision. My shared dream is that the product we are building together, developing software, is improving my user, my customer's life. Now, how did we reflect on it? How much work we do in talking to customers, validating that the users are benefitting from it. How many of you know your customers have talked to your customers? Brilliant. Brilliant. How often do you talk? People that talk to their customers, how often do you talk to their customers? Sorry? Day? Okay. And how do you talk with them? Okay. One of the things that's important when you talk to customers is listening to the customers. So being open and non-judgmental and don't have a plan, listening to their needs. We might talk to the customers because we want to validate something. So one of the things is that the customer expresses once this. So I'm talking to the customer, we are talking to the customer and see how we will implement what the customer wants. Well, the customer can also be biased. So one of the art is how you talk to the customer, how do you ask them questions so you get a grip on what their really needs are instead of doing what your customers or actually not even customers, but maybe product manager tells you to do. So there was someone in the user experience domain that said, well, people from Edeo, if you know that company, it's a company that is a design thinking company, he said, talk to the people always until you don't find out anything new. And when you don't find out anything new, go and talk to them more to be sure that you don't find anything new because you have your own biases. So whatever happens, talk to the people that are your users. So this is about usefulness and user-centric. Why are the user important also? From a human point of being, because agile and collaboration and teams, there are people interaction over processes. And I think we tend to forget that sometimes. We as humans, we need social connections and we need to be useful to someone. I don't know about you, but if I'm not useful to no one in this world, I won't be happy. If I have some proven evidence that no one in this world was helped by myself, my family, my colleagues, the people I'm working, whatever, I won't be happy. From a business perspective, in a business environment, these people are the customers. So I think that the fact that we put the customers in the center of our focus answers to this human need to be useful to someone. And also that's why software teams, business teams, operation teams need to have an approach that is customer-centric. Because we all need to say, what are you doing, who is that useful to? Who is that useful to you? And the last thing of the steps in purposeful agile is prototyping. Prototyping, experimenting. Of course, we all say it's experimental, we do experiments, prototyping. But a question that is answered when you prototype a new experiment is how visible is the contribution I've made? And of course, how do I validate that what I think is useful for my user is really useful? What I say is demo, demo, demo. You can put release, release, release. Well, for me, what is the most important is show. The keyword is show. If that's really deliverable and it's a release, that's awesome. If for some reasons it's not releaseable anymore yet, it's not that good, but the good news that there's a step for improvement. But what is important is show. Show it, show it, show it. So the demo from the iteration theory is I experience it as being one of the most powerful scaling agile tool. If you invite in, there's one condition is to invite largely people in that demo. Who are you doing demos? I suppose yes. Who are the people that are in your demo? Old stakeholders. Who are the stakeholders? That's brilliant. That's brilliant. In every demo. Okay. Thank you. Some other answer. Who's part of your demo? Usually product owner. Okay. That's good. So what is important is to have more people than only the team eventually with a product owner is invite largely. So this is a good example. All stakeholders, sales people, operation, all stakeholders, customers, invite customers, invite executives. They won't come maybe at the beginning. They will come maybe later. Teams don't be afraid of inviting people because you think that's not good enough. Usually, and I didn't see that not happening, people are grateful to have information on what's happening. And even during one of the pretty old story of a demo that didn't want well at all, it was the first demo. It didn't want well at all. But all the people stepped out happy from that demo. And we said, what happened here? Why? It wasn't good. Why all people were happy? Actually, they were happy because they've shared information together. And that was what was important. Stakeholder shared information. It was not important that was good or not good. What was important was that it was shared. And another type of situation I've seen when I say demo, demo, invite largely all the people, customers and stakeholders. The first thing is, well, they don't know why we invite them. They won't come. Okay. One people at the time change happens. One person at the time, remember? So some people that are more impacted are coming. And then the usefulness of the demo just propagates. And what are we going to experience? Those people that know that are impacted then come knows what other people around would be interested. So they become naturally changed agents also. And the second story I'd like to quickly share is another team where we started with a small demo. This was kind of a small demo because it's the photo from there. Ended up with 60 people in the room like that. And one of the developers said, well, tell me, oh my God, next time we have to sell some popcorn here, rent a cinema and sell some popcorn so we can have some more budget to tell more user stories. Oh yeah, user stories and purpose. You remember, I'm pretty sure everyone here knows how you write a user story. There's no brainer there. As a user, I want to remember that as a user. And by the way, the user, never let the user, the user, be specific as a user. The user is the whole universe. It's too generic to be connected. We are not connected to the universe, but someone specific. So if you think users think someone, what is your name? Pritish. So as Pritish, I want to do action. And you remember that part in order to do something? So at the user story level, the purpose is there. And don't ever, ever, my advice, forget that part. If you product owners, if there is product owners here, as developers, they're not clear about that part. You don't know what it is. That means that it's not helpful. Don't do it. You have struggled to put in order to. That user story is useless. Either is useless. Either you'll find out what you put in it. So demo is a very powerful scaling agile tool. Just like that. I wouldn't search further because it serves the intentional product and the purpose. How are we timing? Okay. We have 10 minutes more. What I will be done. And it's something that I somehow already said. When we focus on a product with intention to make users life better, it leads to cultural refactoring. Makes people happier. If we're together, do you plan something with your family or planning holidays, for example? Or are you participating in some hobby activity? How does that work in terms of how excited are you to do that? Very excited. Why is that if you want to share it? What's exciting about that? So that's exactly the way that. Thank you for sharing that. That workplace should be. We are exciting to plan something together. And what we plan together is that product that makes users life better. And when you're excited, culture shifts happen. Couple of minutes on this slide. So shifting to the purpose for organization from a management leadership point of view. This is a pattern that is inspired by the theory you, by the way. From a management or leader perspectives. Are the managers in the room? Are there any managers? Brilliant. Thank you. The first thing I would like to share with you is managers and agile changers and leaders or agile managers, whatever you call it, are part of the system that is agile. Or not just prescript the system, the agile system, they are part of the system. And the first thing that I would like to advise you to do as an agile manager is to clean your agenda. I call it manage like a pirate. What does that tell you, by the way, when I'm saying managing like a pirate? What is a pirate for you? Why pirate? So what is pirate for you? Because we might have negative or positive. Challenge the rules. Exactly. Exactly. Thank you for that. So that's a pirate challenge, the established regulations. And what I found out is very important that actually the manager is usually in place to keep the regulations, should be one of those that can challenge the rules, have to challenge the rules. If not, there's a tension. There will be a tension and we don't know who will win. Or anyway, even if the transformation will win, it will be much further in the future. That is, why should we put that tension in place and use words like win or lose? Manager are part of the system, so why would manager challenge the system? For that, a pirate, that challenges, it observes the systems and you see at the borders what is not going well, what are the problems and then hacks that system there. For big money, it has to be Oshih or he, has to be a very good observer. To have time to observe needs that you're available for it. So the first thing is clean your agenda. One metric of one of the funny metrics I have for agile organization is look into managers' agendas. If you have an agenda, you know, I don't know, you look Outlook or whatever, Google agenda, if you see a packed agenda of the managers, that organization is not agile yet. The first thing is managers give you time to observe the system. Then observe, to observe with intention, going backwards, what is Oshih or .8 is that prototype that it's not maybe a release yet, but is releasable. So it's not 1.0, but is good enough to try it to be meaningful. That's the way also when I've talked about demos and releasable products. Demo on 0.8 versions of your products. That's not good enough to have feedbacks from. And then when you prototype, observe to learn what happened. Observing without judgment, that's also something that it's not very easy. I will think that you guys here, I suspect they are far, far better on observing without judgment that are we in western cultures. Western culture are very judgmental, I think. So I think for this thing, you are far more already skilled, so we have to learn from you. Observe and sense the system to learn what happened when we've done a change and then transform. Make that prototype from 0.8 to 1.8 and go and transform it. So this is, I think, my last slide and I'm on time. And my last message to you is keep in mind when you want to transform your team, yourself, your team and your business and your company to make that step from how to implement Agile to be and make that change that we all together want to see and want to happen. That was my last slide and we have maybe two minutes if you have any remarks, comments or questions. I'm sorry, I didn't hear you well. Beyond the purpose to create a product, I think the idea, really the idea is if everyone in the team is contributing to create together the purpose of the product and everyone in the software team knows what are the user needs and I'm coming back, it seems to be big words but it's so deadly important. What is our shared dream? Why do we think that what we are doing will improve customers' user's life? What I've seen is that that motivates far more software developer to deliver and the software developer is very creative in having the good solutions delivered if he also knows why that requirement, why that user story. So that's my answer if he knows why he will deliver or she will deliver. Then still it remains that how do you sell that shared dream to the team? I mean team has to buy in that dream. Actually my answer is team doesn't have to buy in the dream. Team has to build the dream together. That makes sense. Thank you.