Implementing Agile in Big Corporations - Proven Tips from Salesforce (Interview with Mayakrishnan Chakkarapani, Senior Director of Software Engineering at Salesforce)

In 2024, is Agile software development still relevant?

How about in large corporations like Salesforce?

If you ever got discouraged from implementing Agile or you’re in the process of fine-tuning your way of using it, stay tuned.

Mayakrishnan Chakkarapani, Senior Director of Software Engineering at Salesforce, shares interesting insights on how his organization uses Agile to meet business goals and empower developers while doing so. 

This blog post summarizes some of the topics discussed in episode 87 of the Level-up Engineering podcast hosted by Karolina Toth. Check out the full interview on Apple Podcasts, Google Podcasts, Spotify or YouTube. 

This post covers: 

• Agile in Salesforce
• Some benefits of implementing Agile 
• Constant evolution 
• What to keep in mind when implementing Agile
• Culture first
• How to empower developers when following Agile
• 3D Agile
• Keeping it balanced
• Setting up and managing virtual teams
• Managing virtual teams
• Bonus advice
• View your organization as a doctor
• Be agile in thinking 
• About Mayakrishnan (MC)

What’s the state of Agile software development in Salesforce?

When I joined seven years ago, my organization had already been using Agile, but perhaps not all orgs within Salesforce had adapted to this methodology back then. We started with SCRUM, but that doesn’t make a team agile by default. 

In my teams, we started with 4-6 weeks of planning time and then we delivered outcomes. Of course, given the nature of Salesforce as a product, we kept the deadlines flexible to accommodate our customers - some of them built long processes around Salesforce, so they needed more time to observe and test changes. 

In order to keep up with customer expectations without compromising our internal agility, we adapted a hybrid way of thinking about Agile. We have three major releases in a year, but on an organizational level, we still strive to deliver value incrementally every 2-6 weeks. 

What are some of the benefits of implementing Agile?

Constant evolution

Agile is a very pragmatic approach that keeps both your team and your customers focused on constant evolution and enables your developers to react to changes quickly. 

For example, when we do a release planning, we plan for all the things that the customer asks for as of that moment. Realistically speaking, something is probably going to come up in the meantime: priorities can shift or perhaps someone spots a security issue which needs to be addressed quickly. There’s always going to be a spin in the release cadence, either on a sprint or a release level. 

Agile enables teams to respond to these sudden changes fast. It’s especially important in an organization like ours, since we have many stakeholders and customers, so we continually receive new inputs. There’s a continuous feedback loop coming from various parties, so we have to be able to react and adapt to changes fast. 

What should organizations keep in mind when implementing Agile?

Culture first

Agile is just a tool to react to changes quickly, but it’s the culture that enables you to have this mindset. I’ve seen multiple businesses that became Agile so that they would have predictable, repeatable outcomes - however, without the right culture in place, implementing a methodology won’t solve any challenges. 

Every organization has to figure out what their own Agile looks like and how they’re going to get everyone on the same page and actually remain aligned. When we started implementing Agile, every team began working in 2-week sprints, and we quickly realized that it’s not going to benefit us. Salesforce already had a fantastic engineering culture at that point, so focusing on speedy delivery meant losing some of this culture. Luckily, we were able to spot this issue quickly and started fixing it: we agreed that we cannot compromise on the product vision and architectural soundness for the sake of Agile, and instead, we tailored the methodology to fit our purposes. 

How can you empower your developers when following the Agile methodology?

We strongly value high-performance teams in the organization. In theory, the best-performing people are the ones from self-empowered teams, but it’s hard to know how to actually get to that point. 

You may have a team where there are some top performers who can build a lot of things independently, some rockstar engineers who just need a few clarifying questions to deliver things perfectly, and then you may have some people who need more guidance because they are, for example, still figuring out the culture of your team. 

The big question is, how do you tell this whole spectrum of different engineers to become a self-empowered team and do whatever they want without creating chaos? You need to approach this from a pragmatic point of view and introduce a 3D Agile method here.

3D Agile

3D Agile entails data-driven development. This means you take all sorts of information into account when making decisions - input from customers and other stakeholders and your engineering team as well. 

When you plan the next quarter as a manager, relying on all these data points can be crucial. Let’s say you learn that one of your top performer engineers is having some personal issues, so he wants to step back a bit, and only focus on the tasks allocated to him without taking on extra responsibilities at work. I think that request is totally okay, especially if it helps engineers avoid burnout. 

Now it’s up to you to empower your team knowing this information while keeping the self-governing aspect of the team dynamics - and without revealing someone else’s personal information to others. 

In our case, managers play a product owner role as well. This way, they have a much more holistic view of what needs to be done: they know the priorities product-wise as well as each team members’ strengths, so they know who can best take each story. There may be stories that are always assigned to high performers because they’re complicated, but they can also be given to rockstar engineers who want to take the opportunity to improve. 

This combination of empowering but also focusing on different data points is a great way of software development. We also empower engineers to rotate periodically. If an engineer has built enough expertise in a particular area, we give them new areas to discover. This way, we can continually improve and challenge them, and it also prevents boredom, burnout and turnover. 

Keeping it balanced

The model described above is similar to an equal triangle. You have to balance the stakeholders’ needs from a product and leadership perspective, making sure that their specific visions align. You also have your partners who need to come together and help deliver the desired outcomes. And last but not least, you have your engineering teams who actually deliver it. 

The biggest challenge is setting the right priorities. What one organization deems as most important might not be the case for other teams. Engineering may say that the highest priority is to get the new product out for the customers, and they align well with the sales and marketing teams on this front. However, the security team may think it’s too risky and more guardrails need to be discussed before the release. 

Even though we are aligned, different departments may have different priorities within the organization. In these situations, the right tools can help tremendously. In Salesforce, we use the V2MOM alignment process to assess our goals. You take the information you get from different departments, you bubble it up in your V2MOM system, and you bring it to each department and ask for their input. Do they have the resources to deliver what is needed?

This is a crucial aspect to address, because many times, engineers face a resourcing problem or some sort of technological hurdle, or a combination of these two. If there’s a resourcing problem, we may form a virtual team whose main focus is to mitigate the biggest security risks, for example. 

How do you set up and manage virtual teams?

There are some projects where virtual teams form organically and are very successful. For example, in my organization, a lot of Salesforce products have a charter to move to public cloud. Some of these products are very complicated and have different architectural patterns that evolve over the years, which means moving them all to a public cloud is not an easy thing to do. 

In this case, a virtual team of product engineers and platform engineers can form organically . Maybe they’ll also include some folks from security as well to weigh in on the new architectural changes. This is how virtual teams quickly form, solve an important problem and then go back and proceed with their day-to-day activities. The lifespan of these teams can range anywhere from a few weeks to more than a year. 

Managing virtual teams

Empowerment and ownership are really important concepts in virtual teams. There’s always a caveat - some engineers will inevitably feel like outsiders compared to other team members. On top of that, participants may be distributed in many different time zones, so coming together might be even more complex. 

Within our organization, ownership helped organize virtual team members’ work. We give the strategic pieces of the project to different teams, and they focus their full attention on that particular area. For example, one of the teams can be responsible for all the design work: the POC, the viability of the product, and then the product governance as well. This will minimize the need for communication between people in different time zones. 

Bonus advice

View your organization as a doctor

View your organization as a doctor and your customers as patients; getting your customers’ desired business outcomes means you treated a patient. If one of your patients needs surgery, you need to focus on ensuring they recover as quickly as possible. Agile is nothing but an operational procedure ensuring you’re doing the operation methodically and iteratively.  It means you’re running a diagnosis first, then you come up with various techniques, and finally, you perform the operation the best way possible.  

But just because you have a thorough pre-surgery process, it doesn’t mean you can neglect postoperative care. You still have to monitor the patient, and if something seems off, you have to do the process all over again. 

A lot of times, I’ve seen people taking Agile for granted, thinking it’ll solve everything on its own without thinking about the culture or empowering their teams. It leads them to just force people to do more, causing lots of engineers to burn out eventually. What happens with these dysfunctional organizations is that the operation may succeed because they followed Agile, but the patient still died. 

That’s why you need to be pragmatic when introducing Agile methodologies in your organization and modify them based on your culture. Listen to your engineers’ input, make sure there’s enough ownership for them, and stay in the feedback loop continuously. That’s how your patient is going to do well.

Be agile in thinking

What works this year may not work in the next. Be agile in your thinking, and make it a part of your process to continuously collect feedback and iterate based on it. Agile focuses on software engineering; building an agile organization itself is the leader’s task. Our engineering officer was able to do that in a year - it’s hard work, but it enabled us to take our performance to the next level. We were able to learn what is needed from our partners and customers, because we created an environment where everyone could come and give feedback to improve processes. This feedback loop will enable you to continually iterate and change your mindset and keep trying. This way, you’ll definitely get the outcomes you desire and heal all your patients. 

About Mayakrishnan (MC)

Mayakrishnan’s excitement towards building new things is one of the reasons he started pursuing software engineering. He’s been in this field for more than 20 years now and has worked in companies such as BlackArrow, Intuit, and for the past 7 years, Salesforce. He’s an expert in building, developing and transforming teams with Agile methodologies that are tailored to their needs. 

You can follow MC’s work by adding him on LinkedIn.