Descriptive Study of an e-retail Transformation Program Organization

Introduction

This study is about the replatforming of a big e-commerce legacy application to Salesforce in a retail company.

The program lasted more than 3 years, involved more than 150 people. We were not using Org Topologies at that time but we re-organized the program several times and applied elevating katas moving the organization of the program increasingly toward adaptive topology. Below the description of the 3 stages the program went through with each time the mapping, the assessment and the next steps toward the new organization design. To note that for confidentiality purpose, it does not reflect the exact organization put in place but it is very similar.

First stage

The first "stage" goal was to build the core model of the new e-commerce application that would then be rolled out to approximately 30 countries. It was a replatforming program, therefore the main assumption was that functionally few things should be changed. The main idea behind this the organization design was to optimize the efficiency and reduce lead time toward completion of the replatforming as the respect of the budget allocated was one of the main focus.

There were 3 main technologies involved in the migration: the Front end side of the web application, the back-end side and also the integration layer where all the API rest calls were transiting.

Organization Mapping

Below the list of the teams. None of the teams were able to deliver alone value. To deliver value, most of the time development on all 3 stacks is required. The approach was to have "factories" to build as fast as possible components that were integrated later by a release management team in charge of making sure that all the components are well integrated.

• Content: This development team was responsible for part of the back-end related to content display, similar to a Backend-for-Frontend approach.

• Order: This team handled the back-end business logic for order management, including shipping and billing details, as well as confirming product availability through integration with an external warehouse application.

• Payment: This team managed payment processing, supporting multiple payment methods (credit card, PayPal, Apple Pay). They were also responsible for fraud detection and blocking suspicious transactions when necessary.

• Integration Factory: This team was responsible for implementing and managing all API layers. All front-end to back-end calls were routed through this layer, ensuring enhanced security, better control of the overall architecture, and enabling integration with external systems beyond the core back-end.

• Front-End: This team developed and maintained all JavaScript/HTML components running in the web browser.

• Release Management: This team did not perform development but was responsible for consolidating code tags, packaging releases, and deploying them across environments. Dependency management was a key focus to ensure application stability post-deployment. They were also providing guidelines to development team on how to merge and deploy.

• Architecture: This team designed the overall solution based on business requirements. While not involved in development, they produced high-level designs and integration diagrams to guide the development teams.

Below the mapping of the organization design on the Org Topologies map.

The Architecture team was in charge and providing architecture for the full solution, therefore it was related to Directing archetype.

For Release management team, it oversaw coordinating the releases, with other development teams, and providing guidelines. It was related to Directing archetype though having less complete view of the solution as compared to the Architecture team.

For the other development teams, all were accountable for developing some tasks or capabilities but usually they did not have all the skills to deliver the full value.

We can see that the placement of the teams above reflects the configuration of a "Resource Topology" where Architecture team define the solution and other component teams deliver parts of the solution that need to be combined.

Below a table explaining in more systematic way the positioning on the quadrant for each team:

Assessment

After running with this organization a while, many quality issues were raised, above the level of what would be expected for this kind of program.

One of the main reasons for the quality issues was determined to be communication between the different component teams. It was decided to adjust the model.

Second stage

Organization Mapping

To improve communication between teams and enable them to be fully autonomous in delivering value, we reorganized the teams to be more cross-functional, meaning each team has all the skills needed to deliver value.

Basically, the Front-End team and the integration factory teams were disbanded and integrated to back-end teams that were already more feature oriented.

So, Front end team people were added to Content, Order and payment teams.

Integration team people were added to Content, Order and Payment teams.

As below, how the new organization design looked like.

As we can see, now each team, similar to what is called in LeSS feature teams, were able to deliver their tasks or capabilities from end to end. The scope of skills mandate had been increased.

For the scope of work mandate, things remained roughly the same with still the architecture team deciding on what the solution should be and the teams delivering parts of it.

This organization aligns with the Delivery Topology.

Below a table explaining in more systematic way the positioning on the quadrant for each team:

Assessment

This structure enabled a steadier delivery with less quality issues and the global feedback around it was positive: less issues of quality and of integration.

One downside was the feeling of some team members to be less sharing practices with the people of their own technology stack. We initiated some "Community of practices" with Front-end people sharing together, Integration people sharing together and Back-end people sharing together to make up for this.

To note that the idea of having truly full-stack people in the new feature team was mentioned but peoples were more interested in developing their expertise in one domain and it was not the priority of the management to investigate further this option.

With this topology, it was possible to finalize the core model of the solution to be rolled out on all the countries.

Third stage

Organization mapping

Now that the core model was finalized, it was time to roll it out to all the countries of the retail company. Rolling out the core model in a country is done in two main phases:

• First, the solution for the country needs to be designed, adapted, tested, and validated by the country.

• Then, the solution is deployed, with a clear cut-over date, and post-deployment issues are handled.

First phase

During the first phase, the core model needed to be adapted to each country’s specificities. For example, some countries had specific tax rules or payment methods.

These specificities were first identified, then addressed either by:

• configuration (no code changes), or

• development of specific modules

After this initial design step, the team configured or developed the solution and tested it through regular interactions with business owners and country representatives until validation.

Second phase

During the second phase (Hypercare), the solution was deployed to production.

Post-deployment issues were handled and prioritized based on criticality, with the most critical issues being fixed and deployed within hours.

Team organization

Each country is dependent of a geographic area and we had 3 of them:

• Asia

• Americas

• EMEA (Europe, Middle East and Africa)

For each area:

• A business owner consolidated and prioritized requirements

• A development team was assigned

Each development team included:

• Scrum master

• Architect

• Business analysts

• Front-end, integration, back-end developers

• Testers

Compared to Stage 2, teams remained cross-functional and complete, with all the skills required to deliver value end-to-end.

Business owners and country representatives were not embedded in the teams but were closely collaborating during solution design and validation.

Architects were partially decentralized (aligned per region), but a central architecture group still ensured overall consistency.

A release management team also remained in place due to ongoing integration challenges.

Mandate analysis

As in Stage 2, geographical teams had all the required skills to:

• design adaptations

• implement changes

• deploy and stabilize the solution

This confirms that teams were complete in terms of skills.

The Scope of Work Mandate evolved compared to Stage 2 but remained at output level.

Teams were able to:

• collaborate with business owners

• participate in solution decisions at the country level

• adapt the solution to local needs

However, they did not own product evolution, due to:

• Strategic decisions about new capabilities and user journeys were made by:

  • business owners

  • central architecture

• These new capabilities were implemented by separate feature teams outside of the rollout

Therefore the geographical teams were not in a position to decide what value should be created at product level.

Architecture was partially decentralized but still retained a central coordinating role.

This means:

• Teams had some autonomy to adapt solutions

• But within architectural constraints defined centrally

The  release management team what still required as there were still:

• persistent coordination needs across teams

• incomplete integration autonomy

In parallel, the feature teams from stage 2 remained for the standard application development and maintenance. They were not part of the roll out but now those teams were implementing new features and fixing issues with the core model.

In the above diagram, they appeared in orange. As it was outside of the program, I will not describe them but finally after the rollout was complete, those teams would be the nucleus of a new organization to support the website.

Below a table explaining in more systematic way the positioning on the quadrant for each team:

The organization at this stage remains a Delivery Topology, but at a higher level of maturity than Stage 2.

This is characterized by:

• complete, cross-functional teams

• end-to-end delivery ownership (including deployment and hypercare)

• strong collaboration with business stakeholders

• partial decentralization of decision-making

However, it does not reach Adaptive Topology as the Scope of Work Mandate remained at output level.

Assessment

Good feedback came from this organization and country representatives were quite satisfied as the teams were able to deliver the promises and actively collaborate to take decisions on the product when the solution needed to be adapted.

Also, the quality of the deployment was good. Though the first countries to be deployed involved several major issues, the number of issues after deployment gradually decreased after each new deployment to production, and the solution proved to be quite stable without major user disruptions at the end.

The website revenue was continuing to grow steadily, and, in addition, the performance was improved with a reduction in errors and an increase in successful requests to the website.

As explained before, the organization was not adaptive as the Scope of Work Mandate remained at output level for development teams. Central Architecture teams and Business Owners had the control over the work mandate, however not the skill set to deliver value.

Central Architecture and Business Owners were making strategic decisions regarding how to evolve the solution to answer new market needs, but those capabilities or new user journeys were implemented inside the feature teams from Stage 2 that were outside of the program.

Below the limiting factors preventing the organization from evolving toward an Adaptive Topology:

• The separation between defining value and delivering value remained, with Business Owners and Architects holding Directing intelligence, while development teams focused on execution.

• The Scope of Work Mandate of the geographical teams remained at output level, even if they were able to influence local adaptations.

• The fragmentation of product evolution, where new capabilities were implemented outside the rollout teams, prevented full ownership of outcomes within a single unit.

• The continued presence of a release management team as the integration and coordination were not fully internalized within the teams.

• The central architectural governance, although partially decentralized, still constrained full decision autonomy at team level.

As a result, the organization achieved strong delivery performance and improved quality, but within a Delivery Topology, without reaching full outcome ownership and adaptiveness.

Conclusion

This descriptive study shows how a program organization was first designed as a Resource Topology with the idea of efficiency in mind, but then evolved toward a Delivery Topology to address quality issues caused by communication complexity.

Finally, the teams were reorganized into more country-aligned units, enabling them to better handle the variability of customer needs and collaborate more closely with business stakeholders.

This evolution led to good delivery performance, allowing the organization to achieve higher quality, better stability, and stronger alignment with business expectations. However, the organization remained within a Delivery Topology, as the Scope of Work Mandate for development teams stayed at output level, while product direction and strategic decisions continued to be owned by central Architecture and Business Owners. This separation between defining and delivering value limited the ability to achieve full outcome ownership within the teams.

Looking forward, two key questions remain. First, how can the organization better align the definition and delivery of value, reducing the fragmentation between central decision-making and execution teams? Second, how should the post-rollout organization be designed to sustain value delivery to e-retail customers, building on the increased completeness and autonomy developed during the program?