Digital Transformation in the Midst of the Pandemic: Ibm ISC CRM Development Team Remote Delivery Practices

Author | Jayesh Kadam, Dr. Ashay Saxena

Translated by | Wang Qiang

Planning | Ding Xiaoyun

It was July 20. With the first wave of the pandemic peaking, the 100% work-from-home model (WFH) has been in place for three months.

We are the CRM platform team for IBM's Chief Information Officer (CIO) and have just successfully completed a project to move the global sales team from an in-house CRM system to a SugarCRM managed cloud platform. Another initiative of the project is the adoption of streamlined product tiers across all sales applications.

Just as we were experiencing the new normal of working remotely, the company decided to adopt Salesforce's SalesCloud as a single CRM system for IBM's global sales team and partners.

The core objectives are outlined below:

All IBM sales and business partners move to a single IBM sales platform (CRM). Salesforce SalesCloud will be IBM's unified CRM/sales platform with best-in-class integration, analytics, and cognitive features.

The more than 170 tools and systems previously used by the company in the Go-to-Market (GTM)/Sales Cycle process will go down in history, and the entire sales lifecycle of the sales team will be completed on the new platform.

The new platform will be operational within a year, with July 21 as the deadline.

This article tells the story of how the IBM CIO CRM development team, through two rounds of Covid-19, worked entirely remotely to deliver a project called IBM Sales Cloud (ISC) in less than a year.

Background

My agile journey officially began in 2011. At the time, I was working at Wipro, consulting for the leaders of several client organizations. In the process, I looked at how they were working at the project and enterprise level at the time, and then came up with a roadmap of how all aspects of their project needed to change to achieve agile working.

In my consulting and coaching process, a key challenge was to ensure that the roadmap covered all aspects of agile values and principles, rather than rushing to introduce some practices and calling them agile.

Source (https://dilbert.com/strip/2017-02-06)

According to McKinsey, "a comprehensive transformation involves every level of the organization, including people, processes, strategy, structure, and technology." （https://www.mckinsey.com/business-functions/people-and-organizational-performance/our-insights/the-journey-to-an-agile-organization）

Figure 1: McKinsey article on various aspects of the transition period that need attention

When I was a technical project manager for CRM feature development, I defined a transformation-based lever-based framework based on my own consulting and coaching experience that focused on all aspects of the project.

Project management framework

When we launched ISC Delivery, we used the topic of enterprise agility as a lever for project management to ensure that delivery touched all levels.

Figure 2: Project management framework based on transformational leverage

Let's take a look at the key principles behind these levers. We will then study each lever in detail.

Set up teams: The key principle of team setups is that they must be cross-functional, not component-based. The second is to try to establish a function-independent workflow.

Process: A key challenge for many large projects is that they are designed as large waterfall release processes, even though they claim to be agile. We consciously want to avoid this. So our process is designed based on iterative and incremental development. This requires vertical slicing of feature development efforts as much as possible and moving deliverable increments to a higher environment multiple times in iterations. We need to instill the idea of testing first to achieve this.

Architecture: The idea was to make an initial version within the first 90 days and then gradually adjust it based on changing needs and business feedback. Stakeholders recommended the concept of an Architecture Review Committee (ARB), which is very effective for projects of this scale.

Engineering and tools: We built the development, staging, and production environments in the first 30 days; we built the GitHub repository, Salesforce scratch org as the development environment. We need to move deliverable increments to a higher environment, which also means we need a robust pipeline of build, deployment, and testing.

Assessment and governance: A key aspect of the project is the diversity of stakeholders. Senior executives from sales, operations, the Global Chief Data Office (GCDO) and the CIO team are all involved. In addition, each business unit (BU) is also involved, as the salespeople and sales managers of each business unit are end users of the ISC platform. We strive to maintain a governance structure that is as lean as possible. Agile application lifecycle management tools are a single source of truth about project progress and a dependency management tool across teams.

Culture: In the end, none of these levers will work unless our team has the right culture. We stress once again that project objectives can only be achieved if we truly work together as a team. We started with a lot of unknowns, so we encouraged the team to experiment and learn instead of waiting for everything to gradually become perfect. Working remotely and changing scopes of work puts a lot of pressure on the team. As leaders, we acknowledge this and assure the team that we are always on hand to participate and provide support.

Now let's analyze each lever more specifically.

Team settings

As I mentioned earlier, the key principle of setting up around teams is "independent workflows" with the goal of reducing dependencies across teams. This also helps us move deliverable increments to a higher environment faster. The settings of the team are consistent with functional areas such as opportunity management, leadership/contact management, accounts, regional teams, and so on.

Figure 3: The development team setup for the ISC project

I must stress again that every team needs some cross-functional skills. A lot of times, we see that enterprises like to set up a lot of component teams, such as a UI team, another middleware/integration team, and a separate DevOps/automation team. If you build a lot of component teams, your dependency management needs will grow exponentially. This also creates silos of knowledge/skills.

You might ask, what does cross-functional really mean? Simply put, cross-functional teams will have all the necessary skills to deliver deliverable increments to a higher environment in their own way, rather than relying on such skills from other teams. Each member of a cross-functional team will have T-shaped skills, i.e. knowledge of both one core area of expertise but other areas to contribute to when necessary.

Another key aspect of this setup is the support structure for the team. We have a team of platform, business, domain architects, software development managers, design subject matter experts, and project managers who provide all the necessary support, as some of these skills are not available to every team.

We set up 8 development teams to develop CRM features, 6 in India and 2 in the US. In addition to these 8 development teams, there are other groups responsible for the Partnership Module (Salesforce PRM), Tableau CRM, and User Support.

Process

One of the questions I'm often asked is, are we following any large-scale agile methodologies to deliver this project? Before answering this question, let me explain the process we set up.

As a rule of thumb, one of our iterations is set to 2 weeks, and we should have an effective software incremental outcome for each iteration. We need to follow a test-first approach to achieve this. These process principles apply to all development teams.

Figure 4: The development process adopted by the ISC team

Independent workflows enable them to work in parallel. Does this mean that we don't have any dependencies? Not really. We have a daily site meeting process, which we call Scrum, in which every development team is involved, and the station focuses on addressing dependencies and obstacles in the iteration process.

Considering the nature of the project and the diversity of stakeholders, we decided to arrange a unified project iteration plan and demonstration activities. The development team will conduct their planning meetings individually and participate in unified project meetings to share the key features and sprint goals summarized in the iteration.

Finally, to give stakeholders an idea of where we're progressing towards the defined release milestones, we track progress toward iteration goals and release goals. A version is defined as a set of features that need to serve users in a particular geographic environment. We provide senior CIO leadership and project stakeholders weekly/bi-weekly with a one-page project summary that includes data from ALM tools, as well as barriers and issues requiring executive leadership support.

We didn't follow any well-defined agile or large-scale agile frameworks. Our focus is on following Extreme Programming (XP) practices in everything the development team does, and then using some Scrum activities.

Architecture

Many organizations struggle to adopt an agile way of working in the area of architecture. When an ISC project is launched, the envisaged project architecture spans three main areas:

Business architecture: Focuses on a business perspective on how the sales team ends up using the platform.

Platform architecture: Focuses on leveraging Salesforce's out-of-the-box capabilities, specific customization, and leveraging experience gained from IBM's previous implementation of Salesforce Service Cloud.

Integration and data architecture: The focus is on leveraging IBM's hybrid cloud strategy to set up trusted-sourced integrations for accounts, contacts, regions, leads, product tiers, quote-to-cash applications, user access, and data flows for a variety of downstream applications.

Figure 5: Key principles of the ISC architecture

We have set up an Architecture Review Committee (ARB). It consists of architects and product owners from each function. Their focus is on helping the development team determine the final architectural decision. They also reviewed features drafted by the Product Owner (Epics for the ALM language) and provided feedback. This helps speed up the interpretive process and ensures that the development team has preliminary design input. The development team can contact the ARB multiple times in an iteration and seek their support and review during the incremental development of features.

Salesforce architects in the project initiated communications sessions within the first two months of the project's launch. Key participants include Product Owners, Business, Platform, and Salesforce Architects, and the conference focuses on the following:

Sell role and journey diagrams to implement ISC's UI and UX interface design.

Business architecture

The integration and data architecture was designed by the enterprise architects of the CIO's CRM team, with a focus on modeling data from the source CRM, as well as trusted sources, middleware architecture, and DevSecOps practices.

An important lesson for us on the architecture side is that while we're working on a Salesforce project, architecture also needs to be flexible to adapt to changes and user feedback. Based on this principle, we have redesigned our region and account level solutions.

Engineering practices and toolchains

Building cross-functional teams allows us to align with a set of key principles in engineering practices and toolchains. These principles are:

Establish isc development, staging, and production environments within the first 30 days.

Automate build, deployment, and testing from the start.

The infrastructure for security and complaints aligns with IBM's hybrid cloud strategy.

We encourage development teams to follow a test-first approach, resulting in 90% functional test automation coverage.

When setting up integrations, we automate all aspects of infrastructure configuration, build, testing, and deployment through a dedicated CI-CD pipeline, enabling middleware integration services faster. The team can save 75% of their time compared to previous deployments.

We're also one of the few enterprise projects using Salesforce DX. We build ISC Salesforce packages in an integrated environment and then deploy them to staging and production environments in an automated manner.

Figure 6: Tool stack for CI-CD pipelines

Here are some of the standout features of the CI-CD pipeline setup for middleware microservices.

Figure 7: Benefits of a middleware CI-CD pipeline

The team's main learning outcomes and benefits are as follows:

Reuse pipeline libraries built for traditional CRM middleware.

Thanks to their previous expertise in IBM Cloud Kubernetes Services (IKS), the team could easily adapt to new technologies such as IBM RedHat OpenShift.

Built-in code quality and security

Spend 75% less time on middleware deployments than traditional CRM.

DevSecOps model of teams working together—Cross-functional skills of individual teams help accelerate the development of all tools on the ISC platform.

Assessment and governance

At an early meeting I attended, I had a better understanding of Agile. One issue that participants had been questioning was indicators.

A common problem is that metrics like burn-up, speed, cycle time, or throughout don't really reflect the progress of a project. How can leadership know everything is on track or not on track?

The host cleverly explained this. He asked a question: "How often do you look at the car dashboard while driving?" How long does it take to watch each time? “

"If you pay too much attention to the dashboard, you'll ignore the road conditions. Worse, this could lead to an accident," he explains.

In my opinion, if agile teams focus on following the values and principles of the manifesto, working with the business to do their highest priority work, building and deploying software that works regularly, seeking feedback and taking action, then progress will be transparent to everyone and you won't need as much governance.

We apply the following principles when establishing a team and project-level management system for ISC projects:

Use ALM tools to share a unified view of progress with stakeholders.

Visualize tracking of key features and dependencies between teams.

Transparent presentation of barriers and issues that require leadership support.

Figure 8: Governance work for ISC projects at different organizational levels

We encourage teams to proactively discuss dependencies between teams, if any, and plan them during iterations. Since we work 100% remotely, ALM tools can help us digitally visualize barriers and dependencies. These are discussed in daily inter-team meetings, where the focus is on immediately addressing obstacles. The meeting also discusses contingencies and updates needed to iterate over other parts of the project.

It is important to keep a close eye on the combined progress of all development teams in each iteration. We review projects weekly with key stakeholders from the CIO and operations leadership team, focusing on:

Availability of features in production environments versus requirements for specific GEO releases

Pipelines for ready and high-priority features for development teams to pick

Dependencies of each group within the CIO, integrated trusted source teams, product owners, etc

Content that requires executive leadership assistance (if any)

The executive leadership of Sales and Operations conducted a project called "Transformation Tuesday," in which sales leaders and representatives from all business units will be informed of the overall progress of the project, the results of upcoming features and product discovery workshops, and answers to key questions they ask. We also communicate regularly with the sales community through dedicated Slack channels, newsletters, videos of early adopters, and user documentation prepared by the Organizational Change Management team.

Culture

How do you define a team's culture? In my opinion, culture is the experience you experience every day in your interactions with other team members, peers, leaders and stakeholders.

One of the key points of the ISC CRM development team is that we will connect all IBM sellers to our current SugarCRM cloud platform in February 2020. These milestones were accomplished collaboratively by a team in the office.

It's already a closely connected team. We divided 6 small teams from the existing 3 CRM teams. Our goal is to make each development team have different skills and experience. A new team of team members took on roles such as business analyst and iteration manager. The entire team in India didn't have any previous experience with Salesforce.

We also have about 15 new members who have brought in the CRM development team from other departments or new people from college campuses. Unlike existing team members, we need to pay extra attention to these members to ensure that they can be fully engaged in a fully remote environment – even if we haven't been in face-to-face contact.

We try to follow these principles:

Flexibility: The team experiments, learns from them, and gradually adapts in iterations. Each team has a different skill set. Previous CRM experience is well combined with new team members with full-stack development skills.

Transparency: Encourage teams to be transparent about the issues and challenges they face during each iteration. This helps build a relationship of trust between the team and stakeholders.

Leadership Support: All software development managers are hands-on and support the team at all times throughout the project.

Figure 9: A culture of team unity. Source: Spencer Stuart (2019)

In their report on "The Art of Project Leadership," McKinsey says this about culture:

Effective project teams have a unique and shared identity and can create a culture of mutual trust and collaboration. Project leaders should articulate their goals, set an example of behavior, and foster an ideal culture.

All team members recognized the "team as one" attitude, which helped us overcome various challenges over the course of a year. We worked remotely throughout the process and blurred the boundaries between work and family in both rounds, but these obstacles didn't stop the team from moving forward because we realized that there was a greater meaning behind the project's goals.

Results achieved

Since the launch of the ISC project at the end of July 2020, we have deployed new features to production with each iteration. The first GEO All BU sales went to isochety in February 2021. Subsequently, May 21 was the second GEO. In July 2021, all the remaining OOs were transformed.

As of today, approximately 30,000 sales from all business units are working on the platform as envisaged.

Figure 10: Data on ISC results

The project also migrated data for each GEO from the previous CRM system to the ISC. More than 10 million records of all objects completed the migration and flowed to downstream applications in real time.

The test-first approach helps us ensure delivery quality throughout the project. The development team only receives one level critical event related to the features of the development. At the same time, all work passed a review of GEO-specific data visibility and other compliance requirements.

Jennifer Kady, head of global sales at IBM, says:

Unifying teams with a single view also speeds up sales and strengthens decision-making. Previously, many of IBM's sales processes were conducted in spreadsheets and demos outside of the platform. Siloed projects mean salespeople aren't sure whose numbers are correct and can create confusion when trying to predict an entire account. Teams can now extend business processes such as account planning by getting the same pages through built-in templates based on community collaboration. Through artificial intelligence, IBM can automate sales processes and better predict customer outcomes.

The IBM leadership team also shared their views on the success of the project's transformation.

Lessons learned

So, what lessons have we learned from working and delivering a transformational project of this magnitude?

As the project's timeline and GEO's go-live milestones are sacrosanct, leadership support and support for the team is key to overcoming the challenges posed by working fully remotely during the pandemic.

If we don't follow an iterative and incremental development process, and each iteration delivers software that's available to the production environment, we won't be able to achieve our project goals. Establishing all processes, tools, and practices, with a focus on deliverable increments is key.

It is important to reach out to departments and end users to solicit their feedback on key sales process transformation areas. We sometimes overlook this, but it comes back in the form of feature correction work.

Purposeful work, building cross-functional teams, and a commitment to tasks can help teams cope with frequent changes.

Enterprise architectures also need to evolve incrementally to accommodate feedback from BU and end users.

Figure 11: ISC project experience learned by the CIO development team

If I had to sum up the journey of the year in one word, it would be "resilience." These teams have worked tremendously to achieve all of the project milestones. As part of this team with amazing results, my heart is full of gratitude.

About the Author:

Jayesh Kadam has 21 years of experience in the IT field, covering software product development and consulting. As part of IBM, he is currently leading a project to deliver CRM software, which is used by about 30,000 IBM sales worldwide. Prior to joining IBM, Jayesh worked at Cognizant and Wipro. As a member of these organizations, he advocates agile and DevOps transformation among many of the clients he is responsible for. He has worked in India, the United States and Canada, working with clients and teams worldwide. He is passionate about incorporating agile values and principles into his daily work. In addition to his work, he is also passionate about sports and likes to watch good movies.

Dr. Ashay Saxena currently holds a Product Lead at IBM. He holds a PhD in the field of information systems from the Indian Institute of Management, Bangalore. He delves into the management methods employed by software teams in order to succeed with agile methods in a globally distributed form. He has conducted in-depth case studies at global multinational companies such as Intel, General Electric, Mindtree, and ThoughtWorks. He has spoken and researched in a number of international forums such as the Australian Conference on Information Systems, the ACM Conference on Computer and Human Studies, the India Agile Conference, the Agile Leadership Summit, the India Agile Week and the Software Product Management Summit.

https://www.infoq.com/articles/going-digital-pandemic/