Agile has been around for a long time by IT standards and has proven to be successful for many companies. \u00a0As 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). \u00a0But the benefits of agile that were derived from smaller-scale efforts have not naturally transferred to agile projects at scale.\nThrough 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.\n[ Learn why IT projects still fail at an alarming rate, beware the 10 project management myths to avoid, and find out how to pick the right project management methodology for your team. | Get the latest project management advice by signing up for our CIO newsletters. ]\n1. Key decision governance\u00a0\nAn significant factor of a successful agile project is a small, committed team of collocated, highly skilled members\u00a0empowered\u00a0to make key decisions throughout the project.\u00a0 As a project\u00a0scales, cross-team decision volume increases and so does the number of \u201cwicked messy\u201d decisions\u00a0there\u00a0are\u00a0to make.\u00a0These decisions\u00a0will\u00a0typically involve organization winners and losers.\u00a0 It is\u00a0more\u00a0difficult and time-consuming\u00a0to ensure all teams are aligned when there are more\u00a0teams and consequences\u00a0involved.\nStakeholder scope also increases which can\u00a0further\u00a0lengthen the time it takes to gain consensus.\u00a0 The agile mindset is not conducive to making large, cross-functional decisions\u00a0so this becomes more challenging\u00a0as the project scales.\nTo 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.\n2. Backlog management\nIn an agile at scale project,\u00a0backlog management is more difficult than in a small development project\u00a0because the\u00a0backlog consists of many activities not directly related to the development of software (i.e.,\u00a0data team support, training support, deployment activities, etc.).\nManagement of integrated\u00a0testing\u00a0can also be\u00a0challenging\u00a0since\u00a0much 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.\nTo address this issue, development of the end-to-end testing strategy must take place in the early portion of the program.\u00a0\u00a0 By establishing this strategy, product owners can develop a better understanding of the dependencies and precedents that are required to prioritize backlog.\u00a0\n3. Synchronizing & aligning scrum teams\nAgile projects\u00a0 depend heavily on the\u00a0calibration of velocity\u00a0across\u00a0scrum\u00a0teams. When there is\u00a0misalignment in communication and performance across all teams,\u00a0you will end up with an idle resource team.\u00a0 All teams must cross the finish line at the same time\u00a0with the same level of completeness.\nTo\u00a0achieve\u00a0this, there must\u00a0be\u00a0complete buy-in of the agile mindset from all members and\u00a0a clear definition of "done" across teams. \u00a0Teams operating on varying definitions of done could extend the time\u00a0spent on\u00a0end-to-end testing.\nTo enable this alignment, Release Train Engineers must perform two critical functions:\u00a0\n\nConfirm that cross team dependencies are recognized and logged as part of individual team backlogs and sprint plans.\nMonitor velocity and adjust sprint team capacity as required to align team\u2019s delivery on an anticipated delivery date.\n\n4. Integration of part-time and shared resources\nWhile there will be full-time members who are completely committed to the project, they will likely have to\u00a0share\u00a0their time across\u00a0multiple teams.\u00a0 Effectively allocating their time will depend on keeping them aligned with where the other teams in the project are.\nPart-time resources outside of scrum team\u00a0participation will have to be managed as well.\u00a0 For example,\u00a0the person in charge of auditing may only be devoting 10% of their time to the agile project overall.\u00a0 The program manager will have to\u00a0help\u00a0coordinate\u00a0their time\u00a0to\u00a0ensure their availability and commitment to\u00a0the\u00a0agile project when auditing is needed.\nResource forecasts are a good tool to address this point.\u00a0 Release Train Engineers need to maintain a full resource demand forecast across the programs and regularly update all providing areas.\u00a0\u00a0 Product owners will gain favor with these external resource providers by managing backlog to align with forecast for demand.\u00a0\n5. Required bureaucracy for large projects\nTo 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. \u00a0This complicates the team\u2019s ability to provide board-level transparency of spend and risk management.\nTo 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.\u00a0\u00a0 \u00a0Board and senior management presentations should not be an event but rather the delivery of current state and projections of future state.\n6. Vendor\u00a0accountability & performance\nIn 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. \u00a0This situation flies in the face of the standard belief that much of the scope of ERP is not flexible. \u00a0One area that this complicates is defining and resolving the concept of warranty support. \u00a0This is another reason that everyone in the project, on both client and vendor sides, must have the same definition of \u201cdone\u201d for each sprint.\nNew 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.\u00a0\u00a0 Teams that are considering agile at scale to address ERP should seek out experts in this area to learn about these new structures.