 We are into agile DevOps transformation, project management, coaching, competency development, and some of the strategic consulting like organization design, cross-functional integration, and governance, those areas. So today, I would like to talk about knowledge that are paradigms. That means, what's the fundamental rationale behind agile, especially? So what I see normally in our consulting is that typically, there is a journey of agile where it starts with more of a team structure and looking at the roles. Then people get into scrim practices, artifacts, the ceremonies. Then they look at engineering practices and more of data-driven practices, size, velocity, quality data, et cetera. Then the culture change aspects. Even though culture change aspects begins a little early, but it takes quite a while to really make the change of the transition. But that's where the highest value and sustenance of agile practices happens. But that's the hardest part we see. What we notice is that the key reason why that's a big challenge is that, can we address the sound, please? So the key reason that we see is typically organizations address about what and how aspects of agile, what needs to be done, how to do, et cetera. And not enough focus on why it needs to be done. Even at team level and much more at management and leadership level. So without that understanding, they get into looking at agile as yet another process model or a framework and a prescription. And then it gets into the similar mode like any other standards and processes. So we thought we should focus more on this. So that's the context I'm going to talk about today. For that, we need to really look at going to the fundamentals. What's the real fundamental reasons why the agile is looked at this way? And if you have to look that, we have to go into the history. If you look at a few years back or a centuries back, we used to have an agriculture era, which was local farmers used to plow in the field. And it was very labor intensive. The challenge at that time was how to mass produce and how to distribute it to the larger part of the world. So in order to solve that, the industrial era came. Mechanization, mass production, with that globalization, manufacturing driven economy, product design, then the challenge moved up to product design and innovation. Whichever companies became good at that, they became the differentiators. And now we are into knowledge era, which is extreme globalization anytime, anywhere, like internet. Knowledge driven industries, economies. Now, challenges moving further up. Thinking, collective wisdom. It's not just about individual thinking. It's about collective thinking in a team, including customers. So whichever organization or group of teams are able to do that better, they get differentiated. So there is a nice statement from Stephen Covey. Everything in this world is done twice, once in the mind and then in the outside world. You know, if you look at that, whatever you want to do in the outside world, first it has to happen in the mind, then in the outside world. So we have kind of mastered doing it in the outside world, in the industrial era. In the knowledge era, it's the challenge of doing it in the mind. And not just in one mind, but in collective minds. So it's the challenge in knowledge era is accuracy and speed of thinking and collective thinking. We have a huge legacy of industrial era, which is, we are not very conscious, but it is driving so much of our thinking, decision making, organization designs, every aspect in the organization. If you look at an industrial era product business, 20% were design creation intensive, and 80% were mass production distribution intensive. Now you come to knowledge era product businesses, 80% are design creation intensive, and mass production distribution is almost trivial. But all of our learning, in terms of, if you look at management, leadership, quality aspects, CMMI, Six Sigma, ISO, which are all come from PMI, for example, from construction industry, all of them have come from a mass production context. And we are trying to apply that into design creation intensive work. That is causing most of the fictions between practitioners and preachers. In the current management leadership, quality management philosophies in software industry, we need to reapply them. Basic principles are still valid. For example, if you look at whole agile, it's influenced by the lean, which has come from Toyota production system, which is a kind of a manufacturing-oriented industry. In fact, I worked in Motorola for about eight years. I worked at Six Sigma. At that time, Motorola was working with SCI and Carnegie Mellon University. I closely interacted with Watson-Prix. So I know how things have come from that paradigm, and how they got become a software standard. But we need to reapply and rethink, because that has come from a different paradigm. So if you have to now go to those fundamentals, we need to ask you basic questions. What is the raw material for software? And I think about that. Any quick thoughts? What's the raw material for software? Yeah, it's more of our ideas, knowledge. They're the raw material. And if you look at, where does the transformation from raw material to finished product happen? Physically, where does it happen? It happens in people's mind, right? It's not happening on computer, because computer is a dumb tool which captures whatever we type. So really, transformation from raw material to finished product is happening in people's mind. This is a very important point to note. So if it's happening in people's mind, how do we know how the transformation is happening? If somebody says, don't worry, architecture is happening, no, we have no clue what's happening, right? So basically, then we have to split that, break into smaller steps, and bring visibility. This is the most important point, because nobody else will know what's happening in my mind unless I bring it out through various ways, either pictures, documents, models, prototypes, communication. Then what's the measuring equipment to verify whether transformation is happening correctly or not? You know, in a physical world, I can take a calipers and measure precisely 10 centimeter plus or minus, you know, one millimeter, whatever. What is equivalent of such a calipers in our context? Any idea? Any thoughts? It's another knowledge body. It's experts, peers, customers. They are the real measuring equipment in our context, because there is no absolute truth here. See, this is a very big context shift. If you look at the knowledge or a product engineering, from raw material to finished product, the object is not physical in nature. And there are no laws of physics governing the engineering principles, like in mechanical or civil engineering. In fact, this is the first time, as an engineering discipline, we are dealing with something where there is no physical object. And we are dealing with transformation engine as human mind, not stereotype machines. This is the biggest paradigm shift. If you understand this, then we'll figure out what to do, how to do in a much more innovative way. So a few contrasts between knowledge era and industrial era. If you look at raw material, industrial era, physical in nature. In knowledge era, it's intangible in nature. Knowledge, ideas, transformation engines, they're stereotype, repetitive. You know, if you look at shop floor, you tune the machine once it stays tuned. And all machines can be very civil. You come to our industry, people are the transformation engines. They're idiosyncrotic. Each one is unique. And their characteristics are changing. Again, very important to notice. From morning to evening, this machine's characteristic is changing based on who says what, what manager gives a feedback. So many things, right? Even more, if you just reflect, every evening, machines are walking out of the door. And next morning, they're coming back, slightly changed because they interact with family, social context. Look at this context. So every morning, we are setting up the shop floor fresh with some kind of new machines. In a sense, the stand-ups are like shop floor setting up meetings. Connect the machines, calibrate the machines, tune that machines so that process starts. Productivity, in industrial era, the fundamental productivity was called touch time of tool. That means how much a tool is touching the raw material to make the transformation happen. That's how the whole concept of shift and all came because maximized the utilization of the tool. Now come to knowledge era. Any guesses? Any thought what it could be? Fundamental measure of productivity. It's called touch time of minds. Because that is where the transformation is happening. See, I may be sitting in front of the computer for eight hours. Nothing might happen because my mind is somewhere else. I may log a time sheet at eight hours, but really nothing has happened on the ground. Because what is important is touch time of mind. That means how much is mind is engaged in this transformation process. That's the real product. So interaction in industrial era, people work around the machines. And in knowledge era, people work with people, including customers. That's why it's very high collaboration, communication. The equation in industrial era was man machine material. You can say 3M. You come to our era. It's 3C. Capable people collaborating with common protocol. In the first place, each of these machines should be capable. But it's not good enough. If they cannot collaborate, projects will fail. You know that, right? I mean, if there are too many heroes or heroines in the project who cannot talk to each other, they may be independently very brilliant, but the project will not succeed. And in order to collaborate, what they need is common protocol. It's not about what is the best process. What is the common process is more important. See, it's not about whether English is the best language, Hindi or Kannada or Tamil is the best language. That doesn't matter. What is the common language in the team? That's most important. So it's about common protocol. Now I want to take you through five key paradigm shifts. There are many, but five paradigm shifts which actually drive home why you should be looking at agile this way. Because agile is really looking at knowledge that are paradigms in a very appropriate way. So first paradigm shift is repeatable process to contextual process. If I ask you this question, what is process? Think of a phrase or sentence to describe process. Somebody comes to you and asks, what is process? You just think of what would be your response. Thought about that? Now let me post few options whether any of these definitions came to your mind. Set of steps to perform to get output from input. Sequence of operations to be performed. Standard way of doing things. Repeatable tasks to be performed. Clearly documented instructions to do a job. Are one or many of these definitions came to your mind? Now do you see from which paradigm these definitions are coming? It's a shop floor. There is a raw material comes, goes through multiple machines, comes out. We are so much influenced by the industrial era because 300 years of industrialization. And we tend to extrapolate that and apply it to the new context. Whereas our context is very different. Because we are dealing with human beings here as the transformation engine and intangibles as the raw material. So small game with mathematics. I want to get six out of these numbers by performing different operations. Can you try? Let's start with simple one. Two, two, two, how do you get six? Two plus two plus two, six, easy. How do you get five, five, five, six? Yes, five plus five by five, right? Then you will get seven, seven as well. How do you get seven? Yeah, seven minus seven by seven. You'll get six. Six, six, six, easy. Six plus six minus six. How do you get four, four, four, two, six? Square root of four. Square root of four plus square root of four plus four. Then you will get eight as well. Cube root of eight. How do you get three, three, three to six? Three into three minus three. You'll get six. Then you'll get nine. Because square root of nine, you'll get eight. Last one, one and six. How do you get that? One plus one plus, exactly. Great. But the moral of the story is if you have variable input and if you want to get consistent output, you need to change the operation, right? In a function f of x is equal to y, if x is varying and if you want to get constant y, you have to change the function. That means we have to constantly change the process because our input conditions are highly variable. So are you looking at repeatable process or consistent outcome? What are you interested in? Consistent outcome. But repeatable process leads to consistent outcome is an industrial era paradigm because input is fairly homogeneous and you tune the machines, you focus on the process, you can get consistent outcome. You come to our context in knowledge era, like in software, input has high variability. People, technology, each project context, it's highly variable. So in order to maintain output consistent process should change, but we have driven repeatable process. So the paradigm shift is focus from, should be on contextual process, not repeatable process and consistent outcome. So this is the new equation for us. So that's one paradigm shift. You can apply it into then, you know, how to look at, you know, each of the project context. Second paradigm shift is process driven to principles driven. See, the variability is so high and we want to get productivity, quality, consistent outcome. Can we define rules and do's and don'ts for all possible cases? Is that possible? Then this variability is very high. Can we define rules and do's and don'ts for all possible cases? Not possible. So how do we manage? That's why values and principle, because they give the broad direction and then people figure out, because these are intelligent machines, they figure out what to do, how to do. And that's where innovation happens. That's why values and principles are so important to internalize and work with that, rather than getting stuck with mechanics and artifacts. This is what happens in a lot of agile things, we know this, because people have been so conditioned to work with prescriptive models. One example, you know, defect prevention as a mechanism people want to drive. In the industrial era, most defects relate to materials and machines. Number of causes are relatively less. If you take poor soldering, now there are finite number of causes, temperature, surface, the soldering phase, material. And once you tune that, machine stays tuned. So defect prevention, you can do through a checklist. You come to our context, most defects relate to human errors. In fact, 80% of software defects are human errors, oversight, it's not that they didn't know technology or they didn't know domain, it's human errors. Number of causes are relatively large, if you take poor coding, so many causes. And defect fix is mostly not physical in nature, it's in about thinking, communication, right? And the personal characteristics continuously change in our context. So how do you do defect prevention? We can't use the old approaches of the industrialization, but we have been driving that in many standards implementation, checklist-based defect prevention. They are useful to some extent, but that's much bigger way we need to look at. Much more than that, I would say, how quickly can we take through learning curve? Because every context is new, every team is new, new context. So how quickly can we take this through a learning curve? That's the most powerful way of defect prevention. That's where in agile, the iterative approach, learn and adopt, learn and adopt cycles in agile, short iterations, retrospectives, they're the most powerful way of defect prevention. So I'm going to the next paradigm shift, touch time of tools, touch time of minds. Normally we do a lot of games and drive home these points, but here, due to lack of time, I'm just giving this, you can try it later. You would have done this exercise somewhere in a different context as well. Essentially you simulate here in this sequential process first, and then in the second round, same two processes you run concurrently in your mind. Basically it's adding two numbers, you do it sequentially versus doing it in parallel. And when you do that, you will see that your productivity drops up to 50% in the second round. That means the moment you are running concurrent process in your mind, your productivity drops so much. And now imagine how many processes will be running in our mind when you come to office. If you just observe for a while, you will know because all the family issues or something happened in the traffic, they all will be still running. We don't know how to stop those processes, right? And come to office, so many processes are running, even the office related processes. Now the most important factor for productivity efficiency quality in software, you know what is that? Single most important factor, it's test time of mind. In fact, when you do that exercise, you will notice that in the second round, when you run concurrent process in the mind, you will make more mistakes. So it's both productivity drops and more quality also drops. And what impacts test time of mind? There are so many. You know, I put few of the causes, clarity vision. For example, if you observe, we struggle a lot with what needs to be done for a long time until we get a clarity. When clarity comes, we can very quickly do that. Emotions have a huge impact, right? Somebody says something, I'm in a very negative mood, I can't work. Positive energy, some days I get up and I feel very exuberant. That day, a lot of things happen. Workplace distractions, emails, stats, you know, phone calls, WhatsApp, all those. Motivation has a huge impact. Interaction with people, how I interact, what feedbacks I get has a huge impact. Mind capacity, this is another very big factor. We are not aware of that. I'll take a minute to highlight that. If you just, you may know, for example, from medical industry, how much of our brain we are utilizing. They say about four to five percent of our brain is actually utilized. And if you observe your own thought process, you will notice that 90 percent of the time, mind will be oscillating between past and future. It will be saying, I should have done that, why that person said like this, or going into the future, I should do this, I should do that, all the planning thing, or fear. You know, what if this happens, what if that happens? Hardly 10 percent engaged in the current moment. Now look at the touch time of mind. Just four to five percent of the brain. In that, just 10 percent. So 0.5 to 0.4 percent of real touch time. Even with that, we are also great. Imagine if you just improve that, what will happen? In fact, we are dealing with a lot of companies on mindfulness. A lot of people are now adopting mindfulness, meditation, yoga, because it has a huge impact on touch time of mind. Now who is responsible for all these things? For the touch time of mind. Individual, right? Somebody else from outside cannot. So major owners is on individual, because they are, as an employee, I am bringing family social contacts as well. I'm not able to detect so much. And nobody else in the office can deal with that. Owners on others, managers, customers, peers, partners, subordinates, they also influence. But the most important factor is that you are one of such others for somebody else. The moment we become aware of that, how we collaborate, how we communicate with others, we change actually. Third factor which influences the organization. Workplace design, organizational policies, all those kind of things. But 80 percent is on individual. That's why I so much focus on self-managed individuals, self-managed teams, because they have to adjust. Then role of scrum master in time boxing, bringing focus, prevention of interference, you know, remove obstacles. All these are actually to improve touch time of mind. It has a huge impact on productivity and quality. So if you understand this rationale, then we'll know why you should be doing. This has a huge impact on leadership, because then leaders need to understand how should I deal with this knowledge worker. Some facts I talked about, almost 80 percent of software defects are human errors. A knowledge worker's productivity varies as much as 25 times based on that state of mind. There are these papers on this. It's not 25 percent, it's 25 times. We can observe our self, right? When I'm not in that mood or my motivation is low, my productivity is so low. Fourth, and the supervised to self-managed. This is a paradigm shift. This I'm taking an analogy. We have actually benchmarked one of the good construction company. They have a different supervisory ratios. One supervisor for every 25 civil construction laborer. One supervisor for every 10 mechanical worker. One supervisor for every five electrician. So what's the moral of the story? Hire the skilled labor, hire the supervision leaders. Now by deduction for software engineering, which is highly skilled labor, we need one supervisor for one engineer. If you have to really manage from outside, manager has to constantly ask now, what's happening in your mind? Is the transformation happening? It's almost one supervisor for one engineer. Practically in other words, each software engineer needs to be self-supervised, right? Self-managing users and self-managed teams in agile. My last paradigm shift, measuring to sensing. This one? This one? That means? Yeah. That means somebody from outside cannot supervise. I need to supervise my own because it's happening in my mind. That means I have to self-supervise, right? Because transformation happening in my mind. So last one, measuring to sensing. I'm taking another metaphor. If you look at iceberg, hardly actually, not even 20%. 10% is visible and maybe 80 to 90% is invisible. It's submerged. But what moves the iceberg? From an outside, if you're not aware, you may think that wind is blowing this way, but the iceberg is moving the other way. Because iceberg move because of undercurrents, which are very invisible. In a project context, what are some of those top tip of the iceberg which are more visible? Any thoughts? What are the visible parameters? Yes, some of the measurements that you have. Efforts, schedule, defects, tools. Those are all visible part of the iceberg. What are some of the invisible part of the iceberg? Satisfaction, okay? Outcome is more visible because it comes to the, as a result, touch time of mind. We don't know how much these people are engaged. Motivation levels of people, how the communication happening in members, collaboration issues. So many things are invisible part of the project. But they are the actually undercurrents, which make or break the project. Have you heard of watermelon metrics? Have you heard of that? From outside, it's all green. If you dig deep, it's all red. You know, project metrics say everything is green, but projects are in deep red. So there are hard aspect, soft aspect. You know, the visible part, which are typically all the measurements, tools, given processes. So much of invisible part, shared vision, motivation, communication, collaboration, team engagement, customer engagement. So many things, which are the much bigger part. But these are not measurable. Tip of the iceberg is measurable. But these are sensible. We can sense it. We can sense the motivation level in team members. We can sense how the collaboration is happening in team. Right? And all this bottom of the iceberg are the leading indicators. They are the cause. And top of the iceberg is lagging indicator. They are the effect. See, defect has happened. Schedule has slipped. What can I do now? Whereas the cause is in the bottom. But we are not able to measure that and we are not paying enough attention to that. Pardon? Exactly, that's what I'm saying. We need to shift the focus into these invisible parts. These are the causes. So management and leadership styles have to shift into more of a sensing part and not just rely on measurements. That's what I'm coming to. So, lot of verbage here. Because of idiosyncratic human beings as the transformation engines and dealing with intangibles like knowledge, idea, et cetera, measurement is a challenge in our industry. We need to first recognize and accept that. What we can measure are perhaps not very significant. We measure so many defect removal efficiency, effort schedule variance, all lagging indicators and we can't manage anything with that. We can do analysis and improvement later but we can't manage. Those which are significant are not so visible, measurable. People experience, motivation, collaboration, level of engagement of people. But they are the most important point. But we can sense them. So the shift has to be from sensing and sense making, from measurement to sensing and sense making, which is a leadership quality. There are slogans like if you can't measure, you can't manage. It's an industrial era paradigm. If you are stuck with that, you can't really manage software projects well because you have to be able to sense much more. Maybe I'll tell a small one story. Yeah, yes. You know, there was one lamp post. It was dark night and there was a person searching for a long time below the lamp post. A passerby came and asked, what are you doing? He said, I'm searching. And he asked, what are you searching for? He said, I lost my gold ring, so I'm searching here. Both of them searched for some more time. They couldn't find anything. Then the passerby asked, did you really lose this here? Then he said, no, no, no, I lost it there, but it's very dark there, so I'm searching here. It's exactly like this current measurement. I can't measure this, so I'm trying to manage by what I can measure, which doesn't work. So focus on visual management in agile is to bring a lot of these soft aspects, make it more transparent and visible. My last slide. So the fundamental of software production. In software production, we are dealing with human beings as the transformation engine, and knowledge as the raw material. First time of minds is the key imperative for higher productivity and quality. Capable people collaborating with common protocol are the critical success factors. And I see agile scrum practices harness these fundamentals very effectively. That's why agile methods are a good scaffolding to build knowledge that are enterprises. You know what's scaffolding? The frames they put up. So I would say agile is a good scaffolding to build knowledge that are enterprises. So with that, I close my talk, focus on why, what and how intelligent machines will figure out. Thank you. We can take some questions because next speaker hasn't yet come. That person has to set up an email. Oh, he's here. Okay, very good question. In terms, what we see is that this mindset shift has to start from leadership and management. And that is the biggest lacking. In fact, managers and leaders hire us and they say go and fix the team. We say 50% problem is fixing you actually. But we can't tell it directly like that. So we, in a surreptitious way, we make sure that they realize this. Because it's a leadership mindset transformation and leadership change or concept change has a role modeling effect. They have to change then the rest people will do. And it has a huge impact on governance measurement because agile teams may be performing, but if the managers are asking the same metrics, setting the same goals, asking the same old questions, they will be driving this team in a wrong way. So we say the 50% challenge is addressing in the leadership layer. Once that happens, things happen. Teams will pick this up very quickly because they are experiencing that. Moment you say that they understand it very well. It is the management and the leadership level. Yes, yes. The multiple aspect, one is education is the biggest thing and creating that awareness. It has to be, they have to realize it. Because it's a lot of issues. That means you have to take them through an experience curve. So we do some games and exercises and show it in actual project. Then they realize it. And once that happens, even the leadership level metrics will change. Because then they will look at in a very different way. Hello, yeah. So we've started using gamifications for that matter and I myself feel as a coach, when you go and tell, this is what benefit you get. And we do not tell about a child like talking about, let's do it in a hands-on manner, probably give them a game. Let's play it. And then you know about velocity and iteration. So that's what I thought. Because every time I've heard one thing that at the top leadership level, they have to change. But how I can, as a coach, how I can change their mindset or probably how I can show that these people change if they do not want to change because I'm the way. Because otherwise I'll move to other organization, which I don't want to. I want to change the mindset within the company itself. So that's what one problem I have. Maybe, Krishnan, you can set it up. You're the speaker? No, sorry. You can set up. So we can, if there are questions, I can take it. Yeah. Understand and then proceed. I would say agile scrum XP are a good protocol, but they need to be used with this mindset. Otherwise we'll convert them into another descriptive process. And people look for, tell me what to do, just I'll do that. They won't apply it in a contextual way. So what is that way that we tell them? Because I've tried the approaches like directly telling them and nobody likes to buy it. So if you tell them directly, then it's like you're hurting their feelings. So how else do you tell? See, telling doesn't work. Asking will work. It's a power of question. You know, the whole coaching is about asking, right? So when I tell something, that response belongs to me. It doesn't belong to them. Instead, if I ask a question and they respond, that response belongs to them. That's the power of question. You build ownership in them. I have one last question. You told that 80% are human errors. So what are these other 20% errors? They are typical not knowing the coding, not knowing the domain, not knowing technology. You know, little bit more black and white. Thank you. Thank you very much.