As we see more companies moving to an agile way of working, we often have our clients requesting how to adapt this approach for their SAP SuccessFactors system support.

What is Agile

Agile is a time-boxed, iterative approach to software delivery that builds software solutions incrementally from the start of the project, instead of trying to deliver it all at once near the end.

Why Agile

We have seen many advantages for companies and teams using agile, including making decisions at the level of expertise, empowering people to learn, and experimenting with solutions that are co-developed with customers.

Cloud Based Implementation

We can confirm that the SAP Activate Methodology for SAP SuccessFactors solution implementations is built on the agile guiding principles.

The implementation roadmap is comprised of phases, deliverables and tasks and is in accordance with the SAP Activate Methodology and structure.

An important aspect in this methodology is that the implementation runs most effectively by breaking the project into smaller bits of user functionality and delivering them in short cycles called iterations.

SAP SuccessFactors Support Model

After the SAP SuccessFactors module solutions have been implemented, you must move forward to a support model. As said in the introduction of this article, many companies are moving to an agile way of working. Therefore, your business may want to adapt the agile approach to all your business processes and standards, including the support of your SAP SuccessFactors system.

We have had multiple clients where we introduced and enhanced the agile approach for their SAP SuccessFactors support.

As a leading practice, each cycle should start with a quarterly planning event in which the overall business top priorities will be discussed, presented and agreed upon. This will be the input for your sprint planning.

A sprint is a repeatable fixed time-box during which a ‘’done’’ product of the highest possible value is created.

Before starting any sprint, it is important to understand your team capacity for the upcoming period. As the sprint has a primary focus on system changes, it is important to include your ongoing maintenance (incidents and tasks) into your resource capacity calculations as well. Ongoing maintenance (also referred to as “run”) will impact your resource availability within a sprint. As a leading practice, you should also calculate a 20% margin in each sprint for unexpected circumstances and preparation for the next quarter.

Roles & Responsibilities
An agile team should have a minimum of five and a maximum of eleven team members.

Product Owner

Product owner is the client and decides the priorities. As a guiding principle, the sprint will start with user stories indicated as most important and will be placed on top of the backlog.

Development Team

The development team is composed of multidisciplinary members and organizes itself. They are responsible for analysis, design, development, test and documentation, and will make sure the change is completed by end of sprint so it can be implemented in the production instance.

Scrum Master

The scrum master guides and supports the team to ensure the correct scrum process is followed. The scrum master facilitates all meetings and locations along with hardware and software. This role is also responsible for protecting the development team so they won’t be approached by other parties requesting additional requirements.

Process and Meetings

Sprint Planning

The leading practice for each sprint is a two-week period. Each sprint should start with a planning meeting with a maximum time limit of 1 hour. The most important user stories are on top of the product backlog and will be taken into the sprint. The development team agrees to deliver the user stories by the end of the sprint. By the end of the sprint meeting, they will sit together and decide who will pick up which user stories. As a rule, user stories with highest priority should be assigned first.

Daily Stand-Up

Each daily stand-up should meet the following agreements:

• Each participant is prepared
• Each meeting starts on time
• Each meeting occurs daily at the same time and location
• The meeting will be no longer than 30 minutes
• Participants should physically stand-up which will accelerate the meeting duration
• All user stories will be projected on a screen
• Each team member will provide an update on:
  • Their assigned user stories
  • What did I do yesterday?
  • What will I do today?
  • Are there any impediments for which I need support or are important for other team members to be informed?

These updates should be succinctly. Details will not be discussed.

Review / Retrospective

The review is intended for lessons learned with the intention to improve the team. All team members are required to participate. This meeting will be facilitated by the scrum master after closing each sprint and can be scheduled just before the new sprint planning with a maximum time limit of 1 hour.

As input, each team member is expected to share their thoughts on the closing sprint:

• Stop: something that is not bringing value, or even worse, it is getting in the way
• Keep: something the team is doing well, and you recognize the value in it
• Start: a new idea, or something you have seen working before that you would like to bring to the table

The input can be clustered into topics with each team member being allowed to nominate 3 points. Topics with most points will be selected as an action and assigned to a team member who is responsible for working out the specific action point.

One of the most important aspects of a retrospective is also one of the most challenging: participants should be able to speak freely towards a solution-based culture but should understand no personal debt is allowed towards others for any delay.

Backlog Refinement

User stories on the backlog should be created meeting specific requirements. Therefore, it is key to understand the business requirements by utilizing the product owner.

Stories which are still vague such as ‘’develop user interface’’ or ‘’management reports’’ can be divided in smaller topics, including but not limited to ‘’user interfaces for different groups of users,’’ ‘’financial reports’’ or ‘’HR reports.’’

This will create the opportunity to think about the best solution(s), resulting in a more detailed solution estimate. It will also provide the option to register acceptance criteria which produces acceptance tests. Perhaps additional analysis is required which are called ‘’spikes,’’ in other words, more time is required to investigate the change request. The backlog usually takes place towards the end of the current sprint. It is time-boxed, usually to no more than 2 hours for a two-week sprint. Teams can also choose a format of four meetings with a maximum of 30 minutes per meeting. Participants for this meeting include the product owner and analysts, and it is facilitated by the scrum master.

The process is intended for having high quality user stories on the backlog which are ready to be picked up for the next sprint. As soon user stories are defined, the participants should be able to award points in number of 0, 1, 3, 5, 8, 13, 20, 40 and 100. As a team you, should agree upon the definition of points in order of time duration, but as a leading practice, new teams could start with providing points in line with the estimated hours. For example, a user story (change) which is estimated on three hours of work should be assigned three points. As some numbers are not used, such as the number two, you should work towards one or three points.

Tooling

User stories should be tracked in a ticketing system like ServiceNow, JIRA, etc. A user story can have the following status:

• Backlog
• Spike
• Prioritized and Defined
• Sprint

As long the sprint hasn’t started, user stories on the backlog will not be assigned to an individual resource yet. The individual assignment is an activity of the sprint planning itself, and in most cases, the closing topic on the agenda.

User Story

A user story is an informal, natural language description of one or more features of a software system. User stories are often written from the perspective of an end user or user of a system. A user story should meet the following format:

• Format > As a (role/user), I want to (function/action), so (objective/value for role/user)
• Discuss and capture any user stories details
• Create acceptance criteria and a Definition of Done

See below an example of a sprint rhythm:

Process of Implementing SAP SuccessFactors Changes

When implementing SAP SuccessFactors changes in the production instance, we always recommend some of the leading practices mentioned below. This should result in properly documented changes and a controlled implementation behavior:

• All requested changes must be registered in a ticketing tool. Businesses should understand and accept this requirement before requesting any change.
• Requests to other teams within a specific user story should be registered as a task in the ticketing system and then assigned to that other team.
• All SAP SuccessFactors changes should be configured first in the development instance before moving to the acceptance instance, and finally implementing in the production instance.
• Responsibilities within the team should be clear when it comes to configuration, imports, analysis (root causes), testing (Four Eyes Principle) and user communication.
• In each email communication, the change number and topic should be included to avoid any mistakes.
• Each change requires a configuration test. Pending the type of change, this can be a simple test including a screenshot only, or extensive testing for more complex changes.
• Each change requires a user acceptance test.
• All documentation related to the change should be saved. Most ticketing tools will offer the functionality to upload documents.
• Each change should be reviewed by another team member before implementing in the production instance. Internal and external integration and future impact on other functionality are important aspects in this review.
• Where possible, changes should be released on a fixed day and always communicated to the business when released in the production instance.