Adopting an Agile approach to projects continues to grow in popularity but there are a number of key considerations we should keep in mind on large Agile programs. Agile is great for smaller teams who are colocated but Agile gets more challenging on projects with hundreds of people and offshore teams. The scale and complexity of large Agile programs requires a focus, skills and considerations that smaller Agile projects do not require.
This article discusses 14 key success factors (KSFs) for Agile programs based on the experience of Seven Consulting. 5 KSFs (the blue boxes in the diagram below ) are relevant to all projects, while 9 KSFs (the purple boxes in the diagram below) are specific to large Agile programs.
KSFs relevant to all projects include:
Large programs can become an industry in their own right. It is important to ensure that the program always remains focused on delivering an outcome which is consistent with the organisation’s vision and strategy. There needs to be a direct and monitored linkage between the organisation’s strategic themes and the program’s backlog. Large scale Agile programs will generally be subject to a greater degree of change, so it is critical that the link between strategy and program outcomes are maintained and reviewed constantly.
As part of PI (Program Increment) planning, we generally spend a fair amount of time identifying dependencies between value streams within the program. If the dependencies between the value streams do not align, then the program cannot deliver end-to-end capabilities. However, managing the dependencies that are not within the scope, budget or management control of the program can be even more difficult than managing internal dependencies. Some external programs are Agile and some are not. Some external programs have BAU (business as usual) delivery constraints which do not necessarily align with the program’s sprint cadence or releases. The program team needs to keep up regular communication with external programs and determine a happy medium in terms of delivery of components to the program. Mature programs manage all their dependencies within the values streams. External dependencies often require additional management attention, negotiation and funding.
Agile projects are designed to deliver business benefits and return on investment. However, as the scope of the program gets larger, there are often key foundational, platform and infrastructure components that need to be developed before business capabilities can be delivered. The foundation components do not generate benefits themselves which generally results in benefits only starting to flow once the business capabilities are built. Measuring benefits is difficult and political. Business sponsorship for benefits realisation is critical together with regular benefits status reporting – both in planning/delivery as well as in benefits realisation stage.
Not all programs will transform the user experience. Some programs will provide incremental improvement to the user experience but not revolutionary change. Transforming the user experience is a lot harder than it sounds. The user can be a customer, an employee, a channel partner or another persona. Each persona can have different capabilities. Transforming the customer experience requires reimagination of the customer experience from the customer’s perspective and should not be regarded as just reengineering existing processes. The optimal user experience is fast, intuitive and convenient but with acceptable levels of control. All programs need to keep showcasing the end-to-end user experience and testing it with customers, staff and partners.
End-to-end testing is required to ensure that all components work together as an integrated whole. Testing of new components needs to occur within a sprint, preferably with as much integration testing as possible. End-to-end testing provides a level of validation of testing that may not have been performed in earlier development phases. It is desirable that end-to-end testing and regression testing have a level of automated testing to improve efficiency and reduce testing timeframes.
KSFs which are particularly relevant to large Agile programs include:
One of the advantages of Agile versus traditional approaches is that Agile projects can handle the impact of change more easily. The organisation’s business priorities are likely to change during the life of a large program and the program needs to be able to deal with the change. PI (Program Increment) planning determines the priorities to be delivered for the next program increment (typically one quarter). However, nothing stands still in today’s world, so we need to reevaluate the program priorities before each sprint to ensure and maintain the alignment of the program’s outcome and the strategic intent.
The funding model of large Agile programs is still evolving. Sometimes the funding approach for Agile programs is the last bastion of traditional approaches as boards and executives are used to funding projects for an outcome for a finite period. Some Agile programs struggled to deliver outcomes in accordance with their original estimates and within their estimated timeframes. Large Agile programs are moving to a fixed capacity model where a defined number of teams are funded for a finite period (e.g. 6 months or 12 months). The emphasis moves away from just tracking cost overruns to also ensuring that business benefits can be generated by the fixed capacity team within the funding period.
Large organisations have struggled in the past with the complexity, cost, risk and slowness of enterprise releases which could be as infrequent as twice a year. Agile approaches offer faster speed to market of new capabilities. PI planning can plan capabilities to be built over a quarter but does not imply that there are only quarterly deployments. The deployments can be quarterly, monthly, fortnightly, weekly, daily. Large Australian organisations are moving towards weekly and fortnightly releases. The sizes of the releases are getting smaller and the risk of the releases are reducing.
The ability for an organisation to deploy in to production at the end of sprint is dependent on how sophisticated the CI/CD (continuous integration/continuous deployment) environment is. Building up a CI/CD capability takes time, funding and prioritisation. CI/CD environments require code management, release management and automated testing capabilities. Automated testing capabilities need to be developed for unit testing, end-to-end testing and regression testing. The company will need to prioritise the development of CI/CD capabilities over the development of some business capabilities.
Some of the global technology giants are doing multiple deployments daily. This may make sense for Google and Facebook. However, changing business processes daily for a bank or energy company is not practical. Business users can be swamped with the amount of change being introduced by multiple programs in parallel. There needs to be an alignment of business change, training and communications to help business users keep up with the amount of change.
Communication on larger programs is always an issue. By the time program wide communication has gone out, the information is out of date. Not everyone receives the email. Not everyone reads the email. Running an all hands meeting for a program team of hundreds of people in multiple locations is expensive. There is no silver bullet here. Maximising communication within squads/teams is important. It starts with daily standups and scrum of scrums. Tools such as JIRA are great for tracking the backlog and defects. Nothing beats real-time, face to face communication. With large geographically dispersed teams consideration needs to be given to changing meeting times to allow for off-shore participation, extensive use of video-conferencing and travel to enable building of relationships.
In many organisations there can be different flavours of Agile, e.g. SAFe, Scrum etc. It is important to standardise the Agile methodology, names of the ceremonies, sprint cadence etc. It is also important that there is a central index of epics, capabilities and enablers. There should be an avoidance of multiple teams building the same functionality because they were not aware that someone else had already built it or they called it by a different name. The teams should produce consistent documentation for epics, capabilities, user stories, interface specifications, process flows.
As per the discussion on the funding model, large Agile programs are moving to managing a fixed capacity which gives them a level of certainty about their costs over time. In accordance with the DevOps principles, teams will support what they have built. There needs to be a prioritisation of work between new business capability and production support. A proportion of team capacity needs to be reserved for production support work. Not all of the capacity can be assumed to be allocated to building new business capability. As discussed in the CI/CD section, capacity also needs to be allocated to the development of foundational capabilities including CI/CD.
Tooling and reporting will be required to track and measure the achievement of outcomes against plan. Tools such as JIRA are great repositories of information but often the information needs to manipulated for tracking/reporting purposes using tools such as Confluence, Power BI and Tableau. Tools are required to administer the traceability between initiatives, capabilities, epics and stories. Tools are required for code management, test automation and deployments. Reporting is required on burn-up charts, backlog, capacity, end-to-end testing, issues and risks. Specialised reports are required regarding benefits realisation which are often produced using Excel.
For Agile programs to be successful, it is highly desirable that all members of all squads/tribes/teams are incented to achieve the maximum outputs on behalf of the program. It is generally desirable to have integrated teams with a range of skillsets rather than teams from only one supplier. The supplier commercial arrangements need to align with the ways of working within the program.
