 It is more on usability point of view. I was noticing that yesterday and today, some presentations really took a big hit in terms of colors. So I decided that black and white is what is going to save me today and you as well. It is going to improve readability. It is going to help us understand the topic well. Let us begin slowly and set the context. So strategy gets set at the top. We all know that. And power trickles down. Big leaders appoint little leaders. We have seen that. And individuals compete for promotions. Compensation correlates with the rank. The higher the rank you are, you get higher compensation. It's never the other way around in any part of the world. Tasks are assigned. Manages assess performance. We all know that. And this is the recipe for. And it is a 150-year-old mashup. Started with military command. Started in old organizations, industrial era. And it has penetrated every large organization. And it is the unchallenged tenets of bureaucracy that disables, that makes organizations very inertial, slow, incremental, and uninspiring. So this is what one of the top management gurus said. I don't think any of us are going to refute or challenge this. Well said. A quote worth remembering. And Max Weber is known for founding a bureaucracy and defining the principles. If you look at four in the list, he says, officials do not own the resources necessary for the performance of their assigned functions, but are accountable for their use of the resources. So this is how things started. You are responsible for your line of business. You go and lodge a complaint in a police station. The answer you hear is, no. This crime did not happen in our territory. So you have to go to some other place. So that is called bureaucracy. Defined rules, defined set of constraints within which you need to operate. You cannot change the rules. You cannot have any flexibility. You cannot make decisions. Decisions are made elsewhere, and everything trickles down. And so what? So when there is bureaucracy in geographically distributed teams, you will find powerful forces setting some rules, defining practices, and mandating criteria. Suddenly, you will see there is some kind of a PMO setup, some kind of leaders coming together and saying, you know, we are the center of excellence. We codify the rules. We codify the methodology. And there will be several followers who are ready to succumb to the pressure. Because we are all workers. We need our monthly salaries. We succumb to those pressures. And you will see specialized definitions, measurement, criteria, rituals, frameworks, so on and so forth. People going and talking in conferences, people coming and listening to people in conferences, and whatnot. Decision making will move up in the hierarchy. And teams will practice practices just for the sake of practice. And so this is what I wrote in the proposal when I wanted to speak in this conference. And that is a slippery slope. When you form agile teams, and teams started practicing practices just for the sake of practicing is a big crime. That is a slippery slope. And when you consider geographically distributed teams, especially when multiple organizations come together, there are powerful leaders, it is very difficult and challenging to guard against bureaucracy. There will be some element. You'll be seeing it here and there. And when that happens, we cannot have true agile enablement. It is very difficult to have true agile enablement. You may talk about agility, self-empowered teams doing this and that. Eventually, you will find that things are becoming more and more. We have become very serious now. Just to lighten you up. Kindly fill out this application for the reduction of bureaucracy, a good humorous cartoon. And one thing is true. Bureaucracy and efficiency are pointing at two different directions. If you want to gain efficiency, we need to or we must reduce bureaucracy. Can you point out or call out any bureaucratic organization which is known for highest level of efficiencies? So don't quote me those six sigma studies and the data that were collected and presented elsewhere. So it should come from the ground. It should come from the customers. It should come from the employees where they say that yes, we are a bureaucratic organization and we are truly efficient. It is impossible to find. And Einstein said this. Bureaucracy is the death of all sound work. It works when you have to do a lot of run-of-the-mill, monotonous work. You have to carry on certain things, industrialized work. You have to lay roads. You have to create thousands of automobiles. It works. But it's not good for a lot of sound work. So before we move on, a quick introduction about myself. My name, Raja Bhavani. I work for Cognizant Technology Solutions. And these are my coordinates. I do a lot of writing speaking. You can visit my blog. I have given a URL which is easy to remember. But when you visit that site, you're going to see only one post. And that post is going to give you a link for another site which has a lot of my writing. So the idea there is you can quickly remember what the site is. So enough of introduction. So what is in store now for this maybe 20, 25 minutes left from now? I'm going to share with you eight patterns that I have observed in geographically large distributed teams. We'll analyze one pattern thoroughly. And I'm going to put the remaining seven patterns in a quick format with some examples. And some experience sharing. And of course, when we are presenting, there'll be discussions coming from you. And some parting thoughts and some time for questions and answers. Do you have any other expectations? Let's move on. So people in the last row, are you able to read the fonts on this cartoon to some extent? You are able to? So this is about a QA director who wants to enforce some kind of bureaucratic processes. It is perceived among the employees as bureaucratic processes. When these things get implemented, they, of course, talk about it in the hallway or in the break room. And this is a humor about. So the first pattern is about practice bureaus. So an example or the context is that your delivery organization announces that three practices are mandatory in all projects in order to be qualified as agile projects. They say, oh, are you doing agile projects? Then you should have these three practices implemented in those. If not, we will not call them as agile. That is the context. And these practices are pair programming, test driven development, and story point estimation. So is it bureaucracy? How many of you agree? How many of you? How many of you agree? Raise your hands. How many of you disagree? That's where it's at. You disagree. So can one of you who disagree tell me why you disagree? What is your assumption? So you agree that it is bureaucracy. Anyone who disagrees? So as we move on, I think your thoughts will clarify. That's my assumption. So let me move on. So when we talk about patterns, I wanted to design these as patterns because patterns have a unique structure. So you start with the context. And the context is driven by one or more forces. And we should understand what those forces are. And any context is rooted because of a problem. That is a problem because of which that context is set in an organization. Someone says that these three processes are mandatory because the problem is something. Because of that problem, he's telling that. And what can be a solution? And when you try to bring in a solution, what can be the consequences? So we have to look at the whole thing together as a pattern. So whenever you try to design a management pattern or a design pattern, there is a structure for that. And it is defined in a paper, which I have sourced here, which is how to write a pattern. So you can search for it on the internet. It talks about how to write a pattern. And also it gives a very simple example of when you conceive a door knob as a pattern, how you conceive it as a pattern, and what are these things. So it has a very simple example. Go through that. So now we are going to look at this practice bureaucracy as a pattern and see what the context is. So the context is that you are part of a large distributor project. And your delivery organization announced that these three practices are mandatory. So that is the context. And what is the problem? The problem is that you want to deliver value to customer by improving code quality, eliminating defects, and improving estimation accuracy. Or the problem can be that either in the same project or in the same account, you underwent several escalations related to these three areas. Unit testing was not done properly. Code was not written well. The abuse were not happening. Or estimations were never accurate. There are a lot of overruns. So because of those experiences or because of this problem, someone in your organization says that if you are executing an agile project, those three practices are mandatory. And let us see what is next. What are the forces? The forces are that, yes, number one, we should improve code quality. We should remove unit level defects within iterations, establish an approach for estimation, and improve estimation accuracy. So those are the forces. So those forces are establishing this context. And the problem that we talked about is establishing the context. So what can we do about it? We have to find a solution which is meaningful. So here is a solution. Follow principles first approach. Look at what agile principles are talking about. What are those? What do they mean to us? Read about agile principles. There are several good papers, articles, on those 12 agile principles. And last year in our conference, I delivered a session on 10 principles for distributed agile. So that is based on a published article in one of the reputed journals. Go through those principles. And then relate practices to principles. Now the question is if you want to improve or if you want to resolve all defects within a sprint, all unit level defects, is test-driven development the only practice or can you find other practices? And invest in agile coaching. Sometimes because of lack of understanding among people, sometimes because of lack of time in doing a thorough study of what things are and taking the wise decision, people go to somebody, ask some questions and go with that. So when you have a permanent position like an agile coach in your project, there is ample opportunity for you to talk to that person and resolve such problems. And many expert agile coaches do principle-based coaching. They take each principle at a time and they coach the team and then they map principles to practices. And upgrade your organizational policies. If your policy is rigid, ask why it is rigid. Make it flexible. If your policy says that for a project to be agile, these are the three practices to be followed. Ask that question, why is it so rigid? What else can we do to make it flexible? So these are the solutions. And when you do that from the pattern definition point of view, it is also good to look at the benefits. What are the benefits of attacking this problem? Is it a problem? Is it a battle worth fighting? What are the benefits? Yes, there are benefits. You understand your project needs and follow the essence of agile software development. Instead of blindly following certain practices or imposing practices on your team. How many people who impose TDD on their team have done TDD? How many people who talk about TDD, they have done TDD, none of them. And people who do TDD, they don't impose it. They do it, demonstrate it, and coach their team. And the same thing, people who talk about static analysis. How many of them have experienced static analysis? My suggestion is sit in front of a computer, take a segment of code or a bunch of programs, put them through static analysis, go through all observations, understand what those mean to you. Then you know that, so that kind of relates us to the keynote of today. So if you are preaching practices, if you are dictating practices, go and see what is happening on the ground and experience it. And the second benefit is this will result both in team satisfaction and customer satisfaction. So when team feels it, yes, what we do makes sense to us. What we do helps us learn new things. They get a better level of satisfaction, and of course that is going to satisfy a customer as well. And what are the liabilities? So whenever you want to solve a problem, you have liabilities. So number one is you need to put a lot of efforts in identifying practice bureaucracy, whether it is, whether you are seeing this pattern in your organization. And you need to be mature enough to avoid ad hoc development approaches that violate or ignore agile principles. So which means that you have to be a subject matter experts or you have to have reasonable experience in this area. Otherwise you may not, you will be living with practice bureaucracy. You will not be able to figure out what it is. And questioning organizational policies will pose challenges. You may be conflicting with your peers or superiors. And even if they buy in and say yes, let us do it, go ahead, change, and bring in something new here, you must be confident of bringing in the change and deliver this. Otherwise you know what will happen. So you have to be authentic, you have to have authenticity. And you should have conviction and you should be bold in fighting against it and bringing in a change. And demonstrate that yes, it works. That is the kind of value we can bring to our organization and our customer. And when we lack awareness, we live with bureaucracy. When we lack awareness, we become bureaucrats. And we will not be able to understand what I am talking about. And when we build awareness, we become authentic. The level of conviction improves. We become balanced and people follow us. And we can bring in this change. So any thoughts before we move on? Any contradictory thoughts, any challenges, questions? Yes, yes, yes, yes, it has to be interesting. Yes, yes, okay. When you are at a starting point, assume that your organization is new to Ajay, you are starting some 10 projects over a period of six months. Can you bring in a rule like this? I can argue for both yes and no. The answer is yes, if all projects qualify for these practices. And if all teams are mature enough to carry on with this practice. No, if you're working on a platform or you're working with a customer or you're working with a team, they are not suitable, they are not mature enough to take on these practices. So in which case you have to go step by step coaching. So as an organizational leader, you say, you know, I have 20 years of experience in Ajay. And without these practices, none of the projects succeed. So in our new organization, every team must do these three practices. You know how I will name you. And if you believe in saying that yes, even though I have 20 years of experience, I want to institutionalize or bring in an Ajay coach, do principle-based coaching and identify the right practices and put in continuous improvement in practice and slowly mature my teams, sprint after sprint, then it works. It makes a lot of sense. The teams will have fun doing that. Otherwise, every time you intervene, there'll be process audits, there'll be some high-level meetings. So these two teams are doing TDD. Those eight teams are not doing TDD. Why? And the question is, do you know what TDD is? No, someone said TDD is something, so I'm asking that question. That is bureaucracy. Okay, we'll raise the hands. Hands rising exercise. How many of you have seen similar, not the example, but similar process-related bureaucracy exists in organizations? No, see, there is when we conclude this session, you will get an answer to this question. I'm not trying to pose a picture that all bureaucrats are bad. Or bureaucracy as a term is a bad thing. I'm just setting the context and giving you some examples. In an organization, if there is a leader who comes in and says, yes, we should go and implement agile, yeah. Okay, it is very contextual. We take it offline and discuss among ourselves, yeah. You have any questions? So the next slide is going to answer, give you more, or more meat for you to digest. So that is about documented processes or common sense. So do we mean to say that we have had common sense all these years? Do we mean to say that we have had documented process all these years? How do these two parameters go together? This is how. So when you have documented processes, is it good? Good to have documented processes. So by this, we mean, yes, they're documented well, version control, they make sense, there are no errors, they're reviewed properly, and everyone created it, and everyone who is maintaining it, they're all experts, they're doing a good job. Okay, that is the assumption. When that happens, and when there is common sense, quality prevails, you will see quality all across. Because when you talk about large teams, you cannot have undocumented processes. Number two is when you do not have documented processes, but lot of common sense, that is called creative chaos. Meaning, a lot of meetings and discussions, people come up with a lot of ideas, talk about their knowledge, their experience, but nothing is taken on the ground and implemented. And when you don't have common sense and bureaucracy, it's called mindless bureaucracy. It's like you create numbers, you create reports, you say that no, so many road accidents happened in Bangalore, and so many, for so many accidents, the police went and attended to the victims on time, but they don't talk about the outcome. They don't look at the qualitative parameters. So you measure the numbers, you survive, and it is called mindless bureaucracy. And when both are, no, you don't have common sense, you don't have documented processes, it is mindless. Two should go together. And what about discipline and bureaucracy? They are interrelated. What is, have you seen highly disciplined teams? So do you mean to say that those teams are highly bureaucratic? Or you say teams who have very low discipline and then there's no bureaucracy, does it mean a lot of freedom? What is, look at it. When there is low discipline and when there is low bureaucracy, it's just time pass. You don't have any discipline, you don't have any, it is like a vacation time, right? You take your family on a vacation time, no rules, no regulations, just time pass. And when you have high level of discipline and high level of bureaucracy, you're able to move in a controlled pace and write things are done. People know what to do, people move at a certain pace. But when there is low discipline, things load up. Not all, all things get done. You'll see most of the government organizations fall under this quarter. High bureaucracy and low, they plan to do so many things, they do only so many things. But what happens when there is low bureaucracy and high discipline? You get a lot of freedom, write things are done faster even if the environment is dynamic, yes. When discipline comes within you, right? It is, you build discipline within you, it is never negative, it is good. When it is imposed on somebody, it's questionable, right? It is between person A and person B, how they deal with it. Otherwise, discipline is a good thing. Agile teams are highly disciplined. You cannot have an agile team succeed without discipline. Successful agile teams are highly disciplined. Though they value their time, they value their integrity, they value their team. And all that comes into discipline, right? How they live their day at work. Again, we can have a follow-up conversation if you're going to be around either this evening or for the dinner. And now, do you think geographically distributed large teams innovate? We talk about innovation, right? New things should happen. They have to come up with some new ideas. What happens? That is about my second pattern. It's called innovation barricade. It goes like this. New ideas, let us focus on what is going now. Let us complete the project, let us talk about it later. So that is how bureaucrats try to push things away, push things down. And it goes like this. Some reason is found, some mechanism is found to postpone ideas. I'm not telling that it happens in every place. That is, the question is, are you finding this pattern? In some organizations, they have initiatives to nurture new ideas. So they don't push down ideas like this. They nurture ideas, they allocate a coach or a mentor so people can take things forward. And the third pattern is about development, heard it. And people want to develop themselves. People want to become better players, better performers. And you say, oh, you want a training program? It takes about two or three weeks to get an approval. And it is, bureaucracy is an art of making the possible impossible. So it's all built into us. It's all built into all modern organizations. And no organization is an exclusion until we are conscious about it and try to reduce the amount of bureaucracy. And the fourth pattern is about infrastructure blockade. Have you come across this? You know, that video conference room is only for board meetings. I don't think you can use it for scrimmage themes. And you find that that board room is used only 0.005% of the time in a year, otherwise it's either. And here is another example. You know, there is a limit on your email box. And you want to go and get some approval. And this cartoon depicts what happens in a bureaucratic organization. So again, the people on the last bench are able to read this. I think so. And the fifth pattern is called methodology obsession. You get obsessed with the methodology. And you say, we are an XRXM house or shop. So I've not named any methodology here. And also, you say, we are marrying IKTL with XRXM. So that is a new strategy for our organization. We are bringing this together. And we are seeing how this can bring in synergy for our customers. And we have believed in organizational methodology. So what happens is something like this. This is another brilliant cartoon. Somebody wants to go and meet somebody in the third floor. And somebody tells where he is and how to meet. And by the time this person comes back to the desk, he sees an email which says that help desk ticket was created and closed. Why? You want to maintain the numbers. Your performance is measured on the number of tickets closed. And you are generous enough because your senior manager came to you and asked where this person is. So you are generous enough to create the ticket and close it. So if that person was a software developer, you will say, you go back to your desk, create a help desk ticket, come back to me. I will tell you where this person sits. And once you meet, you have to send me an email. I will ask you, can I close this ticket? Was your meeting satisfactory? Because that is a part of some framework, which says that before closing a ticket, you have to measure customer satisfaction. But all these are good. Don't let that become bureaucracy. And I have listed six, seven, and eight. Because now you know how we are progressing and what we are talking about in this session. Tools dictatorship. You may be in the middle of this project, but it is our organizational decision to migrate from tool X to tool. So there is no question about why, why not? What can be the impact on customer, et cetera? One, upmanship. We will do the root cause analysis here in our location and announce the result to the rest of the locations, which means the distributed teams are not involved. There is some one upmanship going on. And governance. Governance teams, we are all very busy. We don't have time. We are going to skip over the next two or three weeks or three months. And later, if there is an escalation, come to me. I will come and participate in the governance meeting. So distributed agile or working with a large team and governing the team, being a part of the governance team has a lot more significance than being an escalation-based governance. So these are some of the patterns I wanted to talk about. And this is the reality. The bureaucracy is expanding to meet the needs of expanding bureaucrats, whether you admit or not. So if I am sitting there, I may feel a little inconvenient when somebody talks like that. And I am part of you. And every organization has bureaucratic processes. And it expands. However, this is something we should understand. It depends on the social structure. So every organization has a social fabric. And every country has a social fabric. And the technical structure or the organizational structure as defined in your company can be low in bureaucracy or high in bureaucracy. But if your social structure is enabling, encouraging, then you may be in the top quadrant, where the bureaucracy is about enabling your employees. That is called constructive or enabling bureaucracy. It's good, where you will see empowered employees. And hopefully, they will not become bureaucrats because they are in the culture of enabling. And rules and procedures as enabling tools rather than enforced tools. And hierarchy supports organizational learning. They are ready to listen to each other. They are ready to talk about problems and find resolutions to problems. So if you are in that quadrant, it is good. Otherwise, we are in the down quadrant. It is like a very small bureaucratic company, top-down control, minimum written rules, and you own business. And if you are in an environment where it is coercive and high in bureaucracy, it's very dangerous. Rigid rules, extensive written rules and procedures, hierarchical controls. So you will see in many government departments, they don't even smile at you. They don't even ask you to sit. That is an example of coercive and highly bureaucratic environment. I know all IT companies are there in the top quadrant. You'll see a lot of symptoms of enabling bureaucracy. You'll see leaders who are ready to listen to you, who are approachable. You may find other types of leaders also. So the message here is, so far I was kind of painting a picture in your mind that bureaucracy is all bad, but it's not. If you belong to a social fabric which is enabling, even if you see high bureaucracy, it will be for good. Because it's going to enable your team. It's going to be flexible. People are going to listen to you and find solutions to problems. They are going to listen to your ideas and alternatives, which is good. So now what are the parting thoughts out of this session? Enabling bureaucracy is good, but not coercive bureaucracy. It's bad. And start with principles and follow practices. So don't kind of tie yourselves to refactoring, or bad programming, or test-driven development. So these are all practices. Understand the principles very well. If someone says, we do 100% test-driven development in our project, it doesn't mean that that project is superior than your project. Because, of course, the cost of test-driven development and the return, if you see, there is a diminishing curve. After a certain level, the return on TDD flattens or goes down. So if you're doing TDD, you should know how much TDD is good. What kind of TDD is good? How much is good? When is the right time? And what are the industry experts talking about TDD? And what are the upcoming trends in TDD? So take the principles-based approach and follow practices. Consider agile coaching. In large, geographically distributed teams, it is necessary to have agile coaches who are practitioners or who have been practitioners who can work with the teams and put together the right set of things. Invest in agile, aware leaders and include them in governance teams. Otherwise, you'll get into a lot of unpleasant discussions. Why is the velocity of this team is 60 and the velocity of that team is 45? So those kind of questions will come again and again unless you have agile, aware leaders. And conduct effective retrospectives to see if you're doing something that makes sense to you, that provides direct benefits to your customers. And inspect and adapt. Whenever you see that efficiency is drowning, remember that picture. So bureaucracy is pulling you in the other direction. And it is highly possible that it can happen in large-scale distributed agile projects. So with that, do you have any questions? Yes. I'll take it from here. My take is that, yes, communication coordination that has been a problem in software engineering teams as well as other teams for so long. And it is not enough if we focus only on communication coordination problems. So what if you perfect your communication coordination patterns and if you're going to fall into these traps? Your efficiency will go down. Who else says? You have to become an authentic leader. People should start seeing you as a subject matter expert. And you've seen that in your organization, right? So you'll find some people who are down in the hierarchy, but people are ready to listen to them. You know there is a design problem. You know there's a technical issue. You call that person. And you're ready to listen to. So what should we do now? So you have to come to a level where people are ready to say, oh, what do you suggest now? So for that, you need to build authenticity. And that should increase your conviction to get into, identify, and solve this. If we are half-baked, efficiency will go down. Yes, it's everywhere. If it is not there, tell me. We'll go out for dinner. It's there everywhere. We should open our hearts and accept it. And that's why I told you, sometimes we become bureaucrats. And sometimes we become victims of bureaucrats. Agile, non-agile, everywhere. Anyone, any other questions? What is the time now? Four. What is the time? Good. Thank you.