 It takes, there's a phrase, it says it takes two to tango, right? And three for the politics to kick in. And if you add more people, which is if you have a large team, then that's a good breeding ground for various dysfunctions. And software development, if you leave some of the simple application aside, it is a team activity. The more complex the software, the bigger the team. And if you look at any of the industry analysis reports, the success rate of software projects is still pretty low. And the software projects fail not because we don't have smart people working in software industry. In fact, it is the other way around. The smartest or the smartest actually go for ITEC nowadays. The projects don't fail because they're not enough good processes or not enough tools. The projects fail because all the individuals are not aligned with the team goals. And those are some of the dysfunctions. So software development, just to reiterate, is a team activity. And I would like to ask the audience here, can you name some of the dysfunctions that you have seen? Maybe not in your org, but somebody else's org. You can assume everything is rosy in your side, but can you name something? Some of the dysfunctions. Anyone? Lack of collaboration among developers and testers. Not enough clarity and accountability and responsibility. Not good roadmap. So the team doesn't know in what direction we are moving. Good. So lack of clear communication across different functions, not just developers and testers, but the business folks, the sales, the support, and everything. What else? Overhead of processes. Maybe sometimes the processes become the end goals. So I think you all gave some very good examples, like lack of accountability, inattention to results, and so on. So there can be lots of these dysfunctions within an organization. And when I say organization, I'm not implying a large enterprise, but in the context of maybe a product, group, a team, or a division wherein some software is being developed. And there's a big debate about agile and these kind of dysfunctions. So there are two camps. One camp says that to really for agile to be successful, you need to take care of some of these dysfunctions first, which means as an organization, you could be spending next one year or two years just fixing these issues. And if things don't work out, in agile adoption, you blame it on these dysfunctions. The other viewpoint is that agile is actually a new social contract. It's not about just products. It's not about individuals. It's about the social interactions. And when you bring that picture in the forefront, agile can actually help remove some of these dysfunctions. Of course, it takes time. But better if you continue on the existing path and don't introduce a change, you will be worse off than actually introducing the change. So the only constant about change is the change will always be there. So either you don't change and perish or you change. And agile, by its nature, when it embraces change, it helps in alleviating some of these dysfunctions. So that's my opinion. And in the next 20 minutes, I'm going to talk about how different types of these dysfunctions can actually be alleviated through agile. There's a wonderful book by Patrick. How many of you have actually read this book? OK, a few hands. If you haven't read it, I will highly, highly recommend. It's like a fable. It's not like any other book. It's like a story. You can finish it in one sitting. And it gives you a beautiful structure, help you familiarize with how these dysfunctions feed into each other, starting with the bottom, which is absence of trust, to in the end, where you don't get the results you want. So the end result is a failure or less than optimal results. And this book was published more than a decade ago, even before agile was mainstream. And what I have done is I've tried to link this pyramid, these five dysfunctions, to how they surface in our world of software development, and how agile practices help us remove some of these. So I'll start with the first one, which is lack of trust. What defines lack of trust? According to Patrick, it's the unwillingness to be vulnerable within a group. When you're defensive, you will not tell the truth. You will try to always portray that everything is fine. You will try to defend your decisions and not be receptive to feedback. And how does this manifest in our software development? To start with, we got silos, unless it's very common, especially in outsourced world, where we got some development team sitting in one place, testing team sitting in another continent, and the business folks probably could be yet another place. And things are just thrown over the wall. There's lack of appreciation for the job that each function is bringing to the table. And it's all then about the organizational or the cross-functional, us versus them. I've seen it n number of times. I'll give you one example. So this was a time when one of the products was in really crunch mode. The code was churning very fast, and the build quality was poor for various reasons. So as a result, what was happening, every time the testing team picked up a new build, they hit blocker issues. And what development team was trying to do, they were trying to help. So they said, OK, let's not wait for the next build. Why don't we just take patch after patch list? We'll keep patching your testing environment. Or you come and sit with the developer, help debug some of these issues. And I heard a comment from a QA manager. He said, oh, some of my team members are coming, and they're saying, you know what? It's like we are helping the developers go through this exam by helping them. And we have this backlog of all this work to do, and we are going to fail. They're thinking by helping all the energy that they're spending with the developers that they will not get enough time to do their own job. So developers are the superheroes. Their job is done, and I'm the failure. That's typical us versus them. And this also results in information control. If silos are not bad enough, people try to control information even further. Again, to share some of the examples, I used to get daily reports from various product groups. And those reports were about the various bug metrics, how much test coverage has been done, the test planning, et cetera, et cetera. And one day, I spent an hour with the test manager trying to refine that dashboard in terms of the information that was coming. And I posed a bunch of questions, and the development manager happened to pass by. And since I had been asking a few tough questions the previous days, the next day, the reports stopped coming. Why? Because they thought, oh, maybe this information can be used against me. People are just not, when there's lack of trust, people don't want to be transparent. So how can agile help in here? So I think it starts with the concept of team, where the team's identity is the team, not individual functions. In fact, the individual functions of developers, testers, can be interchangeable. And that's what builds that trust, that we are all part of that same team. And what helps on top is all this face-to-face interaction. When you meet those people every day versus just getting emails. By the way, email is the worst mode of communication nowadays, because half the context is lost. Having these face-to-face interactions, daily stand-up meetings, pair programming, these are the things which help build that identity of the team and the trust. Now, when there's lack of trust, people don't engage. Or even when they're forced to engage, that engagement tends to be superficial. This is a beautiful cartoon picture which comes from a book by Jim Kramer. It says Moose on the Table. That's the title of the book. Again, wonderful reading. The whole idea this is trying to convey is you have a big problem sitting on the table, and everybody's pretending that the Moose is not there. They're just working around it. And they're doing other things. And that's a dysfunction. How many of you have seen gone into the meetings wherein you spend an hour, two hours at the end of the meeting? You come out and you wonder, what was the result? Didn't we waste time? Has anyone of you felt that way? How frustrating it is. When people don't come to the point, they're just beating around the bush. And again, agile is not a silver bullet, but again, when team members, not just one person sitting in a corner who says, go and build it, when the team itself is involved in that planning process, the estimation process, there's a discussion, there's a debate, and there's a meaningful debate, because those people are working together on a day-to-day basis. They've built some sort of trust. They can argue in the meeting and still come out of the room with smiling faces. And what helps in terms of controlling that analysis paralysis is you have time box decision making. And the other thing is that if you truly agile, you are delivering customer value on a frequent basis. So you don't need to sit and keep analyzing what if, what if, what if. Sometimes just building it and shipping it and getting that feedback is a lot more productive than just thinking what ifs. And in this web application world, how many of you are familiar with exposure control or A-B testing? It's a wonderful way to get early feedback to avoid this kind of analysis paralysis. You quickly, you think of some idea, you build it, and expose it to a small set of customers. This is what Facebook, Google, Amazon, they do it on a daily basis. They build new features and expose to a small subset. Get that feedback. Use that information as a feedback loop to improve the end delivery. Now, if you go to that pyramid, the third dysfunction in that pyramid is lack of commitment. So of course, when there was a lack of trust and there was lack of meaningful debate, people sign up without real commitment. So there's not a real buy-in. It's a very superficial, yeah, I'm doing it because I'm doing it because I've been signed up. But that passion, that commitment is not there from inside. And how does it manifest? Various ways. One of the things I've noticed in a lot of teams is because there's not enough debate, everything becomes high priority. I had to deal with one situation wherein even though the team was supposedly adopting agile, but their initial, because we're still learning, their initial set of user stories, the product owner came back with 97 user stories. And when asked to prioritize, he said 95 are must ship. That's prioritization. 95 out of 97. And I really got into a debate for them. I asked him, do you really think all 95 are showstoppers? He said, yeah, because that's like the base functionality. Competition has it. We have to have it. My response was, you can take it in writing to me. If you want everything, you will get nothing. Because I can guarantee you all 95 will not be done, because they're always unknowns. And I think that got the message across. And the team then went through another round of prioritization. And they came back with three buckets. The must have, important, nice to have. And it was sort of equally distributed. And when you go through the superficial commitment, people are very hesitant to change, because they feel, oh, if I go through this another change, means we'll go through this analysis, paralysis again. And we never get to the decision. So how can agile help in these kind of situations? One, I think there's a strong emphasis on teams. It's the teams who actually pick stuff from the backlog and commit to it. It's not somebody else from outside saying, thou shall deliver x, y, z. The team is going through the backlog. They plan their sprint. They go through the exit criteria of the sprint. They do the demos, and they deliver. So there's a sense of that commitment, ownership. And what helps is, anytime there's a change, you have a prioritized backlog. So you stick things in the order of priority, wherever the new change belongs. So that way there's less randomization for the overall goals of the team. Now this is a big one. I think that Lady Howard mentioned about accountability. What is accountability when people hesitate to call out the bad behavior? Who do you think really owns the product? You get different answers. I'm curious, some of the answers you might have. What have you heard maybe from teams when you really press them hard? Who do you think owns the product? Any answers here? I'll start with. I've heard saying, don't know. Or maybe it's my boss. Anything else you have heard? Everybody owns it. So if it's everybody's problem, then it's nobody's problem. The best one I've heard was when I asked, who do you think really owns it? The answer was CEO. And I was like, CEO, why do you think it is CEO? Oh, because CEO set the direction. He made a big announcement to the press that we are going to deliver blah, blah, blah next year. So he's the product owner. That just blew my mind away. And you end up in this kind of this scheduled chicken. How many of you are familiar with this term scheduled chicken? Anyone? So scheduled chicken is basically when you have dependencies across teams, you're waiting on somebody else to call out that they are off the track. So then so that you can use that an excuse because the team on which I'm dependent on is delayed, so I'm delayed. So scheduled chicken is that each one is waiting on to call out the other one. Who will confess first? And if nobody confesses in the end, the hell breaks loose. And the blame game starts. This is a nice example of not my problem, lack of accountability. This is a picture of a road I took. You can see what's wrong with it. There's a big, high-tension electricity tower on the edge of the road. So this is probably version two of the road. Version one had maybe two lanes. Then they widened it. I did one more lane. And nicely put a lane marking also. The guy did his job, removal of the pole. According to him, not my job. So the sense of excellence or pride is missing in this case. And that's where Agile helps. Because when you have a clearly defined product owner, anybody can go and talk to that person and debate and argue and have that passion around building that product, half the problems are solved. And when team has a daily stand up, the focus is not on blame game, but finding out what the impediments are and how to overcome them. Every day team is looking for moving forward and not trying to figure out that scheduled chicken. And the team is making itself accountable by having commitments, not just commitments at the end of the project, but commitments at every sprint with where you actually do a live demo of what you build. So the final, this is the most important one. Because if individuals are putting their needs first, then the collective goal, which in this case is the working software, then you never got the results you wanted. How does it manifest? How many of you have heard this phrase when you ask somebody, hey, how is the project going? Are you done with coding? Yeah, 90%. Are you done the testing? Yeah, yeah, almost done, 90%. The fact is when if you hear the 90% phrase over and over, you actually need to do a multiplication by from everybody you hear. So 0.9 into 0.9 into 0.9. So your probability of getting that thing on time is probably 50%. And when the team is in these kind of dysfunctions, instead of what the end goal is, the process itself becomes the end goal. Too many times I've seen where there's heavy focus on dashboards. Oh, this is red. Why is it red? Why this is yellow? When do you think this yellow will turn into green? And there are lots of reviews. Review after review, there's a war room being set up. Everybody just going over discussions. There's not enough background information around it. And in the end, it's the bad quality. And the stuff that the customers reject. And if you look at agile, one of the principles is focus on the customer, not the process. Process is secondary. If the stuff doesn't work for customer, it just doesn't work. And the focus is not on PowerPoint presentations. Focus is not on those dashboards. You could have nice green dashboards and the product could still fail. The focus is on working software. And what helps is clearly defined sprint goals and clearly defined working software as a proof. So with that, I believe agile brings in a new social contract, which helps break down some of these silos, helps break down these walls, and helps alleviate some of these dysfunctions. And that's the end of my presentation.