Can agile practices work across a large portfolio of many teams and lots of developers? Absolutely. Netflix coined the phrase "highly aligned, loosely coupled" to describe well-tuned agile development across a large organization. Let's look at the role of context and autonomy, as well as some common characteristics found among high-functioning agile portfolios.
Définir le contexte adéquat
Dans une grande entreprise agile, l'attention se focalise tellement sur l'équipe que la direction générale finit par se demander à quoi elle sert. Moteurs de la stratégie et de l'orientation générale, les cadres dirigeants peuvent devenir des champions clés de la culture agile pour l'ensemble de l'entreprise. S'agissant du développement agile sur tout un portefeuille de produits, la stratégie et l'orientation générale se manifestent sous forme de « thèmes », à savoir des aspects globaux du travail, définis sur une période spécifique. Ces thèmes permettent à plusieurs équipes de travailler sur un même projet, de collaborer de façon efficace et d'atteindre les objectifs de l'entreprise.
La culture de la transparence fait émerger les problèmes sans crainte de représailles et minimise les aspects négatifs de la politique de l'entreprise. En conséquence, il est plus facile d'identifier la solution adéquate et de faire progresser les équipes.
Déployer les pratiques agiles dans toute l'entreprise
The most successful companies running agile at scale share three common traits. First, the entire program is iterative. Traditional portfolio management is focused on top-down planning with work laid out over long time periods, but agile portfolio management takes the concept of build-measure-learn cycles used by individual agile teams and applies it on a larger scale. Teams work together, use modular design, and share findings on a regular cadence. This results in tremendous flexibility, which shifts the focus from continuing to execute on an inflexible plan to delivering value and making tangible progress according to business strategy and goals.
Second, successful organizations communicate across the portfolio. They share knowledge and break barriers between organizational silos. Similar to agile ceremonies on the team level, context needs to be shared constantly throughout the organization so that goals, progress, and stumbling blocks are transparent for everyone. This fosters respect between teammates and coworkers alike, regardless of role within the organization, and encourages interactions that are rooted in empathy and understanding.
Third, the most agile organizations make frequent releases across the portfolio, even if a release involves the work of multiple programs. Aligned sprint cycles, work invested in strong APIs and technical decoupling, and an efficient automated testing and deployment pipeline all guarantee constant visibility into who is shipping what and when.
Partager une vision commune mais épouser la diversité
As in traditional agile development, work in portfolio agile development is delegated to teams rather than individuals. Each team understands the organization's larger goals, and each team also develops a vibrant culture that optimizes its own processes and delivery.
For example, story points are a common way teams estimate work, and use a set of values based on the Fibonacci sequence (0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100). Team A's idea of what an 8 means will probably differ from team B's. For this reason, senior management shouldn't measure teams by numeric velocity alone. (Numeric velocity is the amount of story points a team can complete within a sprint.) They must understand that each team's velocity will be unique because each team calibrates story point values differently.
Likewise, agile teams have different release cultures. Scrum teams usually release software at the end of each sprint, while kanban teams release continually or when the product owner requests a build be pushed to production. One of the big challenges in agile portfolios is releasing large quantities of code at once–or rather, avoiding that. No one wants releases that requires the entire engineering staff on deck, after all. Separating code into independent release streams by using modular, rather than monolithic, design, goes a long way in terms of flexibility and autonomy among business units. Modular design also reduces risk in each release because less code is changing with each release. That makes it easier to diagnose and fix problems afterwards.
Autonomy also extends into workflows for portfolio organizations. Teams that work in different parts of the business may have unique workflows. It's a good bet that a software engineering team will have a different workflow and process than a marketing team, even when both departments follow agile principles like iterative development and regular retrospection. Or two development teams may choose to divide their workflow into different states. And that's ok! This diversity gives large agile portfolios the benefit of shared knowledge. Trying more things means you're learning more things that can shared across the organization.
Développer l'agilité au fur et à mesure de votre croissance
An agile framework for a large portfolio means scaling agile principles used at the team level across a whole organization. Agile culture is a force multiplier: it naturally scales upward and outward when its core principles are followed and shared. But the portfolio will only be as successful as its weakest team. To ensure success, senior leadership must work in partnership with all teams to build a healthy agile culture.