9 critical success factors in applying agile to S/4HANA programs

The concept of agile development can be traced back to the days when software development started. However, it started to get merged into a specific development approach with the start of the web development in early 2000’s, primarily due to demand to speed up the time to market and have a working “live” solution fast.

In the ERP world, the adoption has taken a slower route, primarily due to the size and the highly integrated and complex nature of the solution. Hence the term hybrid agile was created to focus on the “build” or “realization” phase of the project lifecycle.

In this blog, I discuss how organizations can transform solution delivery to a product centric agile approach and share critical success factors observed when applying the Scaled Agile Framework (SAFe) to highly complex S/4HANA transformation programs.

DON’T SKIP INTRO

Currently, everyone wants to get everything now. However, moving an organization to agile takes investment of time and structured preparation. Project initiation is a key step to ensure the entire project team defines and aligns on the new ways of working and has the same basic understanding of agile. Certification of key project members from integrator, client and other partners is required. This “transition” phase usually takes from 2 to 8 weeks, depending on the size of the project organization. At the end of this stage, all the prerequisites to kick off the project must be met. Some of these are: agile based project organization, definition of R&R, program cadence, tool setup and training, and a central organization that will monitor the progress. This takes us to the second factor.

MENTORING IS NOT OPTIONAL

Agile mentoring is not an initiation only activity. It takes 3 to 4 increments to perfect the agile application and there is a central agile coaching team needed to mentor the team, coordinate central activities, collect feedback, observe, recommend, and apply improvements. Therefore, the mentoring team needs to first set up the initial agile organization and then move to a different role of monitoring: providing ad-hoc feedback, leading critical ceremonies and providing improvement recommendations to the leadership team. Once these improvements are agreed, a quick implementation is necessary as well as explaining it to the team.

INSTIL PRODUCT MINDSET FROM THE START

Backlog management is a critical area for any implementation, and it involves negotiation between the IT and business departments. An approach based on the business value prioritization, such as Infosys VRM, must be used when discussing which user stories are making it to the top of the list and finding a “home” sprint. From a business perspective, a project is the only opportunity to get the requirements done; if these are not delivered in that project, there is no guarantee that there will be another. However, in agile, this is not the case and it is extremely important to instil a product vs. project mindset to all stakeholders. The requirements are captured as part of the user stories, and once the site sees that there is a continuous release calendar from the agile delivery organization, they do not insist that everything is completed in one go. There are other opportunities to deliver the user stories and adapt new features after the first project goes live.

DON’T RUSH “AGILE”

Agile doesn’t mean fast. It does help to achieve faster results while being flexible in delivering software. However, the move to an agile project organization takes time and multiple iterations. The team, and especially the leadership, must not be disheartened when the first increments do not produce the desired outcome. Program increment planning takes anything between 2.5 to 4 days to fully go through the business objectives, backlog, dependencies, risk analysis and an approval of a sprint plan. So, don’t interfere with the “playback speed”: be patient and believe in incremental gains.

SUPPLY AND DEMAND

Sprint planning requires a thorough preparation in terms of the “supply” and “demand” side of the equation. On the supply side, the capacity of the business and IT teams needs to be discussed in advance and agreed for the duration of the program increment. On the demand side, there must be a clear list of user stories in the backlog with good quality information. User stories need to be written following the SAFe agile principles i.e., from the lens of the user. Efforts required from the business and IT teams should be estimated before PI planning and aligned within the team. Different types of user stories have different sub-tasks and resource needs. For example, a config US will have functional resource needs, vs. a development US with tech resource needs. There are also enabler user stories to manage the dependencies between streams.

INVEST IN RIGHT TOOLS

The Atlassian suite of tools (Jira, Confluence) is the market leader when it comes to enterprise agile planning. There are, however, other tools in the market that are very good and fit for purpose. Regardless of the tools selected, there is an investment up front to fully define how these tools will be used for what purpose and by whom. This is part of the “initiation” phase; however, it needs to be fine-tuned as you progress in your journey to become an agile delivery organization. Some configurations will be required specific to your organization and how you define your releases. A lot of out of the box dashboards can be used as templates or as is to make the reporting consistent. My experience is that the right tools make life so much easier, as they enable a faster adoption of the new agile concepts that the organization is in the process of mastering.

FIND YOUR “JUST RIGHT”

SAFe Agile provides a framework and each organization needs to define the optimal application. According to our experience, a program increment takes anything from 1.5 to 3 months, within which a minimum of 3 sprints should be delivered. Hence, a program increment can take 3 sprints of 2 weeks, 6 sprints of 2 weeks or 4 sprints of 3 weeks. The right number is dependent on the organization, and we find the optimal number of sprints and duration of each sprint based on our experience. We then finetune based on each sprint and PI outcome. It is best practice to have “committed” and “stretch” targets for each sprint to see the performance of the team and their reaction to these commitments and stretch objectives.

KNOW WHEN TO BRING IT ALL TOGETHER

In SAP transformation programs, there must be a point where the solution that will go live needs to be tested in an integrated manner. In agile, it is good practice to test an epic or one or many features in an integrated manner during the first integration test. However, there is a need for a second test where entire solution comes together and is tested in an integrated manner. This is critical especially in projects where the solution is encompassing multiple systems and end to end processes. Within the testing phase, a “testing sprint” can be defined to slice and dice scope. There is an opportunity for application of agile in testing phase to a degree.

MUST HAVE IN ANY TRANSFORMATION: LEADERSHIP COMMITMENT

Finally, commitment from the leadership is critical. Moving to an agile based delivery model is a major transformation and requires intense change management efforts. It is important to have regular touchpoints and surveys to understand the friction points and encourage adoption.

At Infosys Consulting, we are advisors and implementation partners of large enterprises in their transformation to agile organization. We have successfully transformed several our client’s delivery models to an agile based framework and provided services from mentoring to full SAFe Agile based S/4HANA implementations. To hear from our experience and expertise, please do not hesitate to contact us.