The Agile Manifesto celebrates its 20thanniversary this year. In addition, the Project Management Institute has been offering the Agile Practitioner Certification for over 10 years. But how are we using Agile in big transformation programs? Why do we keep struggling implementing big SAP ERP transformations using Agile?
In this blog post, we want to explore some key challenges arising from running Agile in large-scale SAP ERP implementations, and provide some insight on recommended work-around, remediation and mitigation. If you would like to know more about our experience in waterfall and agile ERP transformations, contact us.
“Running Agile” (merely using agile practices) is different from “being Agile” (having an agile mindset)
Agile is not merely a methodology; it is a set of principles. However, when pulling together a team for an ERP transformation, enterprises usually seek people with rich experience and, hence, acquire substantial expertise in waterfall implementations. In order to avoid old habits and sustain the mindset change, it is important to follow an agile framework and follow it strictly. The pre-defined structure of each scrum ceremony keeps the team on track and help develop a truly agile mindset.
It requires heavy effort and continuous repetition to develop new habits. Asking everyone in the team to answer the same three questions (What did you accomplish and can be moved to done, what are you working on (including focus of the week), anything in your way or keeping you from completing your tasks) in a daily huddle may seem pointless at first but can rapidly deliver team efficiencies. If Agile seems foreign to your organization, we recommend choosing the Agile framework that works best for the organization, and follow it as strictly as possible, with little adjustments.
- Get an agile coach if needed;
- Get enough people certified to act as scrum masters;
- Make sure everyone understands the objective and importance of each of the scrum ceremonies.
The SAFe® implementation roadmap puts the training in agile at the core of its framework. More than a commercial model, selling certifications, we believe they truly experienced and understood how difficult a change in mindset is.
Scaling agile is easier said than done and lean portfolio management is still a challenge
The concept of the agile release train is quite simple and can provide enormous benefits for larger implementations. It main purpose it to:
- Align agile teams to a common mission;
- Define a solution deployment flow.
I quite like it how Dean Leffingwell explains what a release train is. He defines it as a fractal above the sprint: an agile sprint has a common and simple pattern: plan, commit, execute, demo and adapt (retrospect); the release train has more teams and longer iterations (super sprints, composed of multiple, aligned team sprints). The pattern is exactly the same, but it is at the next level of program scale.
While there are different frameworks to scale agile (Nexus, SAFe®, etc.) they follow this same release train principle.
From our experience, applying the agile principles at the team level is relatively easy. Following the release train principle at program level, requires more practice but results in better planning and alignment between projects.
The higher we go in the hierarchy ladder, the more difficult it is to live the agile principles and it is at portfolio management where we see most challenges. The agile release train concept does not apply for portfolio management, where a more top-down, strategy driven approach should be taken.
- The big-upfront, annual planning and budgeting, with funds allocated to specific projects is still the norm instead of value stream based with guardrails.
- We continue to see detailed business cases with speculative ROIs instead of MVP and business outcome hypothesis with agile forecasting.
- It is still common practice to govern projects by phase gates and waterfall milestones instead of milestones based on working solutions (with incremental epics and features).
We know that the effort that goes into creating a high-level plan is enormous. But we need to keep in mind that responding to the change is more important than following the plan.
One framework does not fit all
SAP has tried to develop the best methodology for the implementation of their products – SAP Activate. This methodology has evolved over time from their waterfall framework and it is very specific for SAP ERP implementations. It has prescriptive tasks and project plans and incorporates useful accelerators, templates and how-to documents, for example, to run Fit-to-standard workshops. But it is somehow difficult to recognize the scrum ceremonies and the agile principles in it. On the other hand, SAP Activate will always be different from their client’s preferred methodology, as the client has to deal with more than SAP ERP and the methodology is not generic enough to apply to any project.
As an enterprise, it is important to have some coherence in the adopted methodologies, although it is not uncommon to follow different frameworks from one project to the other, even within the same program. Following different frameworks does not facilitate the alignment of projects’ objectives and dependencies. This is how companies often end up with hybrid methodologies, to allow for some freedom to use different agile frameworks while maintaining integration points (usually the traditional stage gates).
The SAP Activate methodology has been evolving with the SAP S/4HANA cloud implementations in mind, and we will watch with excitement the maturation over the next years.
Validation and Agile
Computer System Validation (CSV) requirements are often pointed as a reason to deviate from an agile framework and go for a hybrid approach. In fact, to our experience and knowledge, there is no agile framework incorporating the CSV requirements in a prescriptive way. Nonetheless, it is possible to fully follow the agile principles in a CSV environment. Each Scrum iteration can be considered as a mini waterfall project or a mini V-model, and consists of planning, development, testing, verification and validation. The documentation and traceability can be introduced as an activity in each sprint.
If we align early on, with Quality Assurance and CSV teams, on how documentation will be created, ideally leveraging the sprint artifacts, on the different environments that will be used for validation and if we include the completion of the required documentation in our definition of done, we are prepared for success.
Creating the documentation as part of the sprint does not mean one should replace the demos at the end of the sprint by a Functional specification review: “Working software over comprehensive documentation” still applies.
CSV documentation, not only “code”, becomes one of the work artifacts and output of the sprint. Quality should be built in as much as possible within the sprint work. However, to fully cover the CSV requirements and to involve business users in real or simulated deployment scenarios, we recommend dedicating enough time specifically for UAT before each release of the solution to the end-users.
Agile Teams with Offshore CoEs
One of the fundamentals across agile frameworks is the team work: “Individuals and interactions over processes and tools”. An agile team is by definition a cross-functional group of about 10 individuals who can define, build, test, and deliver a working solution in short iterations. The team should have all the people and skills needed to deliver value across traditional organizational silos, largely eliminating handoffs and delays.
However, when we talk about large, global and complex ERP transformations, the company undergoing the transformation often subcontracts expertise and has to deal with a distributed agile software development setup. We are often dealing with partnerships between multiple large enterprises (the client, SAP and an implementation partner). The complexity of the procurement procedures that need to be followed are usually proportional to the complexity of the transformation itself. It is crucial in this situations to remember the agile value “Customer collaboration over contract negotiation”.
A distributed setup, with offshore centers of expertise for the build, or for test automation, for example, although not an ideal scenario, is a reality that we have successfully experienced.
As I am about to write the final remarks for this blog post, I realize that we touched each of the values in the agile manifesto (and some more). It shows me how far we have travelled in the agile mindset journey but also how challenging the journey ahead still is.
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more.”Agile Manifesto