6 challenges of agile at scale for ERP

Agile has been around for a long time by IT standards and has proven to be successful for many companies.  As companies have evolved and progressed through the pioneering stage of agile, there has been a tendency to take on larger and larger efforts. There have even been inroads made in the application of agile to support the deployment of ERP (projects that are notoriously complex with a significant amount of integration).  But the benefits of agile that were derived from smaller-scale efforts have not naturally transferred to agile projects at scale.

Through experience and research, I have identified 6 challenges that must be overcome to effectively execute agile for an ERP implementation and actions to address them.

1. Key decision governance 

An significant factor of a successful agile project is a small, committed team of collocated, highly skilled members empowered to make key decisions throughout the project.  As a project scales, cross-team decision volume increases and so does the number of “wicked messy” decisions there are to make. These decisions will typically involve organization winners and losers.  It is more difficult and time-consuming to ensure all teams are aligned when there are more teams and consequences involved.

Stakeholder scope also increases which can further lengthen the time it takes to gain consensus.  The agile mindset is not conducive to making large, cross-functional decisions so this becomes more challenging as the project scales.

To address this point, Release Train Engineers need to take full accountability in the identification of key decisions, early and frequent socialization, and establish a decision strategy that will enable these key decisions to be made in a timely fashion.

2. Backlog management

In an agile at scale project, backlog management is more difficult than in a small development project because the backlog consists of many activities not directly related to the development of software (i.e., data team support, training support, deployment activities, etc.).

Management of integrated testing can also be challenging since much of ERP testing requires the involvement of multiple teams. A second dimension to backlog management complexity is that many of the items in the backlog are non-discretionary (particularly in ERP) and are a direct requirement of other teams. These two dimensions place a much greater demand on the product owner to understand the scope of the entire program to effectively groom a backlog that is properly sequenced and synchronized with the other teams.

To address this issue, development of the end-to-end testing strategy must take place in the early portion of the program.   By establishing this strategy, product owners can develop a better understanding of the dependencies and precedents that are required to prioritize backlog. 

3. Synchronizing & aligning scrum teams

Agile projects  depend heavily on the calibration of velocity across scrum teams. When there is misalignment in communication and performance across all teams, you will end up with an idle resource team.  All teams must cross the finish line at the same time with the same level of completeness.

To achieve this, there must be complete buy-in of the agile mindset from all members and a clear definition of “done” across teams.  Teams operating on varying definitions of done could extend the time spent on end-to-end testing.

To enable this alignment, Release Train Engineers must perform two critical functions: 

1. Confirm that cross team dependencies are recognized and logged as part of individual team backlogs and sprint plans.
2. Monitor velocity and adjust sprint team capacity as required to align team’s delivery on an anticipated delivery date.

4. Integration of part-time and shared resources

While there will be full-time members who are completely committed to the project, they will likely have to share their time across multiple teams.  Effectively allocating their time will depend on keeping them aligned with where the other teams in the project are.

Part-time resources outside of scrum team participation will have to be managed as well.  For example, the person in charge of auditing may only be devoting 10% of their time to the agile project overall.  The program manager will have to help coordinate their time to ensure their availability and commitment to the agile project when auditing is needed.

Resource forecasts are a good tool to address this point.  Release Train Engineers need to maintain a full resource demand forecast across the programs and regularly update all providing areas.   Product owners will gain favor with these external resource providers by managing backlog to align with forecast for demand. 

5. Required bureaucracy for large projects

To keep the project on track, it is typical that the higher-ups are involved in formal Stage Gate Reviews and that they have what they need to support the review. Typically, in large-scale projects, more output and documentation are required to get full support from review board members. A paradox with implementing agile is that there will be more focus on incremental development throughout the project and less on documentation in general.  This complicates the team’s ability to provide board-level transparency of spend and risk management.

To address this point, product owners are advised to develop an initial senior management presentation and then update this material at the conclusion of each sprint as part of the retrospective.    Board and senior management presentations should not be an event but rather the delivery of current state and projections of future state.

6. Vendor accountability & performance

In agile projects, it is more difficult to define risk sharing between the company and vendor. Contracts for large-scale programs tend to be waterfall or deliverable-based, with penalties or incentives driving cost and schedule performance which enables companies to hold vendors accountable for delivering full scope. By contrast, agile assumes cost and time is fixed when scope is variable.  This situation flies in the face of the standard belief that much of the scope of ERP is not flexible.  One area that this complicates is defining and resolving the concept of warranty support.  This is another reason that everyone in the project, on both client and vendor sides, must have the same definition of “done” for each sprint.

New contracting structures have emerged in recent years that are focused on this definition of done with the application of incentives and penalties in the achievement of the specific definition.   Teams that are considering agile at scale to address ERP should seek out experts in this area to learn about these new structures.