Top Five Lessons Learned From Real Agile Delivery Cases

Garrick Keatts

Companies are adopting new business suites to help them achieve many strategic priorities for their business and IT operations. According to a recent survey from Frost & Sullivan, these strategic priorities include:

  • Cost reduction (cited by 76% of survey respondents)
  • Better positioning the company to leverage new technologies for growth (cited by 61%)
  • Delivering services and applications faster (69%)
  • Reducing the hardware and software maintenance burden (64%)

An agile deployment is the best way to start drawing value from a new business suite quickly and reduce implementation risk. A business suite migration is a particularly good fit for agile methods because new capabilities are consistently being added to the solution. An agile deployment can help make sure you’re taking advantage of the latest innovations from each new software release. As a result, you can maximize the return on your business suite investment, and keep up with changing business requirements as they arise.

Based on IBM’s experience helping clients execute their business suite migrations, we’ve learned a number of lessons about what’s required to ensure a successful agile deployment.

Lessons learned from agile delivery cases

1. Plan sprints, not phases

Far too often, agile teams fall into a pattern of planning their work according to phases in the development lifecycle. This can cause problems, because those workloads won’t always align to the sprints. The only way to make sure the right work happens at the right time is to focus on planning the sprints first, and then aligning phases accordingly.

2. Allow for increased overhead based on tool management

Generally speaking, tracking workflows in agile deployment projects will require more effort than in projects using waterfall methods. In addition, certain agile tracking tools may require more overhead than others.

For instance, some tools require project managers to manually set tasks and hours planned per task. This allows them to make sure all team members have tasks assigned to them, and that the right tasks are being assigned at the right time. Managing workflows this way requires more time and effort than simply moving sticky notes around on a whiteboard. It’s important to understand and account for this fact when planning your business suite deployment.

3. Encourage collaboration between onshore and offshore developers

In waterfall project management, the separation between onshore and offshore developers is well established: Typically, the onshore team will write the functional specifications, and then hand them off to the offshore team to execute. In contrast, agile project management requires collaboration between onshore and offshore developers, with rapid back and forth throughout the sprints and project.

This means you may have to adjust your thought process and hire additional on-site development resources. Even if you still do the majority of your coding work offshore, having onshore developers available when you need them can help ensure that your team is able to meet the specific needs of the project quickly.

4. Ensure clarity and accuracy of story points and acceptance criteria

If all team members don’t have a complete and accurate understanding of what they’re expected to accomplish during a sprint, and how much time and effort it should take to accomplish it, then it should come as no surprise when the sprint fails to meet expectations.

When acceptance criteria are clear and accurate heading into the sprint, team members will be empowered to meet those criteria. In addition, accurate story points ensure that team members won’t end up with too much or not enough work assigned during the sprint period.

5. Empower scrum teams to work autonomously

At the end of the day, the team members themselves are the best judges of what they can and can’t accomplish during the course of a sprint. Rather than working against the entire backlog at the direction of the product owner, allowing the team to determine their own work priorities ensures that expectations are realistic going in to the sprints.

Learn more

For a deeper look at the ideas presented in this post, register to attend Think 2019, the flagship IBM technical conference. There, you can attend sessions featuring experts in SAP S/4HANA and agile deployment methods.

In addition, an IBM impact assessment for SAP S/4HANA can help you understand the end-to-end impact an SAP S/4HANA migration could have on your data, custom code, interfaces, and business processes. Register for an IBM HANA Impact assessment to start your migration today.

This article was written in collaboration with:

  • Steve Parks, Associate Partner, Global Business Services, IBM
  • Clay Sheriff, Partner, Global Business Services, IBM

Garrick Keatts

About Garrick Keatts

Garrick Keatts is the SAP S/4HANA Hypergrowth Leader for IBM Global Business Services.