Mohammed Musthafa Soukath Ali

Hi, I am Mohammed Musthafa. I'm an author and agile coach. I lead the agile and DevOps transformation for TCS. Today we are going to talk about it. Today I have my colleagues, Mani and Tabrez, with me. We are TCS.

We are a very successful company. We offer IT services and business solutions for many customers. You can see from the revenue graph of TCS for the last two decades that it delivered outstanding positive increment year on year. We are a large company with half a million employees on its payroll. How is TCS very successful? It always scans the horizon for any change and is prepared to embrace the change.

In 2017, TCS saw agile and DevOps pull from the industry. It knew that it had to be prepared, but there were three specific problems. Number one, TCS had legacy roles, almost 140. Number two, only 10% of projects were agile; the massive portion was non-agile. Number three, its internal processes, though their agility was better than the competition, were not matching its growth aspiration.

TCS further researched agile and found that most organizations in the industry applied agile and DevOps within the IT department, especially for application development projects, not even for maintenance. It knew that the potential for agile and DevOps was not at a project level, but beyond IT and even beyond to the enterprise level.

Manikandan Balasubramanian

Musthafa, hold on. What is enterprise agile, Musthafa?

Mohammed Musthafa Soukath Ali

Our CEO declared that we had to become an enterprise agile company in 2017, and we had the same question, Mani. What it meant was, as a company, whatever we do, not just IT alone, not just IT projects alone, the principles of agile and DevOps must be applied. Their philosophy is so amicable to any work that we do, from marketing to sales, research to production, compliance and whatnot. That is enterprise agile. That's the bar that we set.

Muhammad Tabrez

Considering, Musthafa, we have half a million employees, was it even possible?

Mohammed Musthafa Soukath Ali

It was not a joke. Half a million employees had to be upgraded. We also had to upgrade our infrastructure from a non-collaborative, non-DevOps, non-agile workplace to a very DevOps-facilitating workplace. We had to transform our service delivery projects; remember, only 10% were agile. Doing all of this within three years was definitely a challenge, but we went at it.

The challenge was: we had this vision and these dimensions. How do we move forward? There were two choices. One is the old way of working: phase-gated delivery to vanity measures. The second is the DevOps way of working: eat our own medicine, apply it to the agile initiative and DevOps initiative itself: flow, feedback, continual experiment. We had to take a decision there.

Muhammad Tabrez

What does vanity measures mean here, Musthafa?

Mohammed Musthafa Soukath Ali

Assume we had taken the old way of working. We would have taken all of these dimensions together: workforce, workplace, all of them. We would have done huge data-crunching analysis across the company, huge planning for all of them together, and it would move through phase gates: analysis, planning, design. At every stage we crossed, we would mark that we were 25% complete. But realistically, we would not have created a single value for anybody. Nobody would have consumed our outcome. It would still be in analysis and design. Delivering to this 25% complete, 50% complete is a vanity measure.

We chose the DevOps way of working. We looked at all of it, workforce and workplace, and then looked at the minimal thing we could do so that it could be end to end and create value. We narrowed down to role transformation, because we had to upgrade 140 roles. Within that, we looked at the most threatened role, which was manual testers. We had 7,000 manual testers on our payroll. We knew they would not survive in the digital agile DevOps world. Most of them were in the North America region and in the service unit assurance. So: go to the smallest level, pick up this non-value-adding role, and work on it to upgrade.

The first part is flow, the second part is feedback. Deploy them, upgrade them on the ground, deploy them to projects and see the improvement there. Listen to the feedback. What kind of value are they bringing back? Is customer satisfaction improving? Are they doing better than before? That is the continual experimentation and pivoting. Overall, we were able to do this minimum viable product of upgrading manual testers to quality engineers within four months. We moved them up in their career and made TCS future-fit in terms of roles.

Manikandan Balasubramanian

Musthafa, what are the other MVPs we did?

Mohammed Musthafa Soukath Ali

This first MVP gave a lot of confidence, Mani. Then we knew there were other roles to work on. We took up roles such as project managers and middleware developers, and upgraded them to modern, future-fit roles. Those were our subsequent MVPs.

Muhammad Tabrez

Musthafa, every organization does role transformation, but it does not necessarily mean maturity in agile ways of working.

Manikandan Balasubramanian

Culture change is critical.

Mohammed Musthafa Soukath Ali

This was a huge learning for us too. We thought role upgrade would bring agile behavior. It didn't. For example, quality engineers were expected to collaborate with developers and prevent defects. But they didn't. They were still thinking of themselves as a separate QA team. They were waiting for development to complete, capturing defects, and so on. We knew they had to be jolted; their behavior should be changed.

We brought agile games and DevOps games. We sent them to external certifications, but none of them worked. Finally, we found our own vehicle called Living Agile, where every employee has to take a two-day or three-day real project and work on it to create value. If they did not have agile behavior and DevOps behavior, they would not be able to create value. They would be told about that assessment.

First, we assess them on their current behavior: for example, are they still bringing the old hierarchy-based mentality? Then we allow them to take a two-day or three-day project. In the project, coaches facilitate them to see non-agile and non-DevOps behavior. They retrospect, and they change it. At the end of the three days, most of them understand and imbibe that behavior. If they do not get that behavior, they have to repeat the project.

One example was for the Indian state of West Bengal, where the government asked for a beach safety app. Plenty of people visited the beach, sometimes got into hazards, and had to let the guard know. They wanted a safety app. We let employees develop the mobile safety app through a Living Agile three-day project. On the third day morning, the team rolled it out in front of officials. That is a real project. It is not a game, not just training. It is real-time, and you may fail if your behavior is not changing.

Overall, we had competent roles and agile-trained associates with the actual agile mindset. We were able to move from a 114-legacy-role company to a seven-role company, and we created the world's largest agile workforce. In that process, productivity improved by a noticeable margin. That is what we did with respect to the people part.

Manikandan Balasubramanian

But still, Musthafa, half a million employees cannot sit in the same room. They have to be distributed. Was that a challenge?

Mohammed Musthafa Soukath Ali

TCS by its business model is very distributed. Many of our customers are. When we applied agile and DevOps initially, if you are distributed between India and the US, for example, and you participate in the daily scrum in a different time zone, you have to come in a graveyard shift, in non-office hours. Initially people did it out of interest, but it didn't last. The rubber-band effect came back: "I'm not going to make up; I'll not come in the graveyard shift." We knew location was a constraint.

We had to find an alternative to agile's ask for face-to-face communication. We came up with a model called three-four-five: three models, four enablers, five principles. First, find out which time zone your team is distributed across. If it is one hour, like India and Singapore, you are probably M1 and need some enablers. If you are on opposite sides of geography, six hours plus time-zone difference, you are M3. For example, between APAC and Europe, with a large time-zone difference, you need four enablers. M1 requires two, M3 requires four.

One example of an enabler is the product owner role. If you are in opposite time zones, the other time-zone people may need duplication of the product owner role, so you create a product specialist. You create self-provisioning infrastructure so every member in a project feels like a first-class citizen. They can trigger the build and set up the data by themselves, so it is on cloud and available through self-provision. Overall, we were able to improve the productivity of location-dependent teams to be as good as co-located teams; in some cases it went beyond that.

Manikandan Balasubramanian

Musthafa, digital routine sounds interesting. I understand different digital tools enable this. What investments did you make?

Mohammed Musthafa Soukath Ali

The digital routine is part of the collaboration infrastructure, Mani. To be really location-independent, you should be able to log in from the device of your choice, the place of your choice, and the time zone of your choice. The answer was to give collaborative infrastructure. The branded name TCS had for that was Open Agile Collaborative Workspace, which allows people to enter a digital routine. You have conversational tools between employees. They have the working model set up so they know when to join and can sense one another's whereabouts. The digital routine is set up through the Open Agile Collaborative Workspace.

Muhammad Tabrez

Place of your choice, device of your choice. How is it possible, Musthafa?

Mohammed Musthafa Soukath Ali

A lot of it is IP, Tabrez, so I cannot reveal much, but we gave employees seven options to securely and reliably connect to the workspace from the place of their choice and device of their choice. This came in very handy later.

Overall, we enabled people with skills, roles, methods and tools. Now we had thousands of projects across the company. TCS is a CMMI-compliant company, so we need to maintain the quality baseline. We should know where we are in maturity. We picked 21 high-impact practices. There are around 150-plus agile DevOps practices; we can apply all of them, but to be practical we picked those with high return on investment and put them in three buckets: basic, standard and advanced. Basic means you come together every day, like a daily stand-up. Standard means you iterate and demo value every iteration. We gave the template to project teams so they could assess themselves and move from one stage to the next. For a large organization, this kind of guideline is necessary. You have to make your definitions black and white and get them across. We moved many projects from basic maturity to advanced maturity.

Manikandan Balasubramanian

Initially you said 10% of projects were agile in 2017. How many projects, as a percentage, have you moved into agile now?

Mohammed Musthafa Soukath Ali

In 2017, 1,700, Mani. We are talking about 2019 now; now it is 6,000 projects we have moved. These are not just projects mechanically applying agile practices. They brought a lot of business outcome as well. One example is a capital goods and electronic equipment manufacturer. Their shipment and packaging improved because they brought in DevOps feedback, flow and continual improvement along with other agile practices. A less-than-satisfactory fulfillment rate, 63%, improved almost close to 100% when they applied this. We documented 3,400 business outcomes for many of these projects. We also conduct the LIVA conference, Location Independent Virtual Agile conference, where TCS employees and customers bring back applications of DevOps and agile in multiple situations.

Muhammad Tabrez

You talked about people and process, Musthafa. What about technology?

Mohammed Musthafa Soukath Ali

Technology was already baked in when I talked about the Open Agile Collaborative Workspace and self-provisioning in the location-independent agile model. Self-provisioning requires infrastructure on the cloud. It requires applications to be self-contained in terms of microservices and APIs. That is one part: technical practices and infrastructure. We also gave conversational tools for collaboration.

But we were still stuck with 6,000 projects; thousands of projects were not agile. When we researched them, we found that a company like TCS has mammoth work in operations: doing the same thing repeatedly, application maintenance, business operations, back-office work. A lot of manual hours were spent there. We introduced agile to them and said precious human hours should be spent improving the way you do the work rather than doing the work. Doing the work should be done by the machine. The machine should be given the first right of refusal. Their answer was: "We are very busy. We don't have time."

We helped by providing a dual operating model called Cognitive DevSecOps. Part of the day is spent doing repeated work; if humans are still doing it, okay. But you step back for a portion of time, one hour every day for example, and maximize the value through machines. Think about the projects you can run to improve the technology agility of the work you do. Bring automation.

In a large company, we have to define everything black and white. It cannot be abstract. People have to be told where they are, where they have to go, and they have to be provided tools. We defined a roadmap from basic to standard, advanced and best-in-class. If you are doing operations-type work repeatedly, you may want to start with mere automation: test-case automation, email automation. Then go to purpose-driven automation and end-to-end processing automation. We also gave a tool that scans project information, customer feedback and performance, then suggests the current stage and the one, two, three things to do to reach the next stage. It became a specific exercise.

This was not just mechanics. With Cognitive DevSecOps, we saw a close correlation between maturity and business outcome or types of outcome. If they applied only point automation, they saw team-level outcomes: in-sprint automation, say/do ratio, defect containment and so forth. But those who applied the best-in-class, highest level of Cognitive DevSecOps maturity were able to see organization-wide outcomes: NPS improvement, sales turnover, innovation quotient and so on. That is the technology agility we brought.

Manikandan Balasubramanian

Musthafa, you have done people transformation, largest agile workforce, workplace transformation projects and agile DevSecOps. So your transformation is done, right?

Mohammed Musthafa Soukath Ali

Sir, I wish it was like that. It was massive transformation, Mani. We had IT services done and business solutions done, but still had a huge part of the organization, enablement functions. For example, people building and maintaining facilities for TCS asked: "For software, we can understand MVP, minimum viable product. We are building a facility and maintaining it. What does it mean for us?" Sales people said that dedicated, cross-functional, self-empowered teams were not practical for them because at one point they pursue different leads.

For each of them, you have to figure out what agile is for them. We created the largest collection of agile ways of working for each of them, with documented FAQ. We call that framework Agile for Everything. Agile for Everything converted TCS into an agile company overall. The value stream from research to retirement of assets and sunsetting all became agile.

Muhammad Tabrez

Musthafa, hold on. You yourself mentioned that it is a complex slide. Can you explain one of them?

Mohammed Musthafa Soukath Ali

I will take the first one, Tabrez: sense/validate/research. TCS research and innovation, before the transformation, would take many months or years to file a patent. By applying agile, they reduced it to 10 months in 2019. As we speak, I know of many efforts where we applied for patents within four months. Similarly, in the way we hire from college, we increased our reach and improved the cycle time of onboarding an employee.

Overall, Agile for Everything brought internal agility. For example, an associate hired from college will be trained while still in college. We shifted their training back into the college, which means when they join TCS, they are job-ready. On the day they join, they have the laptop ready. On the day they join, the project is mapped. The flow happens ever since they are onboarded into TCS. This internal agility allowed TCS to transition to working from home within a few weeks: half a million employees, their customers, all the work, including mission-critical work, because of internal agility.

Muhammad Tabrez

I now understand the seven options you mentioned earlier: place of choice and device of choice.

Manikandan Balasubramanian

Musthafa, Agile for Everything is interesting, and the internal agility you achieved. Did you take agile beyond the company?

Mohammed Musthafa Soukath Ali

It is dangerous to say Agile for Everything, but we did. Many of us apply agile for our personal things, families and whatnot. We show a case where TCS associates adopted an eatery, a restaurant in Noida, Delhi, which had potential but not a great customer base or sales. The TCS team helped them follow an agile way of working to improve the status quo. They conducted a daily scrum, set up listening posts for customers, acted on feedback, and improved the flow of value to the customer. Within a few weeks, sales improved by 25%. That is one case. We have done many such works for social work. Agile for Everything was applied to many things outside the company too.

Muhammad Tabrez

How did you do the change management, Musthafa? Any specific framework?

Mohammed Musthafa Soukath Ali

It was a problem. TCS is a company within a company: complex, diverse. We tried many things like the John Kotter model, but we had to figure out our own way. We call it the neighborhood model.

Traditionally, you form a transformation team at the top, with levels beneath that. You pass information and change direction to them; they deploy. Somehow that sounds very hierarchical, against the self-empowerment principle we teach. We went with a network model in which neighborhoods are embedded. In each TCS unit, we formed a self-contained transformation team. They were connected as nodes to action centers called neighborhoods. Each neighborhood is an expert center for a specific vertical. The whole information flow, knowledge flow and deployment flow got decentralized. At any point in time, there are 14 neighborhoods. They disseminate requirements and guidance, and the democratization of flow allowed us to scale a lot better.

Manikandan Balasubramanian

Musthafa, 14 neighborhoods. Can you throw some light on it?

Mohammed Musthafa Soukath Ali

Each neighborhood is staffed by people who are on the ground working for customers, but they are experts. DevSecOps is one neighborhood. Top-notch talent in the field is part of the DevSecOps neighborhood of TCS. I might be a junior in TCS working in a project, and I know the maturity I have to go through from basic to best-in-class. I have a question, I want help, and I can straightaway touch base with these people. There is no central mechanism; it is more distributed. As a junior, I get access to top-notch talent immediately. Similarly, the other 13 neighborhoods democratize information and knowledge in TCS, making this a scaling-out model.

Muhammad Tabrez

Musthafa, having half a million employees, how do you measure overall progress?

Mohammed Musthafa Soukath Ali

It was an ask, Tabrez. What do you mean by where are you? We have to answer the board, analysts and TCS chief officers. We need to know where we are. After multiple iterations, we found a measurement called agility debt. It indicates the burden a company carries in terms of agility. The heavier the burden, the poorer your agility debt. It is similar to blood pressure: you know what is ideal and where you have to go. Here, the ideal measurement is zero. You should not carry any burden at all. If you carry a non-agile workforce, it is a burden.

We calculate this number at project level, looking at people, process, infrastructure and technical agility. Together, we get a single number. It can be aggregated all the way to entire TCS. As we speak, TCS has 0.24 agility debt, and it can be decomposed into business units all the way down to projects. At any point in time, anybody can have an easy conversation about where they are in terms of agility. This is not a measurement to scare people or force compliance, but at least it makes the real situation on the ground transparent so you can act on it.

Manikandan Balasubramanian

Musthafa, 0.24 agility debt. What does it mean in layman's terms?

Mohammed Musthafa Soukath Ali

Very simple, Mani: 1 minus 0.24 is 0.76. Seventy-six percent of the work we do in TCS is agile. Less is better. If agility debt is zero, then 100% of the work we do is agile.

We also compared agility debt with the growth of our customers. Those who enjoyed better agility debt, close to zero, 0.1, 0.2 and so forth, had better growth for the most part. Those at the lower end of the spectrum were not growing better. Many were traditional companies too; because of some legacy reasons they survived, but otherwise they had problems.

We also looked at feedback from inside. We collect the customer satisfaction index on projects. Year on year for four years, customer satisfaction on agile projects was always one notch above non-agile counterparts. That reinforced our belief that agile and DevOps practices really work for business agility and customer satisfaction.

Muhammad Tabrez

It makes sense, Musthafa. I understand the overall transformation. You got the one-liner from the CEO, then used the DevOps way of working for the entire transformation, and I hope you are getting some good recognitions.

Mohammed Musthafa Soukath Ali

Absolutely. We got a lot of recognition. We were placed in leadership quadrants by many analysts. We got a few patents; some of them are direct grants. We also won many awards.

The summary of the story is: in 2017 we had a lot of legacy loads. By the end, we had multiple thousands of agile teams with seven lean agile DevOps roles. We had a legacy portfolio of only 10% agile projects; that grew fourfold. Revenue has improved four times now. We already mentioned that 76% of the work we do is agile. Internal processes also improved the overall business objective.

But the journey is not going to stop. We are not done with our work. As we speak, we are doing a huge operating model change at the TCS level. Perhaps in another session we can explain that: how to move from the current geography- and vertical-based structure to a customer-curated journey of incubation, growth and transform. The point is that TCS is very committed to agile and DevOps. We have tasted it. Our customers have tasted it. We will continue to refine it.

Now it takes us to the help we need. Whatever we have done so far is great work, and we are proud of it and want to share it. If you are in a similar stage and want help, we can share this knowledge. Second, we are trying to specialize in areas where solutions are not completely there yet. For example, how do you measure business value? How do you write an agile contract? These are areas we are researching. If somebody is doing great work here and is in an advanced stage, we would like to learn from them. Thank you so much. Thanks, Mani and Tabrez, for accompanying this talk.

Manikandan Balasubramanian

Thank you all.

Muhammad Tabrez

Thank you.

Mohammed Musthafa Soukath Ali

Thank you, everyone. Thank you.