Agile in Action: Lessons from a Global SAP ECC Implementation

Over the past 4-5 years, the Global IT team at ALK has implemented a series of large, agile projects that have delivered good business results. The journey has not been without challenges – but has contributed significantly to our learning curve as an organization. Also, our SAP delivery center has navigated a transformation from traditional release structures to an agile-driven setup, which has also seen its fair share of obstacles. During this shift, a noteworthy positive effect has been a reduction in the amount of rework and much better alignment across business units, which has resulted in a better prioritization process ensuring a better focus on the most valuable change requests.

The key focus of this article will be on an agile implementation of a full-scale SAP ECC project that is currently underway at one of our production sites. In the article we will present our approach to agile in the pharmaceutical industry, which we have named Hybrid-agile. We will argue why true-agile have had limited adoption in our industry, and hereafter do a walkthrough of the pragmatic approach to agile we utilize in SAP projects, incl. a summary of the benefits and challenges we have seen so far.

High-level Project overview

The aim of the SAP factory project is to harmonize and enhance our business processes and improve our operating model. This involves aligning the site with the SAP ALK template while phasing out the legacy technology that struggles to support the business growth. The project is organized into six tracks, each representing a specific process domain:

• Sales and shipping
• Material handling
• Quality control and assurance
• Production
• Packaging
• Finance

The project team consists of approximately 60 members, split evenly between IT and Line of Business (LoB) representatives. The technical scope of the project covers SAP ECC (all core modules except PM, with QM and WM being novel to the site), ATTP, and an array of satellite systems interfaced to SAP, mostly within the finance, distribution, and labeling domain.

The project timeline stretches across an estimated two calendar years, factoring in the time-intensive nature of the authority-required system validation process.

Choosing the Right Methodology: One size does not fit all (agile is not always the answer)

We believe in the importance of choosing the appropriate methodology based on the nature of the project, whether it be agile or a more traditional approach. Agile is not a rigid doctrine for us, but rather a recognition that different projects require different approaches. We also emphasize that preparation is crucial regardless of the selected methodology: agile is not an excuse to run without a plan or direction.

For projects with clear scope and low uncertainty, we recommend using a waterfall approach. This is typically suitable for smaller simple tasks or complicated but well-defined projects such data migrations, battle-tested roll-out projects, etc. However, as project complexity and uncertainty increase, waterfall methodology may prove inadequate. Gate-based approaches often struggle to handle feedback loops, incorporate learnings and maintain focus on the right things when projects are complex. Issues or misunderstandings in the requirements that arise late in the process can be costly to rectify in terms of both time and budget. Failing to implement lessons learned also diminishes the overall possibility for benefit realization of the project.

In essence, for complex projects, the waterfall approach brings less visibility during the implementation, less ability to change and as a consequence, more risk compared with the iterative and adaptive approach of agile.

Challenge: Running agile in the pharmaceutical industry with heavy external regulations is hard

In our experience, IT projects in the pharmaceutical industry often follow a waterfall approach. But why is that the case? We've observed numerous projects with both high complexity and uncertainty, which would seemingly benefit from agile methodologies, but are instead managed using waterfall. Our best assumption is that due to the heavy regulation and stringent requirements for documentation, testing, and traceability in the pharmaceutical industry, waterfall has been perceived as a safer option.

Particularly, in accordance with the principles outlined by the Good Automated Manufacturing Practice (GAMP[1]), a framework embraced by most regulatory authorities, their validation model bears a striking resemblance to the conventional waterfall model. Consequently, over time, enterprises have demonstrated a historical inclination towards aligning their practices with this approach.

Furthermore, the Quality Management System (QMS) employed within the pharmaceutical domain is intentionally structured to accord paramount importance to patient safety. This is accomplished through the implementation of a stage-gate approval mechanism, a design that similarly resonates with the waterfall approach.

How are the agile benefits of running complex projects realized without jeopardizing the pharmaceutical regulation and QMS?

The pragmatic way to deliver better SAP projects: Hybrid-agile

Based on our collective +20-years' experience in running SAP projects, we have observed that the traditional waterfall approach to SAP implementations often leads to schedule delays, cost overruns, and under-delivery on both scope and expected benefits. SAP projects are inherently complex, demanding extensive preparation and iterative learning within the project team to achieve successful outcomes.

We find that to achieve success in SAP projects, a more adaptive and iterative approach is essential. Agile allows for flexibility and adaptability by emphasizing iterative and incremental development, enabling teams to respond to changing requirements and company conditions and decisions. Unlike waterfall's rigid sequential approach, agile encourages collaboration, frequent feedback, and continuous improvement. Agile also promotes greater stakeholder involvement throughout the project, leading to higher customer satisfaction.

This realization is not novel, evident from the latest GAMP guideline update by its governing body, ISPE. They have introduced a section on agile methodologies and underscored the promotion of critical thinking.

However, in our implementation of agile frameworks, we do so with distinct variations. This gives rise to what we call Hybrid-agile, as the main difference is that we do not release increments after each sprint.

Consequently, the practical implications are:

1. Everything will be released in one package after validation.
2. Prioritization across the sprints based on business value is not relevant.

This has some disadvantages on the application of agile, but holistically, we believe it is the best way given our circumstances:

1. The numerous sequential steps needed for validation and regulatory compliance to do an increment release, cannot be efficiently condensed to fit a sprint's time horizon (4 weeks).
2. Most of our projects are not suitable for running as MVP (minimum viable product) projects, especially those that almost solely deliver core functionality such as the fundamental ERP implementations.

The potential of deploying an excessively minimal version poses a risk to erode user confidence in both our systems and projects. In addition, releasing such partial solutions continuously will require substantial regression testing to prevent unidentified cross-functional dependencies to trigger defects.

Note that this is not about taking on challenging project scopes or striving for simpler solutions to meet requirements. Rather, it is about ensuring full process support is in place at the time of go-live.

Nevertheless, while the possibility of adapting our strategy to accommodate incremental releases in future projects remains open, our decision for the mentioned project is to proceed as stated above.

Not releasing functionality after each sprint, brings a challenge in terms of ensuring complete transparency and mitigating technical debt[2] between sprints. However, we see measures that can be taken to minimize this issue, and these can be included in the Definition of Done of each sprint.

Even though applying agile in the pharmaceutical sector is challenging, this tailored approach with variants – as we refer to as Hybrid Agile – enables us to still reap many of its benefits.

Applying ALK Hybrid-agile

While we do not implement incremental releases after each sprint, we can still apply key tools and principles from various agile frameworks in order to reap the benefits.

Predominantly, we adhere to Scrum principles, encompassing sprint planning, backlog refinement, sprint review, and retrospective events. Utilizing project and sprint backlogs, sprint goals, and our version of the "Definition of Done" (DoD), we maintain alignment to a high degree. Unlike Scrum, we term it a project backlog and demonstrate some flexibility in team role terminology in order to fit it into our existing organization.

To guide our approach, we have established a Sprint Guide, a definitive document that unifies our work methods and applies agile principles to the project, including DoD maintenance. Furthermore, we use it to share templates and insights to ensure consistent work quality across teams.

Project preparation phase (think slow to act fast[3]):

We invested considerable time and resources in project planning before implementation. This involved defining requirements and solutions in detail to create well-defined user stories for the sprints. Through Gemba-walks[4] in all six tracks, we gained insights into current processes, laying the groundwork for future requirements. Collaboratively, IT and LoB embarked on an iterative process to enhance business processes by redesigning systems and workflows.

We mapped out end-to-end business processes, resulting in the creation of 18 process diagrams and over 450 user stories that were estimated in complexity relative to each other using the Fibonacci sequence (as story points). These user stories formed the basis for developing the future technical solutions.

Complex user stories with high Fibonacci score have in multiple cases been prototyped and tested within specific tracks to mitigate the risk for misalignment on the requirement and to demonstrate the solution fit before entering implementation.

In concluding the preparation phase, we produced a high-level implementation plan with two high level phases:

1. Build: A Hybrid-agile phase that included 7 sprints of 4 weeks (plus a buffer sprint) to iteratively build, test and document the full solution.
2. Validation: A plan-driven phase to formally perform system validation of the new solution and document the formal testing of the requirements (at this point, documented as gaps) as well as the technical import, data migration and go-live activities.

Efficient planning and investment in each phase yield savings in subsequent stages. Thorough preparation of requirements and solutions before sprints minimizes adjustments during testing. Likewise, strong testing in the Hybrid Agile phase facilitates smoother validation.

Nonetheless, this is a delicate equilibrium. Complex or chaotic topics greatly benefit from early, robust preparation. Simpler or even certain complicated issues might align better with minimal preparation and adapting during sprints.

Project implementation phase – so far:

The implementation commenced with an off-site event, during which iteration planning took place for each of the 6 tracks, drawing inspiration from the SAFe framework. Afterwards, the following 3-4 weeks were dedicated to a "boot camp" phase, focused on building all the fundamental and standard SAP functionalities identified in the user stories.

With the preparation in place – the requirements and solutions prepared, the system basic build in place – the sprints could start, focusing on the user stories selected for the first sprint as well as for the next.

Each sprint delivers a rigorously tested technical solution for the designated user story from the Line of Business, accompanied by comprehensive documentation as specified in our "Definition of Done" (DoD). This is planned and tracked real-time in Azure DevOps Boards. The insights from the data provided by the tool have in multiple cases been able to spot and action difficulties within a track much faster than what we normally are.

At the current stage, two-thirds through the sprints, we have gained the following insights:

• We are seeing a great boost in productivity during sprints, and it keeps getting better as everyone gets the hang of the new ways of working.
• Collaboration across units has increased, helping us in aligning the project team with tasks and timing, though not yet fully optimized.
• We need to balance the sprint's energy and urgency to avoid stressing the team with excessive work. However, our retrospectives show that team engagement and well-being are quite strong.
• Balancing project documentation during sprints is critical; excessive emphasis can compromise quality. We strive for a better balance prioritizing quality over documentation.
• Shifting towards a more agile and proactive approach demands change management, particularly among senior stakeholders. This exposes them to an in-depth view of the project's internal mechanics, which might appear less refined than usual standards.

Elevated data quality benefits everyone, while low data quality has adverse effects. Achieving this requires investment and time, which should be incorporated into sprint work and factored into planning. Initially, this might appear as time diverted from substantive tasks, yet it remains essential.

Implementation phase – next steps:

The objective is to complete solution building and testing by the last sprint, followed by the "Business simulation" phase. During this phase, we enact the new end-to-end processes through role-playing, closely resembling real-world scenarios and involving the relevant stakeholders in tasks while utilizing the system comprehensively.

The simulation aims to uncover and rectify errors and potential misalignments in the future process design. Once the Business Simulation concludes, we transition from the Hybrid-agile phase to a more plan-driven validation phase. Subsequently, the new solution will be released to Production and activated for real-world use.

Final remarks

Over the past 4-5 years, the Global IT team at ALK has implemented a series of large, agile projects that have delivered good business results. However, the Global SAP ECC Implementation is our first project where we have embraced many SCRUM ideas and tools in a new way we call "Hybrid-agile". This is also the first large project where we plan and keep track of each sprint using Azure DevOps. As it is only one project of this magnitude and since it is not yet complete, we cannot draw general conclusions yet – however, for the specific project we believe the benefits of running hybrid-agile outweighs the challenges by not running fully agile or the alternative of waterfall. Rework efforts are down, while alignment, team well-being and deliverable progress is up.

Being pragmatic in our agile approach has helped us tackle some of the challenges we have experienced so far. Some could argue that our approach is not truly agile, however, what matters most to us is the value and output we deliver. By selectively choosing agile elements from the toolbox, we believe the hybrid-agile approach is demonstrating good results.

We genuinely welcome any input, feedback, or ideas for improvement you may have. Your insights can help us refine and strengthen our approach further.

[1] Good Automated Manufacturing Practice (GAMP) is a set of guidelines for manufacturers and users of automated systems in the pharmaceutical industry published by the International Society for Pharmaceutical Engineering (ISPE).

[2] SCRUM definition of technical debt: Deferred work

[3] Bent Flyvbjerg quote, which was lately recommended again in his book from 2023: “How Big Things Get Done”.

[4] Gemba-walk: From the Japanese word “Gemba” or “Gembutsu” which means “the real place”, so it is often literally defined as the act of seeing where the actual work happens.