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 our experience and research, we have identified six challenges that must be overcome to effectively execute agile for an ERP implementation.
- Key Decision Governance
A key 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. - 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. - Synchronizing / Aligning Scrum Teams
Agile projects heavily depend on the calibration of velocity across scrum teams. When there is a 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. - 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 the other teams in the project. 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 per cent 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. - 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. - 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. On the contrary, 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. The lack of documentation makes benchmarking vendor performance a challenge. Over time, the more traditional waterfall methods have provided opportunities for clients and vendors to establish measurable standards of performance and productivity. Agile is broadly assumed to provide productivity improvements but agile at scale still falls short in providing clients with a clear-cut way to quantify and measure the performance of vendors.
About the author
John Belden is the Project Execution Advisory Services Practice Leader at UpperEdge. The practice is centered on risk mitigation with a focus on the assurance of operational continuity and harvesting the expected returns of large IT-enabled transformations.
Belden will be speaking at the 2018 CIO Peer Forum in Vancouver.
