Soon after publishing my
earlier blog posting on Agile & Release Management, I was able to apply what I had learned on another type of SAP project. This project was to help an automotive client assess the fit of SAP S/4HANA to their business processes, and identify Roadmap options for an implementation and global rollout.
The client had done some work comparing different software products and had seen some standard product demonstrations from an SAP Implementation Partner. Our project was to quickly stand up an SAP S/4HANA demo system and showcase specific capabilities that would address key business pain points, while also providing answers to some specific questions. The client also wanted to move beyond the sales materials, and see how their business processes would look on an SAP S/4HANA system.
In retrospect, I can see that there were different levels of experience with using Agile methodology among the client and SAP team members. I think this is typically the case on any project these days. I, myself, have gotten more experience on my current project, which I will write about in a forthcoming blog post. Also, there was another key challenge at the outset - determining which SAP Best Practices solution to leverage as a foundation. I will leave that topic to another discussion...
What elements of the approach and methodology could be considered to have been Agile?
- All team members worked together to define an overall backlog. Work was broken down and organized into Sprints
- Sprint scope was adapted / groomed along the way, taking into account progress, changes and additional input
What key elements of an Agile methodology were missing?
- There was no scrum master, and no daily stand-ups
- The tools used to track work were not aligned to Agile
- The client team members were not required to commit to specific tasks or deliverables
What worked?
- The sprints set a common cadence for key client personnel to review progress and provide input
- The deliverables were adapted along the way as the client saw more clearly what could be done. The team was also able to articulate the benefit
What did we learn to do better next time?
- A scrum master would have helped to get the busy client staff to commit to and deliver their input more regularly
- A more formal definition of roles and responsibilities would have led to a more efficient use of everyone's time
- Having tools aligned with an Agile methodology may have made it easier to organize the work. The team was sometimes working across different timezones and in different languages. While not Agile-specific, collaboration tools such as MicroSoft Teams or Google Docs allow different team members to build on each other's work. If you make everyone's work visible, you avoid duplication of effort. It also makes meetings more efficient, as long as everyone is doing his/her homework.
In conclusion, this project validated that the Agile philosophy of refining the work periodically makes sense for a short-term, POC ("Proof of Concept") Roadmap project. This is because the goals change or become more clear as everyone learns from each other and the work is completed. Working as a team to build the backlog and plan the work into sprints made sure that all angles were being covered, and that the various tasks were in alignment. Frequent communication and sharing of deliverables is also key to making sure expectations are being met.
