Over the past three years, we have been engaged with a multinational client to deliver agile training and coaching to one of the biggest SAP deployments in the world. In addition to the challenges presented in applying agile principles and practices to a waterfall deployment, it also involved:
- Working across geographical boundaries, from the USA, across the UK and mainland Europe out to India
- Dealing with multiple time zones
- Collaborating with different augmentation partners
- Supporting over 400 people
- Adapting how we work because of the COVID-19 pandemic
Reflecting on our experience, we learnt many things we would do again, and a few things we would do differently to increase the chance of being successful when using an agile approach for a traditional, waterfall project, like a SAP deployment.
Key Insights from Using Agile In SAP Deployments
Agile Contracting with Suppliers
To deliver a deployment of such magnitude, organisations often augment the knowledge and skills in their internal teams by hiring an augmentation partner to support them.
To have a unified mindset, principles and practices, it is essential to stipulate an agile approach. Be clear in the contracting on issues including:
- What are your (the customer) responsibilities? E.g. training your people in agile
- What is your shared responsibility? E.g. defining success measures
- What is your partner’s responsibility? E.g. defining the preliminary scope and being transparent about people and resource availability
Organise Around Value
It’s quite often the case in SAP deployments that work is handed off from functional team to functional team, from “the Business” to Development, to Test, Deploy and so on. When setting up your teams, consider leveraging Value Streams and Value Flows to influence your team design.
In SAP deployments, Value Streams and Value Flows represent how value is generated by the organisation. Value streams can be broken down into sub-streams and value flows. Value flows can be broken down into sub-flows which are used to drill down into the capabilities and processes that the organization requires to operate.
Some of the Value Streams in SAP, for example, Order to Cash or Make to Deploy may be so complex that you require tens of people to execute. These are great examples to break down the teams into smaller, more agile Scrum teams.
These sub-streams and flows provide some organic boundaries for you to form cross-functional teams that deliver value. Using the common roles and responsibilities of a Scrum team, you can:
- Look to a Sub-flow Lead to be the Product Owner
- Support them with a Scrum Master
- Build a team around them capable of delivering WRICEFs end to end.
Once you’ve organised around value, it is critical to ensure that if you decide to use Scrum, you do good Scrum. Hire a coach to support your teams to ensure that they are mastering the basics like healthy backlogs, making sure they are a stable team, and that they are delivering often.
Add Predictability with Synchronization and Alignment
At the peak of the deployment, we had over 400 people across tens of teams. To ensure alignment and predictability, we used the Scaled Agile Framework (SAFe®).
Using SAFe® gave us the following benefits:
- Satisfied the needs of a more traditional deployment – One of the goals of implementing SAP is to reduce variability through standardization so any changes to scope must be clearly reasoned and defined. Using Program Increments and setting a planning horizon of 12 weeks gave us predictability over our planning and delivery but also allowed enough flexibility to be responsive to changes in the environment and in our progress.
- Total alignment with Planning Increment (PI) Planning – We conducted our first 2 PI Planning Events in person before the COVID-19 pandemic forced us online. PI Planning was powerful for the teams when planning to not only collaborate on dependencies but also to visualise the complexity of the deployment.
By being intentional with our use and application of a framework, we were able to maximise its benefits without being overly prescriptive.
Don’t Stop Sprinting
Again, traditional SAP deployments tend to follow a typical waterfall pattern, consisting of; a development phase, configuration phase, SIT phase, UAT phase and then deployment.
Many organisations think that doing Scrum and “sprinting” is only valuable during development. This couldn’t be further from the truth! Just because sprinting stops, doesn’t mean that sprinting should stop – continue to leverage the skills and knowledge built up using Scrum by continuing to use short, iterative feedback loops after the final “development” sprint.
Data-Driven Deployment
Like popular software development strategies such as Test-Driven Development, start with the end in mind. Identify end-to-end scenarios with fully defined narratives, including the data required at the start of a Program Increment.
Use these scenarios to help prioritise, identify scope, identify data and add focus on your end users to build quality in. These scenarios can be similar in size to an Epic in SAFe® and broken down into Features (which may resemble WRICEFs) and then into User Stories by the teams for execution.
Do not fall into the trap of “chasing the numbers” (e.g. number of WRICEFs or User Stories closed) and focus on chasing the end-user outcomes.
When in Doubt, Refer to Agile Principles
Finally, when you inevitably hit a roadblock when using Agile with SAP, the best way to test your solution is to refer to the Agile Principles and ask yourself, “if we do this, is it in contradiction with any of the principles? If it is, what is the cost and are we prepared to pay that?”.
The approaches outlined in this post are applicable not only to SAP deployments, but to any kind of traditional or hybrid project that you may be looking to add some agility to.
For more information on how our agile services can help you with a traditional or hybrid deployment, get in touch to discuss our bespoke Agile consultancy service.
