 Welcome everyone and I welcome you to the session how to stop weaponizing the ideal practices in the workplace. And this is given by Sharon. So without further delay, I'd like to give Sharon the entire stage. Sharon, welcome to you. Thank you very much. And I'd like to thank Agile India for having me. I'm so excited to be able to talk to you today. And I'm really looking forward to sharing my thoughts with you. So the first thing that I want to say is agility. How much do we love it? And one of the things that I'm really enjoying is the amount of conversations that we're having around agility these days. And I think it just is testimony to us as an organizational culture that we're still able to talk about it. I'm old. I've been working in technology for, well, since the turn of the century and before the turn of the century. And I can never remember having a conversation about waterfall, but I love the way that we talk about agility. But one of the things that I want to talk about today is the problem that we have is in how we are weaponizing it. We're using agility as something against each other instead of creating it as an inclusive proactive engagement tool. So that's what I'm going to talk about as we go through today. But first of all, I would like to introduce myself and say hello. I'm Sharon. Why am I talking to you about this? Well, I'm pretty lucky, as I said, I've been involved in all sorts of technology approaches for the past 30 plus years. So I'm pretty lucky to have been in and around agility concepts and approaches since it was mooted really. Now, Capital A agile or the formal agility stuff has only been around for about 20, 21 years, 20 years. And I've been actively engaged in agility for about 15 of those 21 years. So I'm pretty sure that I've had a good exposure into how agility can be applied and has been applied. I currently own my own company that specializes in enterprise level transformations towards agility. And one of the things that I do focus on is the basics. You know, what makes agile agile? I specialize in coaching executive senior leaders and agile coaches and my whole focus, my passion is to create an agility focused environment where we are looking to use the fundamentals of agility. Use them well and use them to create the value that we are looking for. From that perspective, though, I have been a team member, a program manager, a team leader, a leader of transformations. I've been a senior manager. I've been a general manager in the corporate world. And now I'm a small business owner. So I'm sort of looking at agility from all all perspectives. I used to be tasked with setting up and running PMOs and helping architects understand how to work in an agile environment. So the beauty of my career is that I actually have had the opportunity to talk to people about agility from many, many, many perspectives. So I'm lucky that way. However, there's something that we need to do. We need to talk. And if anyone's ever been with their significant other and have heard those sentences, you always feel that quickening of fear and you always think, oh, what has happened? Those dreaded words. They mean that someone is not happy. Someone's not engaged. Someone's not feeling it. So when we need to talk about agility, it's really hard because agility is something we all know and love. That's why we're here. That's why we're at a conference. We want to learn more. We want to do more. We want to understand more. But one of the things that we're discovering is that there are so many things that are going wrong. And we're here at the conference to learn what can we do differently? How can we do it better, faster, stronger? How can we become more effective? How can we become more efficient? And it really breaks the heart that something that should be so good and was fundamentally designed to be about creating alignment and shared understanding and value outcomes that it's gone wrong. So let's talk about it. How many times do we hear the words associated with agility used wrongly? Now I even hear the word agile used in executive conversations against teams. Your team's agile. They're not creating very good quality outcomes. Your team's agile. They're not doing the due diligence that needs to be done. We hear it talked about when we talk about various people. She's not agile. He's not agile. They're not agile. We hear it talked about when we are looking at patterns of delivery and patterns of outcome creation. We hear people say that's not agile or that's not how you do it. We hear people imposing judgment on the quality of work that has been done, but also the quality for how we do work. Your stories are wrong. We see agility used as a passive aggressive tool for our stakeholders and we talk about the fact that we need your requirements. We need you to tell us what you want. We need you to increase your input with us. But we also see agility used as a whipping tool for our delivery teams. Increase your throughput. Reduce your lead time. Reduce your cycle time. Just get it done. I'm sure a lot of you will find these concepts quite familiar and this is what scares me because what worries me is that we're actually forgetting the basics around agility. And we're using agility concepts and tools and techniques as weapons against each other. And against each other, individual to individual, team to team, department to department and even at a fundamentally organisational level. We need to think about these things and we need to pay attention to them. So one of the things I would like you to do is I'd like you to think about any time you've heard some of the language in agility or some of the approaches in agility actually being weaponised. Use as an excuse for a shortcut. Use as an excuse for poor behavior. Please feel free to put it into the chat box. There's one of the things that we'll discover is as soon as someone shares it, everyone else will be saying, yeah, I've heard that too. My personal favourite, the one that I come across a lot all the time is MVP. Minimal viable product. What a great concept is the least amount of work that we can do to create a meaningful outcome and so we can learn something. How often is MVP uses an excuse to cut corners and not do due diligence and to just get something out the door as fast as we possibly can. This is not what we want from agility. Agility is about this cohesive shared understanding, mutual alignment approach to our working practices. Over time we've seen agility used to create factories in the workplace and organisations are using agility as a concept just to put people into literally a sausage machine and just grind things out. We see agility being used for poor behavior as an excuse for poor behavior where we have egotistical approaches or we have people who dominate a particular conversation. We also have agility happening where we're seeing people demonstrate particularly low maturity and this is around this understanding what value demonstrates for an organisation and deliberately avoiding that. You'll see it a lot. I'm not sure if any of you have any excuses around the whole concept of we don't do any planning because we're agile or we don't need to document anything because we're agile. Now we know that's not true and sometimes we use agility as an opportunity to avoid doing the stuff that we don't like. Now I can see that there's a few comments in the chat box there, micro management. Yes, I'm going to talk about that. Velocity as a whip for increased throughput. Faster, faster, faster, faster is not equal to better, better, better, better. Using agility to drive personal agendas is one thing. Using agility as a code word to sell something. That's another thing. And these are the types of things that I want to talk about. But what I want to do is I want to talk about how can we move away from these things. Because it's so very important that we come back to what agility is all about. So let's talk about that. At a fundamental level, we should all be reasonably familiar with the agile manifesto. After all, it was ground zero for, you know, where all of this stuff started from. And one of the things that I find quite interesting to talk to my stakeholders about is that when we look at the agile manifesto, it talks about individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. But I want you to realize it's the word over, not instead of. And in fact, when the authors of the agile manifesto were talking about these things, they weren't advocating that we don't do these things. They weren't guys. They knew that for us to deliver value to the organization, we need to focus on the holistic view of value. But we want to buy ourselves ourselves a little bit, but not totally towards interaction and collaboration and delivery of working solutions and learning and adjusting as we go. And that's part of the manifesto. While there is value in the items on the right, we value the items on the left more. It doesn't say don't do the things on the right. This is the first thing that we see when we see agility used as a weapon inside our organizations. We have agile team members who say we don't need to do a plan. We're agile. We don't need to document anything. We're agile. The agile manifesto says we don't need to. And it's not true because the agile manifesto doesn't say that. And what we need to do is we really need to think about what are the basics around agility. So if you're finding yourself in this situation where you've got these biases very strongly one way or the other, you need to come back to the basics. So go to the principles. And the principles behind the agile manifesto. They're what agility really is all about. How you do agility, the tools, the techniques, the practices, that's going to depend on your framework and your team and your organization maturity. The whole point though is the values and the principles. If we are focusing on creating customer satisfaction, welcoming change when it's good for the outcome we're trying to create. If we're focusing on delivering frequently so we get good outcomes, we get feedback loops and we start to accrue value and minimize our risks. If we're focusing on working together, we're moving in the right direction, even better, motivated people. That's one of the key things around agility. We need to have good people really investing in our solutions. We need to have collaboration. We need to make sure we are creating outcomes, not outputs, because it's about the change that we're making in our organization's outputs. It's about changes that we're making in our customer space. We also want to be talking about sustainable pace. It's a marathon, not a sprint. This is where some of the language that we use in agility, some of the scrum terminologies in terms of calling an iteration a sprint, can actually be a little bit confusing to our stakeholders. They think we're just rushing, but we're not. We actually need to continue to deliver at a sustainable pace. We also need to build in technical excellence as we go, otherwise it's going to get harder and harder for us to deliver value. We want simplicity. We want to be able to organize at the individual or self-level, team level. We also need to adopt the practices of a high-performing team, which is all about being self-aware and self-moderating. That means that we need to take the time to reflect and then make the commitment to adjust. When we start to look at agility at the basic levels, it's about coming back to those things, but there's more to it when we weaponize it. At the organization level, as I've mentioned, oftentimes we see agility as a way of creating faster production lines. What happens here is organizations pivot towards iterative working practices and they pivot towards teams that are allocated to these iterative working practices. They use the concept of time boxes, but they break the concept. The original concept of a time box is that you have focused and dedicated working time so that you can actually achieve value quicker. What happens at the organizational level is we end up trying to speed up the time boxes. We try to make them faster and faster by putting more work into the time box or taking people and assigning them to multiple teams at the same time. Now, what happens is we actually create a spiral down because we're making it harder and harder and harder for us to create value. This generally is a result of a focus on revenue or profit. Now, every organization has to be in business. Every member of an agile team needs to know how to stay in business, but we've got to be very careful that we are not trying to increase velocity, iteration, on iteration, on iteration, on iteration. If we do that, we end up creating a situation where we've got mammoths amounts of technical debt and we end up going into this down rule spiral and the spiral actually becomes a tornado. So how do we deal with this? At an organizational level, we need to be talking to leadership around the fact that velocity shouldn't be always increasing. We should aim for it to be stabilizing. We need to be talking about allocation of people to various teams. And we need to be saying that it is more effective and efficient if we have people in sticky, long-lived teams. We have product teams rather than projects. Product teams mean that we create a team of cross-functional skill sets. We get them together and we allow them to build their team approaches. And then we bring the work to the team. Project work is we define the work and then we bring the team to the work. And then at the end of the work, we disband everyone. All of the IP goes away, all of the ownership, all of the knowledge about what we've just created goes away. So we want to be thinking about team structures that allow us to create IP and then retain IP. We want to make sure that we're not constantly trying to up our velocity. We need to be looking for stable velocity. And we need to slow down a bit. Theory of constraints. We need to slow down to speed up. We can't constantly be pushing things through the pipeline faster and faster and faster. It doesn't allow us to deliver more value. At a leader level, we've got some really, really challenging constructs happening. Shane in the chat mentioned it absolutely. Daily meetings equals micro management. So we invented all these wonderful tools to allow teams to be able to be empowered and self-organized. And we visualized work and we started to put it into tools that allow people to see it. And it allows people to see where we've got impediments and roadblocks and to take a pulse of the team. What has happened? Micro management. We have people on us all of the time. Is it done yet? Is it done yet? Is it done yet? Is it done yet? And what happens there is we have team members who are losing their empowerment and they're just reverting back to doing what they're told. The scariest thing I saw a couple of months ago with one of the teams that I'm working with at the moment is that I had a whole group of people. We'll call them BAs who were writing all of the stories that were just handed over to the team and there was no conversation about it. So the team was reverting back to they just doing what they're told to do. It was a very poor practice in terms of agility, but they were calling it our job. Oh, thank you, Shipra. Yeah, we've got that one. Frequent team changes in the name of agility will just treat people as if they're fungible will just move people around. We don't want that. We want people to be able to create a team and work together. Estimates. Estimates are a great thing to talk about when we're talking about weaponizing agility. And the reason that we need to talk about those is the whole point of agility is when we start a piece of work. We know we don't know that much about that piece of work. So we're actually going to focus on learning as we go. That's why we do t-shirt estimates. That's why we use planning poker and story points because we can't give an exact accurate estimate up front. But we're going to think about the relative sizing of the work. And then as we know more about what those sizes actually play out to, we can extrapolate from that knowledge. The other thing that we've got happening with leaders, one of the things that scares me the most. Agility is all about learning and it's all about thinking as we go. As the focus moves towards faster velocity, more throughput and micro management of tasks, we lose the focus on the thinking. And agility boils down to the deliberate practice of structured thinking. The whole approach of working together in a cross-functional team, the whole point of writing things like stories and acceptance criteria and the whole approach to elicitation and elaboration being a team sport is that we create shared and common understanding. As soon as we focus on tasks rather than collaboration, as soon as we focus on getting things done rather than experimentation, we're shifting the focus away from learning. And when we do that, it means that we are not able to really target the value propositions that we're trying to create. On the flip side though, it's not all leaders. One of the things that I want us to think about is the fact that as an agile team member, we often can get a little bit passive aggressive with our leaders as well. And we often use agility structures to basically sit back and fold our arms and say to our leaders, well, it's in JIRA, you should go and find it. We talked about it in the showcase. Why weren't you there? And that's the sort of thing that we need to be aware of as well. We don't want to use the tools, the techniques and the practices as weapons against our stakeholders. We want it to be inclusive and we want it to be involving them. And we need to be open to our techniques and our practices and our tool sets to see whether or not they are actually supporting what our leaders need, what our stakeholders need. So we need to be very, very careful there. We have to bias ourselves towards engagement, relationships and building shared understanding. Invite people in. Don't push them away. Now let's talk about some of those people. Hello, I'm Sharon. I'm a consultant and I'm a coach. And I know that oftentimes when you get a consultant in the room or a coach in the room, they want to be the smartest person in the room. When we're working in an agile environment, an agile consultant is trying to sell you something. That's the job. And one of the things that we see happening when we weaponize around this consultancy space is we'll see the uplift in jargon or specialist terms or esoteric knowledge. They know something that you don't know. And they actually use it against you. The reason they use it against you is they stand themselves higher and they basically make it very difficult for you to absorb their knowledge because their job is to get you to buy more of their time. I often say to the coaches and consultants that I'm working with. Their job is to make themselves redundant. As a consultant and as a coach, you want to be enabling the team to be able to do the things that you're talking about. Your job is to share knowledge, not hold it. Your job is to create a situation where people can engage. We want to look out for that because that is a very subtle weaponizing of agility where we use agile as a way of boosting our own egos or setting ourselves up to be the smartest person in the room, which is not what we want. From a consultant or a coach or a scrum master perspective, we are the absolute servant leaders. The job of the consultant coach or scrum master is to share knowledge, not to hold it. It's to enable people not to disable and it is to empower not to judge. When we start to see these types of behaviors played out, one of the things that we need to do as a leader or even as a coach or a consultant ourselves or as a team member is we need to call it out. And we need to recognize that the job of the consultant or coach is not to be the king, it is to be the gym, the bodybuilder and to help the team strengthen itself. At the team level, we have a fundamental problem happening and it's become more and more obvious as we're working remotely. We can't ignore the impact of COVID, we can't ignore the impact of having to do more and more work with greater geographic distances. But what we discovered is that there is a fundamental challenge at team level. Most agile practices, most agile techniques and most agile approaches are biased towards articulate extroverts. The loudest person, the longest talker, the person who can write the most post-it notes quickly. They are the people that tend to be driving the behavior. We need to be looking at how we can structure our agility engagement sessions so that it's not all about extroverts. We need to be thinking about different methods of engagement. We need to be thinking about using asynchronous engagement as well as instant collaboration. We need to be thinking about how can we build an environment where everyone can participate in their own way, no matter what their way is. We need to also be thinking about using value as our compass. Talking about value generically as opposed to specifically is a really important thing. And getting team alignment on what value looks like, what is the outcome that we're trying to create is a number one thing that we need to do. What we often find is that everyone has their own personal view of value. So we need to create a shared understanding of what value looks like and then work as a team to figure out how we collectively can create that value. This is super important because we need to shift the focus away from do, do, do, do, do, just checking off the checklist definition of done stuff doesn't add value. We need to be using value to talk about what do we need to change, what do we need to do differently, what do we need to learn. So we need to bring value as a concept into our retrospectives so that we are fine tuning our performance engine as a team. We need to make sure the retrospectives are valued activities and that we set them up so that everyone can be actively engaged. We also need to make sure at the team level when we are estimating when we are doing our sprint plans or our iteration plans when we are doing our elaboration sessions when we're creating our acceptance criteria that we are allowing ourselves time to think, time to share and time to learn. So we need to take the time to look back at what's happened in the past and project that forward to the future. These are some of the things that we need to do. When we think back to how agility is now seen as a very tightly time boxed rush rush rush rush rush delivery approach, we can see that we're breaking these fundamental concepts around what agility means at team level. So we need to really focus on these things and talk about them and call it out when they're not happening. But at the most important level, we need to be thinking about how agility has now moved away from the joyous work pattern that it used to be. And one of the key elements around agility was that it creates an environment where people enjoy their work and they want to come to work and they get pleasure out of the work that they're doing. And they start to feel really motivated and empowered and we accept ownership. We take safety as a prerequisite into everything we do, but we're also thinking about how can we own the outcome. Psychological ownership is a cornerstone element to agility. But if we have those structures in place and the weaponization at enterprise level or organization level and at leadership level and at team level individually, you're just going to show up, do your job and go home. What we're looking for from an agile environment is the opportunity to create a learning environment where we can come to work and become better at what we do. We get to try challenging problems. I mean, part of the reason we do our jobs is we like solving problems. So we want to be able to try challenging problems and experiment with solutions and learn, learn by doing, learn by experimenting, by trying new things. But we also want to work in a psychologically safe environment, which is this inclusive environment where we don't have barriers against speaking to each other. As soon as we start to get in the churn, the workout mindset, people are always saying that they're too busy to talk. They haven't got time to collaborate. We'll just have to catch up later. What we want to be doing to maximize this self-fulfilling prophecy of motivated individuals at the team level is creating this environment of inclusivity, not exclusivity. We want to bring people on a journey and we want to learn from each other. Collaboration is the cornerstone to this. And one of the things that we see as soon as we get into the rush, rush, rush is there's no time to talk, let alone to collaborate. Collaborate is one of the hardest things that we will ever learn how to do. It takes time and we need to build relationships. Thinking is not something we can do on demand either. So when we think about it, agility contains a lot of structures, a lot of tools and a lot of techniques that are there to promote shared understanding, collaborative working practices and value-based outcomes. When we're using them, think back to what are the fundamentals around this particular tool and technique and ask yourself, what is this helping me to do? Try not to fall into the trap of weaponizing agility. I'm going to finish it there because I can see that I've got some questions. I would like to say thank you. Thank you for engaging me coming to this session and thank you for allowing me to share my thoughts. So with that in mind, shall we have a look at the questions? Yes, I think you can look at the questions now. Everyone feel free to put in the questions on the Q&A section. So we've got three in there already. This is great. So we've got question number one. How to measure teams efficiency and maturity? How to create a healthy competitive environment? All great questions. So one of the things, I'll start with the third question there. How to create a healthy competitive environment? One of the things that we need to really recognize in an agile team is that no one of us can do it by ourselves. So we actually need everyone in the team to create value. So the competitive environment is not me against you. It becomes me against me. Can I get better at something that I did last time? And can I work with you to create a better outcome? Our societies are based on meritocracies, which is about individual performance and behaviors. When we start to talk about agility, we actually are thinking about how we can create collaborative and team based performance outcomes. So we've got a fundamental disconnect in the way that our organizations are structured and how they do reward or enumeration. What can we do about it? Within our teams, we can just bias ourselves to helping each other rather than trying to cut each other down. In terms of efficiency, when we're talking about agility, one of the things that I always focus on is effectiveness. Are we doing the right thing as opposed to efficiency? Are we doing it in time and cost limits? Agility is about effectiveness and then creating patterns of behavior that create that effectiveness before we look at the efficiencies. It's only after we've created that pattern of behavior for effective delivery that we can start to look at how can we optimize the system. That's the first thing. In terms of maturity, there are bucket loads, lots and lots and lots of agile maturity assessments that are available there. For me, I keep it very, very simple when I'm talking about maturity and it comes back to the concepts around effectiveness. Are we actually able to be an effective team? Are we working well together inside the team? And then are we also able to work well with our stakeholders? Are we working with adjacent teams? Are we able to interact with our customers? And are we able to get feedback from our stakeholders quickly and easily? They're the key things that drive maturity. The ability to be aware and self-moderating is a thing that is cornerstone to agile maturity as well. If we're not able to do retro as well, then we're probably not able to do a lot of the other maturity elements as well. I hope that answers your question, but if not, please don't hesitate to join me in the next session where we're at the table where we can come and talk about this more. There's another question here about agility, talking about not limiting ourselves to the boundaries of our roles, but at the same time having dedicated roles. It's difficult to draw the lines. Yes, very much. Because we talk about this thing called T-shaped skills. Now, T-shaped skills mean that the bottom of your T is the roles and responsibilities that you have been employed to do. This is what your job description talks about. And across the top, we have the other skills. Now, it depends on the framework that you look at. I always like to call those across the top skills of the T. I like to call those my teaming skills. How well am I able to work with others? How well am I able to collaborate? How well am I able to understand someone else's role and figure out how to integrate it into the work that we're trying to do? This to me is what T-shaped skills are about. But when we also look at all of our job descriptions, we'll see that most of us have certain things that we always do. Most jobs have a degree of analysis. Most jobs have a degree of communication. Most jobs have a need for collaboration. All of those things are the things that we can help others do from our perspective. That's where T-shaped skills are very, very important. It doesn't mean the developers need to become testers or testers need to become developers. It doesn't mean that at all. But it means we need to be aware of the other roles and how we can support them. The next question is around the fundamental elements of agility around building teams around motivated individuals. And it is hard to find such souls absolutely and keep them together. And what you're talking about there is just the fundamental concepts around sticky teams. I mentioned them earlier. We actually want to create a team that is cohesive and has worked together and has solved problems together and are comfortable working together. And we want them to become long lived teams. We don't invest in team formation activities. If you do retro, that's part of it. But there are other things that we do as well that we often skip over these days. We've stopped doing social contracts or working agreements. We don't talk about how to have healthy conflict in the team. Very few organizations these days fund team bonding activities. And when we're working remotely, as soon as we jump on a call, the first thing we do is we follow the agenda and we finish the call as soon as we can. We don't talk to each other as people. So if you want to really have motivated individuals, you need to recognize that we're all people and we're all here to work together. And we need to treat each other as people, not just the next step in the machine. Hopefully that answers your question. We've got one more question. Have I got time for this one, Vikas? You can take up the last question and then we can wind up the session. All right, great. So I'll just quickly answer this question. It's a big question, so I don't know that I'm going to be able to answer it quickly enough, but I'll give it a go. At team level, it is easier to address because it's more obvious. However, at organization level, you can see it in the culture. So if your organization is very, very rigid and structured and silo eyes and saying all of the agile words but not doing any of the agile things, it's really obvious. The actions are about opening leaders minds to how agility leadership is so very different and how we need to break down the barriers. And this is something that is becoming more and more part of modern management theory, recognizing that it's about creating networks inside our organization rather than power dynamics. So one of the things that you can do here is you can actually start a conversation around networks and how do we create teams and teams and how do we bring our stakeholders to the work that we're doing. That's one of the most important things you can do is you're actually going to be talking about shortening your feedback loops, creating emergent understanding, rather than trying to shift knowledge via words or emails. Starting the conversation is the first step though. And thank you Sharon for such an insightful session and certainly helps us to you know to improve our organizations better towards being agile than doing. Thank you very much everyone.