Sekhar: Madhur, I see you have a good background in Process Consulting. Has this background been useful in helping organizations to move towards Agility?
Madhur: Since 2004, when I started in Process Consulting, I was part of what is called Software Engineering Process Groups (SEPG) of various organizations. The SEPG as a team are focused on improving process quality across the organization.
Even though the Agile Manifesto says to focus on people first and the process next, a-lot of agile methods also focus on how to improve processes. In that sense, If someone has a background in Process Change Management, it definitely helps to move towards agile software development, but let me reiterate, it does not address the behavior changes quintessential to a greater agile adoption.
For example, take Scrum, it is a method or a framework with a series of steps; and teaching people to execute these steps is easy, though Agility is much beyond process management. During my initial days, we took a couple of our clients to CMMI level 5 organizations. CMMI as a framework had been grossly misunderstood by many: people think that CMMI means we need to have hard evidence, a bunch of word documents, etc., but if you go into the depth of CMMI, it never says anything like that. It talks about certain generic and specific practices and it asks about evidences either hard or soft. It never said that we need to write a project plan in a word document. So that way, we use Agile Practices to make CMMI level 4 and 5 organizations, kind of marrying both in terms of delivery flexibility and to find a way to measure the best practices. So, to answer your question , a process champion does make up a good coach and a Scrum Master to start with…
Sekhar: Do you ever think these processes are overhead in organizations? Sometimes you have too much process in established organizations and in startups you don’t have processes at all. So did you really find that balance?
Madhur: I would really go with the very first Agile Manifesto, People matter more over processes, with more importance given to the items on the left. Agility never means you throw the process out. Some process at least in my opinion is required. Even in our personal life we still have some process. It is a simple basic nature of humans to have basic process and over and above that we can apply the Agile Manifesto.
Sekhar: How many clients have you coached to date?
Madhur: Close to 75 clients.
Sekhar: Are they only Indian clients or international?
Madhur: I have clients in US, Europe, South East Asia, Malaysia and Thailand. I have worked with close to 300 teams to date.
India is a high Power Distance Index (PDI) society...On the other end of
spectrum, there are countries like Sweden, Netherlands and the United
States...
Sekhar: What are your typical challenges related to cultural aspects?
Madhur: This has been a topic of debate and research over the years on how culture reflects agility and there has been a-lot of text written on it. To me, culture has two aspects: Society Culture and Company Culture.
Society Culture is the way people adopt the Agile Manifesto. An example is India: India is a high Power Distance Index (PDI) society, meaning that whatever is going to happen, there will be some kind of deference to authority. A further extreme is Japan, where they are ultra-high on PDI, meaning that authority is almost worshiped. On the other end of spectrum, there are countries like Sweden, Netherlands and the United States, where you have an authority through your knowledge and not just by designation. Methods like Scrum, SAFe, and DSDM talk about people first and their collaboration and interaction with others. So, in a way , the PDI does effect how associates in a particular country adopt these methods and frameworks.
The same principle applies to an organization as well. The organization can be anywhere in the world – some organizations have a very hierarchical culture and some organizations have a very open flat culture. I am not only talking about the Googles or Amazons of the world, I’m talking about very normal organizations. Some organizations are very open to thought process, they would empower their developers to forget about being Agile or non-Agile, you are free to do any innovative activity or research as long as it for the benefit of the company. For those organizations, it is very easy to adopt Agile. On the other side, I was training a portals company in India, and they are too Agile: they are making several releases a day, they want to use Agile methods like Scrum to control this phase which is not sustainable. It really depends on the culture of the country and organization on how Agile practices are perceived.
Sekhar: One point you raised is autonomy, whereby people get an opportunity to try out different things and they can innovate as long as it serves the interest of the company. So do you think autonomy happens in some cultures and it doesn’t in some other cultures?
Madhur: To an extent it is there in all cultures. In certain cultures and geographies it is relatively easier, purely because people are fine tuned to that way of working that they have to try something different every time rather than being routine. A simple example is, Why do we not have the Apple’s of the world in India?
It is changing now and the startup culture is slowly emerging and things have started improving. Even the education culture needs to change for that matter: people want to get into a top 10 engineering colleges after 12th grade and no one wants to become an entrepreneur. Everyone thinks that they want a secure job and no one wants to take risk. For a country like India, we are a low risk society; we don’t want to take too many risks.
Sekhar: Tell about the competition mindset, that most people in India have. We want to compete with other individuals even within an organization. That really comes from our school age – we value competition more than teamwork. Even within a team, everyone wants to be an individual hero rather than a team player. Have you faced any similar situations in your coaching career?
Madhur: Yes, with a-lot of organizations that has been the case. Only for the simple reason that people want to show the world that they are the best of the world, because they want to get a better pay scale, better promotions, more recognition and so on and that mindset prompts the competition. Since we are in a corporate environment, many people do not admit this upfront. But when you are coaching the team or mentoring Scrum Masters and when you are listening to the symptoms of it, then we realize that the root cause of the problem is not about process implementation, but about people wanting to compete and show the world that they are better than others. It is not only between individuals, I have seen it also exist between different role teams. For example, Product Management has wanted to show that it is the best team and the engineering team is not up to the mark. They always want to showcase themselves as the best protectors of the company’s interest. That depends on what kind of culture the management cascades downwards. Competition may be good in terms of organization growth, so that people can still grow. But growing versus others and growing yourself are two paradigms.
Sekhar: A controversial topic, performance appraisals: many people say that performance appraisal kills Agility in an organization because people are in direct competition with each other. We teach Agile values, principles and the importance of teamwork, but if we don’t change our performance appraisal process, it undoes our efforts for Agility. So do you have any lessons learned from this kind of practice being adopted in organizations?
Madhur: Yes, I have been recommending a few ways of doing performance appraisals. For example at one of the large digital media organization, a couple of years back, they naturalized the impact of performance appraisals done annually. Instead, they have one-on-ones at end of every month with every individual, giving a-lot of informal and regular feedback, preferably face-to-face or over Skype. The Managers give feedback to the individuals and also seek feedback on what more support they can provide to the individuals, also what more support the team can provide to the individual.
I always recommend that business goals get transformed into product goals and they transform into team goals. So I would say about 60% of the performance appraisal is about whether the team goals are achieved or not. The Product Owner will decide if the team has achieved the team goals or not and generate the business value required. Managers may also join this exercise on mutually agreeable parameters. Another 20% is about what your Scrum team thinks about you, including the Scrum Master and Product Owner. The remaining 20% is your self-growth, which may include how many conferences you attended, how many papers you published, how many certifications you achieved, how many new innovations you made. People who only do delivery may not score well in this area.
If an organization is able to adopt this model of performance appraisal, you are able to satisfy most of your key Agile values and principles related teamwork, collaboration, trust, accountability, sense of urgency and a goal driven approach etc. Of course, the law of averages will play vital role in creating the differentiators.
Sekhar: Another challenge in an agile transformation is middle management participation – whether they are supportive of the Agile Adoption. The moment an organization decides to go agile, middle management can become scared of reorganization or losing their jobs. Have you faced any such situations in your coaching career and if so, what strategies did you use?
Madhur: I will give you two different kinds of examples.
One concept which I promote, that seems to be flowing against the tide: In every change management situation, people are always apprehensive about “What is in it for me? Am I going to improve in stature? Will my pay change? Am I going to lose my job?” It works similarly all across the organizations; we even have a-lot of similar debates in offshoring. If we are able to provide the right value to the various roles and various stakeholders in the system, the behavior change is obvious. Most say, “you change the behavior; you will be successful with Agility” I say no: You cannot change the behavior unless you show value to each and every person who is affected by that change. For example; your business executives, marketing guys, and sales guys don’t care about what process you are following, what change you are talking about, ultimately they care about the numbers. Is my organization improving? Do I get better numbers because of the change you are bringing? Whereas, developers don’t care too much about the numbers and behaviors – they think about how this change is going to improve their daily work life. Is it going to help them generate fewer bugs? Can they go home early today and spend time with their family?
The middle management are more concerned about the processes. If the process is right the team will be able to take it forward and the manager’s life will be easier. They are very concerned about setting the right process and making sure that everyone follows that process, so that they don’t get caught in a mess.
If you are able to help managers to develop good processes so that the managers are happy, provide the right metrics or data so that it showcases to management on how they are improving, give the right training so that developers are happy so that they can perform their daily job well, then the behaviors will automatically change.
I call this model “Value Driven Behavior Management”.
Sekhar: You are saying managers are acting in their self-interest; they are not acting in the organization’s interest?
Madhur: They would be acting in their self-interest only; see at the end of the day, traditionally at least, managers are the first point of push, if anything wrong happens, catch the neck of the Manager, because he did not do it correctly. Since Managers want to have a good night’s sleep, they want to set up the process in the right way, so that they don’t have to train, teach and groom people continuously. Train the developers the process and let them perform. Most managers think if they give the right process, everything will go fine and smooth. Suddenly, when Agile comes into picture and takes the power away from the manager, they start feeling jittery. Now managers cannot decide the process in Agile – the team decides it. Now managers do not know what is in the future. Whether the team will perform or not, the manager does not know.
In one of the large telecom client five years back, we said we will change designations, and we will not fire anyone. Everyone has a role to play. All the managers in that organization were actually trained and groomed as team coaches and the designation changed to team coach/team mentor. That really flipped the mindset, since we are not throwing out anyone.
Sekhar: Another symptom, which I have seen during Agile Transformations, is when you have Agile frameworks like Scrum, XP or whatever and you have the existing organization structure. Most of the time, it is difficult for the organizations to tweak the organization structure, due to various reasons such as high resistance, so management tries to tweak the respective agile framework they are adopting, so that it fits into the organization structure. It could be for example, assigning managers the role of Scrum Master or introducing command and control into Scrum teams. There are so many ways management can force fit agile into existing structures and hierarchy. Do you think that works or reorg might always be required before an organization adopts Agile?
Madhur: Reorganization? I don’t think so. In close to 75 of the organizations that I have worked with, we never initiated reorgs in any. Reorgs happened as per the natural process rather than a forced one. The reason was very simple; let us take Scrum as a framework; it says it has three roles, Scrum Master, PO and development team. It never says there are three designations, that means if anybody has the right skill and mindset they can take those roles, weather he/she is a developer, test engineer or a manager or a director. We recommend changing the manager’s designations in the right way so that it doesn’t affect the team’s progress. We never have said that managers are redundant, just changing manager behavior so that they in turn in insert the attributes of self-organization and self-management into the team. This is a very crucial step. Even from a middle manager’s perspective there are several things a team might not be able to do on their own. We have to identify line managers and technical mentors during the agile transformation process.
Management think that because the Scrum Master role is closer to a
manager’s role, they should either make a manager as a Scrum Master or
make a Tech Lead a Scrum Master. This creates lot of administrative
Scrum Masters.
Sekhar: So what do you say about hierarchy? There are reporting structures in place and let us say for example you don’t have sufficient Scrum Masters in your organization and you have to designate someone as a Scrum Master, then that person is ill equipped as a Scrum Master and is someone who is being controlled by a Manager.
Madhur: This is where the mistakes in an organization start happening: the management think that because the Scrum Master role is closer to a manager’s role, they should either make a manager as a Scrum Master or make a Tech Lead a Scrum Master. This creates lot of administrative Scrum Masters. They administer the ceremonies and the rest they don’t care about. The rest could be the behavioral changes, body languages, impediments to be removed and so on. They just think in terms of process to follow.
Sekhar: Do you see any cultural challenges in setting up these hierarchies in an organization?
Madhur: Yes. Companies see promotion as a method of rewarding performance, so when someone performs well, the management elevates them to a manager, director etc. Now they are rewarding individuals even with a Scrum Master role. But I see that there are other ways of rewarding individuals without hierarchy. I suggest considering the person’s people mindset, before rewarding a new role or designation to them, rather than simply deciding on years of experience.
Sekhar: One of the things that I have seen in the Indian culture is that there are some developers and testers who want to show something extra to their management, apart from doing development, and so they seek to play the role of Scrum Master so that they might get some extra points in their performance appraisal. Have you seen that happen in your coaching career?
Madhur: That happens a-lot of times, that is why we always recommend to clients – and we have successfully implemented this – that Scrum Masters do not come from the development team that they lead: either they should come from the SEPG group or simply be outsourced. They should understand the domain and everything, they understand what the team is talking about, but they are not part of the development. Then we can avoid the incentive to “showing something extra”.
Sekhar: So what do you think about a situation in which Scrum Masters are being controlled by managers?
Madhur: It happens if it is just a nomenclature change or name change. In waterfall they were called Tech Leads, in agile they must be called as Scrum Master. The true essence of what a Scrum Master should be doing gets lost. Lots of people asks me, “Can we have all of our development team certified as CSM?” I asked “Why do you want to do that?” It might look good on their resume, but for Agile to work you don’t need 200 CSM’s in the team. Just five are enough and others need basic Agile training to get started. The mindset has to change. To some extent, if I stick my neck out, a-lot of us coaches are also responsible for bringing such a culture. As coach, we should be really careful of promoting the right things which may form a new organization culture.
Sekhar: What do you think of other cultural aspects, that don’t fit into Agile such as people’s lack of discipline, managers who use micromanagement, etc. – are these cultural issues that are predominant here in India?
Madhur: Not really, they are everywhere, I have seen people who abused the whole concept of working in Agile: In once case they said they had been using Agile for the past five years, but when I went in and saw the culture, the team came in at 11am or 11.30am, even though the daily scrum started at 11.30am,and people would be sitting out and playing games. The Scrum Master had to literally pull people out for the daily scrum. They finished the daily standup and at 12.30pm they went to lunch. They come back at 2.30pm to work for couple of hours and at 4.30pm they left for the day. They said they were Agile and the manager was not allowed say anything to the team to change this behavior – it was “self organized”.
Culture can play role to a certain extent; but it is also important to set the right expectations. The discipline part that I talked about is very essential.
Sekhar: So what I understand is, we still need managers in an Agile team – they should not abandon the team completely.
Madhur: Absolutely, it also depends on the maturity of the organization. A team that is very mature should be able to work without a manager. I have seen a-lot of teams, at least in Asia, of the mindset that “We need someone taking care of us and lots of time spoon feed us”. Some developers think that “I’m like a robot and the commands you are going to give me, I just follow them. The moment I get alone and nobody is looking at me, I go in a tangential direction.” This could manifest as chatting in the office, not attending meetings, skipping ten test cases – we will only 5 for now – it depends on the individual. To get to the maturity of self-working, it takes a-lot of time. When Agile training has been done, management often thinks we can get started without checking if there is someone to mentor the team members in the right direction.
Sekhar: What do you think are the root causes of these immature behaviors that exist in people of an organization?
Madhur: In one line, I can state it as “People want to work for Agile, rather than they want Agile to work for them”. I have organizations saying Agile is our business goal, whereas Agile is a philosophy or set of practices that were originally designed as an enabler to reach your business goal. So Agile is not the end goal, it is an enabler, it is just a means to reach the goal. So we should not say, we want to be agile in the next three months.
Sekhar: We talked about a-lot of challenges and constraints, but if you are asked to coach one of those complex organizations, what do you think are the typical characteristics of a coach who can deal with these kinds of challenges?
Madhur: When I interview coaches, and when I coach the coaches, I need to see that they are not just thinking about doing the process. Someone should be really able to see beyond the curtain of a team, individual and the management. Another thing, I have seen coaches at both ends of the spectrum, some coaches who are very strong, “if you don’t do this, I’m not going to coach you? This is the only way to do this?” The other set of coaches are very soft, they just leave it alone after telling the team once or twice.
I always tell the coaches who work with me, “You need to be politically correct to make the change”. Sometimes, the group force approach may not work. I’ll bring the same as a part of value driven behaviors. As coach you need to understand why someone displays a specific behavior, and you need to work according to that. As coach you have to be sometimes the data scientist, getting data from various teams, inferring various results from the data and showing the management that this is what we want to do, and this is what we have been doing or improved. Sometimes as coach you have to be process champion, writing templates and tailor them to the organization’s need. Sometimes as a coach you might need to play the tools and techniques guy role, like helping people to use Jira, Rally, VersionOne, TDD, etc. Sometime you pure play a psychologist role. You may play the role of a mentor for individuals and they may share some of their personal stuff also. It is not necessary that everybody will have all these qualities within them and they have to do coaching, someone who wants to coach has to define themselves, “I’m great at processes, I can tell you exactly how I can do process work.” “I’m good at tools” “I’m a good data guy”, “I’m a behavior guy, don’t talk to me about process, I can help you on what can be done in this situation”.
Executive management have less time available in their day-to-day busy
life... they
will only pick up those things that can make significant and measured
change.
Sekhar: The coaching role has an important element of coaching executive management. For these managers you often have to make a case for your ideas. How do you think a coach should deal with executive level managers?
Madhur: Simple, by using value driven behaviors. Executive management have less time available in their day-to-day busy life; they have to take care of many things in an organization, they will only pick up those things that can make significant and measured change. Unless you are able to measure it, it doesn’t matter for them. You might do great Scrum and all, but unless it is reflecting in lesser time to market, better quality, better customer satisfaction, that directly tags to their KPI’s or their goals, they don’t care. So as a coach you should be able to bring that picture to the executive management. You need to be friends at all the levels, the same way that you should have skill in presenting it in a different way to the developers, you must use a different way for executives. You need to be friends, ears and eyes of each one those people along the hierarchical chain, if you want to be an enterprise coach.
Madhur Kathuria's bio can be found on his LinkedIn page.
No comments:
Post a Comment