Scaling agile at financial institutions has been added to your bookmarks.
Scaling agile at financial institutions
Lessons from the trenches
Many large financial services companies face mounting pressure from new, nontraditional competitors. The most disruptive of these newcomers develop and launch multiple innovations, identify the winners, and then grow at speeds generally hard to match by major institutions.
Scaling agile at financial institutions
Agility has demonstrated its merits and can accelerate speed-to-market, enhance quality, and increase flexibility while reducing costs and complexity. Various agile methods employ various approaches to implementation, but share characteristics. In this paper we discuss:
- Agile approaches to meeting new challenges
- Keys to scaling agile
- Governance and execution
- Adapting agile
Download the paper to learn more.
Keys to scaling agile
In order to scale agile to the needs of a large organization, the following are critical:
- Use multiyear road maps: Initiatives in large organizations often involve multiple projects with long-time horizons. Agile implementations for such initiatives should conform to a long-term road map while maintaining basic principles of agile.
- Strengthen governance structures: Large-scale implementations involve multiple scrum teams from disparate functions under different leaders, often in dispersed locations.
- Address cross-team dependencies: Often a team requires completed components from another team before proceeding further. Such cross-team dependencies create the need for additional coordination when planning upcoming iterations.
- Consolidate reporting and tracking: In traditional agile, progress can be tracked via burn-down charts or other reports from agile tools. In large-scale agile, team burn-down rates should be combined and fitted into the project-level plans to report overall progress.
- Increase end-to-end quality assurance: Traditional agile relies on functional and unit testing within sprints as well as other quality control processes. In agile at scale, limits on how frequently code can be integrated create a need for dedicated end-to-end (E2E) testing before releasing code to production.
Elements of agile can be adapted to larger financial services organizations, but the organization should also adapt to agile.
Traditional agile is designed for small teams working on well-defined problems over short periods. Scaling agile to projects with dozens of teams working on complex products over multiyear horizons clearly presents challenges.
Governance and execution
Effective governance calls for alignment of executive sponsorship across functions, broad agreement on the business case and desired business value, and acknowledgement of the potential benefits and the limitations of agile. A commitment to data-driven project management fosters the right cadence and atmosphere for the project. That commitment supports governance that relies on facts rather than opinions, and promotes honesty, openness, and collegiality across the various teams.
Governance strategy for agile at scale encompasses the following activities:
- Agile program structuring
- Programmatic backlog management
- Systematic reporting and dashboards
- Integrated quality management
- Organizational coexistence
Also, teams need realistic expectations regarding deliverables, testing, and documentation. Tolerance for the iterative nature of agile does not come naturally. However, training, mentoring, coaching, pilot projects, and hybrid or gradual adoption can help organizations develop that tolerance.
Sound execution tactics include the following activities:
- Enhanced scrum roles
- Business process alignment
- Development and release management
Successful scaling of agile depends mainly on effective governance strategy and sound execution tactics.
- Project selection: The potential benefits of agile will likely be most apparent on projects with volatile requirements, aggressive timelines, and high end-user interaction. Business applications, self-service portals, and ecommerce and similar Web-based applications are good candidates. In addition, a hybrid approach may be useful for projects outside this profile or in organizations that want to take a more gradual approach to adopting agile.
- Business involvement: Agile methods require increased involvement from affected businesses and, in some cases, dedicated business resources. Therefore, it is more suitable to develop a mutual understanding of the frequency and type of involvement that will be needed from the business to specify needs, review progress, answer questions, and provide feedback.
- Regulatory requirements: Regulatory and compliance requirements typically call for rigorous exception and reconciliation reporting, which can be developed with agile methods. This can be done by embedding fulfillment of regulatory requirements into the work of each iteration and then auditing the test reports. In other words, regulatory requirements and reporting needs should simply be treated as features by the development team and addressed accordingly.
- Human resources: An agile team requires collaborative, cross-functional individuals who can understand business requirements, interact with customers, design features, and develop and test code. Agile teams should, whenever possible, place experienced developers in those roles and pair junior developers with more senior team members.
- Senior management commitment: Senior executives will probably be unaware of agile methods, and project managers may resist apparent loss of power. However, executives and project managers can be swayed by understanding the threat posed by more nimble competitors and seeing early wins at accelerated rates.
Addressing the following practical considerations can assist an organization seeking to scale agile to larger projects.