It was July’ 20. A little over three months into 100% work from home mode (WFH) as first wave of the pandemic took off.

We at IBM Chief Information Office’s (CIO) CRM Platforms team, were just coming off successful completion of an initiative to board global sales teams to a SugarCRM hosted Cloud platform, from an in-premise CRM system. The initiative also involved adopting streamlining product hierarchy across all sales applications. 

Just as we were experiencing the new normal of remote working, it was decided to adopt Salesforce SalesCloud as single CRM system for global IBM sales teams and partners.

Key objectives outlined were as follows -

1. All IBM Sellers & Business Partners move to a single IBM Sales Platform (CRM). Salesforce Sales Cloud to be IBM’s unified CRM/sales platform with best-in-class integrations, analytics, and cognitive features.
2. 170 + tools and systems across the Go-to-market (GTM)/Sales Cycle Process currently in use would then be sunset with Sales teams living ON the new platform through entire sales lifecycle.
3. Go-live with the new platform within 1 year in July’ 21.

Here’s the story of how IBM CIO CRM Development squads worked through two Covid-19 waves, all-remote, to deliver the program that was christened as IBM Sales Cloud (ISC), in less than a year.

Background

My agile journey formally started in 2011.  I was working at Wipro, and was consulting with leaders from several customer organizations.  The process involved looking at their current way of working at a program and enterprise level, and then to come up with a roadmap of how different aspects of their program would need to change to enable agile ways of working.  

A key challenge throughout my consulting and coaching tenure, was to ensure that the roadmap covered all aspects of agile values & principles, and not just introduce some practices in haste to call them agile.  

Source 

According to McKinsey, “A comprehensive transformation touches every facet of the organization, including people, process, strategy, structure, and technology.”

Figure 1: McKinsey article on facets to look at during transformation

When I took up the role of Technical Program Manager for development of CRM functionality, I relied on my consulting and coaching experience, to define a transformation levers-based framework, that would look at all facets of the program.

Program Management Framework

As we kicked-off ISC delivery, we used Enterprise agility theme as Program Management levers to ensure the delivery touched all facets.

Figure 2: Transformation levers-based Program Management Framework

Let us look at key principles behind each of these levers. We will also look at each lever in detail subsequently.

1. Team set-up: Key principle behind team set-up was that they must be cross-functional, and not component based.  Second, was trying to have functionally independent work-streams. 
2. Process:  A key challenge many large programs face, is they are set-up as large waterfall releases even though they claim to be agile.  We consciously wanted to avoid that.  So, the process set-up was to follow iterative and incremental development.  This would require vertical slicing of feature work as much as possible and moving shippable increments to higher environments multiple times every iteration.  We needed to imbibe a Test-first philosophy to achieve that.
3. Architecture: Idea was to have an initial version in first 90 days.  And then, incrementally align it to evolving requirements and feedback from business.  A concept of Architecture review board (ARB) was recommended by stakeholders, and it worked quite well for a program of this scale.
4. Engineering & Tools: Development, staging & production environments were set-up within first 30 days; GitHub repositories, Salesforce scratch org as development environments were set-up. Need for moving shippable increments to higher environment(s) also meant we needed a robust build, deploy and test pipeline.
5. Measure & Governance: A key aspect of the program was diverse set of stakeholders. Senior Executives from Sales, Operations, Global Chief Data Office (GCDO), and CIO groups were involved. Apart from them, each of the Business Units (BUs) had a stake too, as sellers & sales-managers from respective BUs would be the end-users of ISC Platform. We focused on keeping the governance as lean as possible. Agile application lifecycle management tool as single source of truth on progress as well as dependency management across teams.
6. Culture: Lastly, all these levers wouldn’t be effective unless we had right culture in our teams.  We re-emphasized that we could achieve program objectives only if we really worked as one-team. There were several unknowns when we started, so teams were encouraged to experiment and learn rather than waiting for everything to be perfect. Remote work and evolving scope of work, put lot of pressure on teams.  As leaders, we acknowledged it, and reassured the teams that we were available and involved 100% all the time.

Let us look at each lever in little more detail now.

Team Set-up

As I mentioned earlier, key principle around team set-up was ‘Independent work-streams’ to minimize cross-team dependencies. It also helped in moving shippable increments to higher environments faster.  Team were set-up aligned to a functional area.  For example, Opportunity Management, Lead/Contact management, Accounts, Territories etc.

Figure 3: Development Team set-up on ISC Program

I must re-emphasize need for cross-functional skills in each team.  Many a times, we see that they are formed as component teams.  For example, an UI team, another middleware/integration team, and a separate DevOps/automation team.  If you set-up components teams, you are increasing the dependency management exponentially.  It also creates knowledge/skill silos.  

What does cross-functional really mean, you may ask? Simply put, cross-functional team will have all necessary skills to deliver a shippable increment to higher environment on their own, rather than being dependent on other teams for those skills. Each member of a cross-functional team would have T-shaped skills with a core expertise area, but knowledge of other areas as well to contribute as necessary. 

Another key aspect of this set-up was the support structure to squads.  We had a group of Platform, Business, Domain architects, Software Development managers, Design subject matter experts, and Program manager(s), who provided all necessary support as some of these skills were not available within each squad.

We set-up 8 Development teams to work on CRM functionality, 6 in India, and 2 in USA. There were other groups working on Partner relationship module (Salesforce PRM), Tableau CRM, and User enablement, besides these 8 development teams.

Process

A question I get a lot is, if we followed any scaled agile approach for delivering this program? Before I answer that question, let me explain the process we set-up.  

The thumb rules were that we will have 2-week iteration, and we should have a working software increment as outcome of every iteration.  We needed to follow test first approach to achieve this objective.  These process principles were adopted by each development team.  

Figure 4: Development Process adopted by ISC teams

Independent work-streams allowed them to work in parallel. Does that mean we did not have any dependencies?  Not really.  We had a stand-up which we called as Scrum of Scrum, conducted daily, with participation from each development team, with focus on dependencies and impediment resolution during the iteration.  

Given the nature of program and diverse set of stakeholders, we decided to conduct consolidated program iteration planning and showcase events.  Development teams would conduct their planning meetings individually. And join this program meeting to share summary of key features taken up in the iteration, and the sprint goal.

Lastly, to provide stakeholders a view of how we were progressing against defined release milestones, we tracked progress against iteration goals vis-à-vis release objectives. A release was defined as a set of features required to board users from a specific Geography. We provided a one-page weekly/fortnightly program summary to senior CIO leadership and program stakeholders, with data from ALM tool, along with any blockers & issues that needed executive leadership support.

We did not follow any defined agile or scaled agile frameworks. Our focus was to follow Extreme programming (XP) practices in everything development teams did, and then use some of Scrum events.

Architecture

Architecture is an area that has struggled to adopt agile ways of working in many organizations. When ISC program was launched, architecture was envisioned across three major areas -

1. Business Architecture: focused on business perspective about how the platform would eventually be used by Sales teams.
2. Platform Architecture: focused on leveraging out-of-box Salesforce functionality, specific customization, and utilizing learning from previous implementation of Salesforce ServiceCloud at IBM.
3. Integration & Data Architecture: focused on leveraging IBM’s Hybrid Cloud strategy to set-up integrations with trusted sources for Accounts, Contacts, Territories, Leads, Product hierarchy, Quote to cash applications, user access and data-streaming for various down-stream applications.

Figure 5: Key principles for ISC Architecture

An Architecture Review Board (ARB) was set-up. It consisted of Architects across functions and Product Owners. Their focus was to help development teams in finalization of architecture decisions. They also reviewed Features (Epics in ALM language) that were drafted by Product owners and provided feedback. It helped in expediting elaboration and ensured development teams had initial design inputs. Development teams could reach out to ARB multiple times during an iteration and seek their support & review during incremental development of features.

Salesforce Architects on the program helped by conducting Illuminate sessions within first two months of program launch. Key participants were Product owners, Business, Platform & Salesforce architects with focus on following - 

• Seller personas & journey mapping to enable ISC UI & UX interface design.
• Business Architecture

Integration & Data Architecture was envisioned by CIO’s CRM team’s Enterprise architect with focus on data modelling with source CRM as well as trusted sources, middleware architecture and DevSecOps practices.

A key learning on architecture for us was that even though we were working on a Package implementation (Salesforce) program, the architecture needed to be flexible to adapt to change, as well as user-feedback. Territory and Account hierarchy solutions were re-designed based on this principle.

Engineering Practices & Tooling

Setting up cross-functional squads helped us in aligning to key principles on Engineering practices & Tooling. These were - 

1. ISC Development, Staging & Production environments set-up in first 30 days.
2. Start with Build, Deployment & Testing automation.
3. Secure & Complaint infrastructure aligned to IBM Hybrid Cloud strategy.

Each development team was encouraged to follow Test-first approach, which has helped in achieving 90% coverage on functional test automation.

As part of setting up integrations, automating all aspects of Infrastructure provisioning, build, testing and deployment, via a dedicated CI-CD pipeline, helped in bringing the middle-ware integration services up at a faster pace. The team could save 75% of time compared to previous deployments.

We were also one of the very few Enterprise programs using Salesforce DX as building ISC Salesforce packages off Integration environment, and then deploying them in an automated way to Staging & Production environments.

Figure 6: Tooling stack for CI-CD Pipeline

Here are some salient features of CI-CD pipeline set-up for middleware microservices.

Figure 7: Benefits of Middleware CI-CD pipeline

Key learning and benefits for teams were as follows -

• Reused Pipeline libraries built for legacy CRM Middleware.
• Adapting to new technologies like IBM RedHat OpenShift was easy due to prior expertise with IBM Cloud Kubernetes service (IKS)
• In-built code quality and security
• 75% reduction in time spent on middleware deployments Vs legacy CRM
• One-team DevSecOps Model - Cross-functional skills in each squad helped in faster pace on all tooling development for ISC platform.

Measure & Governance

In one of first sessions, I attended to understand agile better, a constant disbelief among participants was about metrics. 

A common concern was that metrics like burn-up, velocity, cycle-time or throughout, didn’t really give a view of progress in the project. How would the leadership know everything was on-track or not?

The facilitator explained it very nicely. He asked, “how often do you look at your car’s dashboard while driving? And for how long?” 

“You would miss out big picture on the road, if you focused too much on the dashboard. Worse, it could result in an accident”, he explained.

In my view, if agile teams focus on following values & principles from manifesto, took up highest priority work in collaboration with business, built and deployed working software frequently, sought and acted on feedback, the progress would be transparent to all, and you wouldn’t need lot of governance.

We adopted following principles while setting up governance for ISC program at team and program level:

• Use the ALM tool to share unified progress view to stakeholders.
• Visual tracking of key feature and inter-team dependencies.
• Transparency about blockers and issues needing leadership support.

Figure 8: Governance on ISC Program at different organization levels

Teams were encouraged to take ownership of discussing inter-team dependencies if any and plan them in iterations. As we were 100% remote, ALM tool helped in surfacing blockers and dependencies digitally. These were discussed in inter-team catch-ups every day with focus on resolving blockers immediately. Contingencies as well as any updates needed to rest of iteration plan were also discussed.

It was important to keep an eye on consolidated progress across all development teams every iteration. Weekly program review with key stakeholders from CIO and Operations leadership team focused on looking at -

• Availability of features in production Vs required for a particular GEO release
• Pipeline of ready and prioritized features for development teams to pick.
• Dependencies across sub-groups within CIO, trusted source teams for integrations, Product Owners etc.
• Help needed from executive leadership, if any.

Sales & Operations executive leadership ran a program called ‘Transformation Tuesdays’, where Sales leaders and representatives from all Business Units would be informed about overall progress, upcoming features, and outcome of product discovery workshops, along with answers to their key questions. At the same time, regular communication would be shared with Sales community via dedicated Slack channels, newsletters, videos by early users, and user-documentation prepared by Organization Change management team.

Culture

How does one define culture in a team? In my view, culture is what you experience daily in your interaction with other team-members, peers, leaders, and stakeholders.

A key aspect about ISC CRM Development team was that we were coming off from boarding all IBM sellers to current SugarCRM Cloud platform in Feb’ 2020. These milestones were achieved by a team collaborating in-person, at office.

It was a close-knit team already. We carved out 6 smaller teams from 3 existing CRM teams. Our aim was to have diverse group of skills & experience in every development team. A new set of team-members were taking up roles such as Business Analyst & Iteration Manager. Entire team in India had zero prior Salesforce experience.

We also had about 15 new members joining CRM Development team laterally, or from college campuses. Unlike existing team-members, additional focus was required towards ensuring these new team-members were engaged in the 100% remote world, without having met them in-person at all.

We tried to follow these principles - 

• Flexibility: Teams experiment, learn from it, and adapt iteratively. Diverse mix of skills in each team. Prior CRM domain experience was combined with new team-members having full-stack development skills.
• Transparency: Encouraged teams to be transparent about issues and challenges faced during every iteration. Helped in build trust within teams and with stakeholders.
• Leadership Support: All Software Development managers were hands-on, and always available to support teams throughout the duration of program.

Figure 9: One-Team Culture. Source: SpencerStuart (2019)

McKinsey in their report about ‘The art of project leadership’ say this about culture - 

Effective project teams have a unique and shared identity and create a culture of mutual trust and collaboration. Project leaders should articulate purpose, role model behaviours, and nourish the desired culture.

Each team-member imbibed the one-team attitude, which helped us overcome various challenge during the 1-year period. Working all-remote, diminishing boundaries between work and home amid two Covid-19 waves, didn’t stop the team from pushing ahead, as we realized the larger purpose behind the program objective.

Outcomes Achieved

Starting from ISC program kick-off in late July’20, deploying new features to production every iteration, sellers from first GEO across all BUs, were on-boarded to ISC in Feb’21. It was followed by 2nd GEO in May’21 and remaining all GEOs in July’21.

As of today, approximately 30K sellers from all Business Units are living ON the platform as envisioned. 

Figure 10: ISC outcomes in numbers

Program also involved Data migration from current CRM system(s) to ISC for each GEO. 10M+ records across all objects migrated and streamed real-time to down-stream applications.

The Test-first approach helped in ensuring Quality of delivery was maintained throughout the duration of program. Development teams received only one Severity 1 incident related to features developed. At the same time, all work passed scrutiny of GEO specific data visibility and other compliance requirements.

Jennifer Kady, IBM Global Sales Executive said,

Unifying teams with a single view also accelerates velocity and decision-making capabilities for sales. Previously, much of IBM’s sales processes occurred off the platform in spreadsheets and presentations. Siloed line items meant sellers were unsure whose numbers were correct, causing confusion when attempting to forecast an entire account. Now, teams can get on the same page with built-in templates for community-based collaboration that scale business processes like account planning. And with AI, IBM can automate sales processes and better predict account outcomes.

IBM leadership team sharing their views on transformational success of the program.

For @IBM, Salesforce + Slack = "A big change in our company."

Learn how one of the world's largest companies is using #Customer360 and @SlackHQ to build a more vibrant work culture and transform for the next 100 years of work: https://t.co/2AUg98xO73 pic.twitter.com/atCpZR3TvL

— Salesforce #TeamEarth (@salesforce) August 25, 2021

Lessons Learnt

So, what did we learn from working and delivering on a transformation program of this scale?

1. As program timelines and GEO go-live milestones were sacrosanct, leadership support and availability to teams was key to get through various challenges in all-remote, Covid-19 times.
2. We couldn’t have met program objectives if we did not follow iterative & incremental development with working software in production every iteration. Setting up all processes, tools, and practices with focus on shippable increments was key.
3. Engaging with BUs and end-users to solicit their feedback on key sales process transformation areas was important. We missed it at times, and it came back in form of modifications in features.
4. Working with a purpose, setting up cross-functional teams, and get it done attitude helped teams to respond to changes that came in frequently.
5. Enterprise Architecture also needed to evolve incrementally to accommodate BU and end-user feedback.

Figure 11: ISC Lessons learnt by CIO Development teams

If I had to summarize the year long journey in one word, it would be ‘resilience’. The teams went above and beyond to achieve all the program milestones. I feel a sense of gratitude as a member of this incredible team.