As mentioned in my previous blog post, I am now getting a lot more first-hand experience with the application of Agile methodology concepts to a very large SAP S/4HANA implementation project. Our client and the lead implementation partner, Accenture, both have been actively using Agile methods and tools on many different types of projects. The size and scale of the project presents many challenges, and there is strong pressure to ensure that the promised go-live date is kept.
For this posting, I interviewed one of my counterparts from Accenture, Swapna Pavarala. She is a Senior Manager from the Supply Chain domain of Technology Consulting, and track lead on this project. She brings a wealth of SAP experience using Agile and waterfall-type methodologies. She has worked in various industries not only as track lead, but also as integration lead, cutover lead, and data lead. We discussed our experiences on the project, and the challenges with applying Agile concepts to such a large scope. Since all major business processes are moving from an ECC to an SAP S/4HANA system, it is not feasible to move small increments of the solution to production. However, all of the work leading up to go-live is being managed with a clear Sprint cadence, daily stand-ups, as well as regular backlog grooming and retrospectives. Deliverables and tasks ("stories") are organized and tracked using an Agile-based toolset.
Marcel: How would you describe the methodology that we are using on the project? Is it really Agile?
Swapna: We are working in a "Wagile" model, that is, a combination of Waterfall and Agile. We have a definite timeline to meet, no matter what. At the same time, Agile gives you the flexibility to update the requirements as you build you learn more. The Agile methodology has you do design, development, testing and then push that to production. Now, forget about that last step, instead we still "sprint' out the work, take it through UAT (User Acceptance Testing), and get sign-off.
Marcel: And what implications are there to blending Waterfall and Agile?
Swapna: A big challenge is that until you fit all the pieces together, you will not have uncovered many things that will cause your design to change. With two week sprints and pressure to complete, we are often taking things through build and test, and only communicating the final result when it's already finished. If my changes impact somebody else, they are left to remediate it after that fact, or I have rework on my part.
With an Agile methodology, it is also critical that requirements are made very explicit and are well-documented. You cannot just say at a high level we are leaving a certain process as-is, because that could be interpreted differently by different teams. Then, as one team is building it's processes, it may make some changes to the as-is, but not realize the impacts it will have on another team.
The cross-functional dependencies are key. It is very important to understand what other teams are doing and how that is going to impact your work. Although Key Design Decisions are made and presented jointly in the design phase, Agile allows flexibility to adjust as you go through the detailed design. However, that is often not being communicated across tracks. You must ensure that these changes are socialized and other teams catch up.
Marcel: That presents another challenge, though. How can you balance making changes to the plan midstream, ensuring all impacts are identified and accommodated, and having to meet fixed deadlines?
Swapna: Yes, that is a challenge, and whether you use Agile or Waterfall, there will always be competing objectives - stick to the initial decisions or try to meet all additional business requirements as they are discovered. With Agile, the intention is to remain flexible to change, but change doesn't come for free. We are also budget restricted and capacity restricted and that doesn't go well with Agile.
And it is most challenging when we are working with new functionality. That is where we need to allow for flexibility, because we have less business expertise to rely on. We have to plan with limited understanding, and we have to rank our requirements in terms of must have, nice to have, etc. In order to meet time and cost restraints, the business must be willing to accept workarounds, at least for a period of time. Beyond the sprint schedule and Agile tools, a big part of Agile is how you manage requirements. For complex business requirements, there always has to be a Plan B.
Marcel: That's very true. In order to get something live, you should try to stick to a core scope for the baseline that should be less subject to change for the initial go-live, or first release. Then begin to work with true incremental sprints for the rest.
Now, another aspect of our current project that seems contradictory is that we have a long test phase with a long freeze. With such a large scope, the long freeze is meant to reduce risk to solution integrity. How is that Agile?
Swapna: That is not Agile, you can't have a long freeze and say you are Agile. What happens before the freeze is that the number of change requests starts to increase as people see the window closing, and that increases the risk that they have not been fully reviewed for cross-functional impact. The change request process needs to include a step to approve larger change requests only for analysis. The analysis means those cross-functional discussions.
Marcel: Good point. You need to take the time to assess the impact on other processes, and gather the needed input from other teams.And the body that is reviewing change requests needs to have a clear and common understanding of the core scope, and what areas are most important.
Swapna: And that brings me back to how important requirements management is to Agile. As you move forward, there needs to be a strict assessment of whether something is a new requirement, or if it is something needed for an existing requirement. Once you are building the solution, you cannot bring in brand new requirements. Instead, you may have a decision that was made earlier, and now you see you need this new development to support that. In the later stages of the project, this is the only type of thing that should be approved. And, as you said, only approve work that is critical to your scope.
Marcel: So overall, this becomes a balancing act between course correcting as business requirements are better understood and priorities change, while also keeping everything aligned, within budget and on-time. With a large scope comes a large team, making cross-functional alignment more important but also more time consuming.
Agile principles help to keep a solution relevant, but no methodology has all the answers. We still need skilled and experienced project leadership to find the right balance between flexibility and risk reduction.
Thanks, Swapna for your insights and interesting discussion.
Swapna: Sure, let's catch up again on these topics in a few months. It will be interesting to see how things evolve during integration testing.
