Agility with results: small teams, clear decisions

What the evidence says

McKinsey analyzed agile transformations at 22 organizations across six sectors and found improvements of 10 to 30 points in customer satisfaction, 20 to 30 points in employee engagement, 30% to 50% in operational performance, and reductions of at least 40% in time to market. The study’s caveat is as important as the figures: significant results appeared only where the transformation was implemented holistically and with ambitious performance targets (McKinsey).

That caveat explains why many agile initiatives disappoint. The rituals are adopted (daily stand-ups, boards, sprints) without changing what matters: how priorities are set, who decides and how results are measured.

The symptom: activity without results

In our work with a consumer e-commerce company, the diagnosis of the marketing team revealed a pattern we see often. The team was active: it produced content, launched campaigns and managed social media. But the activity did not translate into sales. Advertising spend was not recouped and the team, as a whole, did not generate enough volume to sustain itself.

Digging deeper, the causes had nothing to do with individual talent. Clear leadership to guide, prioritize and supervise was missing. Each member worked in isolation, without effective coordination, which hurt the quality and speed of deliverables. Data was not used systematically to make decisions. And there was a misalignment between management’s vision and the team’s capabilities.

Agility starts with an owner of the priority

The first recommendation for that team was not to adopt an agile framework. It was to define who prioritizes. In agile models, that role is called the product owner; in the mid-sized company, it is usually an area leader who was never given the explicit mandate to say what won’t be done.

An agile team needs a backlog ordered by value, and someone with the authority to order it. Without that figure, the team attends to the day’s emergencies, which tend to be the requests of whoever has the most power, not the ones that generate the most results. Agility, in this sense, is first and foremost a governance decision.

Short cycles tied to business metrics

The second recommendation was to connect each work cycle to a business metric. In a digital marketing team, that means every campaign has a hypothesis (which audience, which message, which channel), a success indicator (return on ad spend, cost per acquisition, conversion) and a review date. At the end of the cycle, the team decides whether to scale, adjust or stop.

This change seems obvious, but it requires something the team didn’t have: data. Without dashboards showing performance in real time, the cycle review becomes a debate of opinions. That is why, in our experience, investment in data and analytics should come before, or at least alongside, adoption of the method.

The structure that enables agility

Agility doesn’t work on just any structure, either. In the organizational diagnosis of a technology SME, we found many management titles for a small team, with no coordination forums between areas and no clear decision limits. That structure produces the opposite of agility: every decision that crosses areas has to be escalated to the founder.

The answer is to organize small, cross-functional teams around an outcome (a product, a customer segment, a process), with autonomy to decide within a framework. The formal structure can remain functional, but the work flows through teams.

Operating models for programs

Agility also applies outside product teams. In designing a business-strengthening program for an industry association, we built an operating model with strategic direction, a program lead with PMO functions, sector experts, a training workstream and an analytics and delivery workstream. Cycles were organized in phases with verifiable deliverables and indicator tracking. The principle is the same: small teams, clear roles and data-driven decisions.

The most common mistakes

In our experience supporting the adoption of agile practices, some mistakes keep recurring. The first is turning agility into a meeting calendar: daily, planning, review and retrospective meetings that consume time without changing decisions. The second is applying agility to just one team, while the rest of the organization keeps running on annual budgets, hierarchical approvals and disconnected targets. The agile team ends up waiting for decisions from a system that isn’t agile. The third is confusing agility with an absence of planning: agile teams plan more often, not less.

The fourth mistake is not changing the role of leaders. In an agile organization, the leader stops assigning tasks and starts defining priorities, removing obstacles and developing people. That change is hard for those who built their careers solving problems personally, and it needs support.

Agility in the large organization

Agile practices also have a place in large organizations, including financial institutions, where product and technology teams work with agile frameworks at scale. Our experience in those environments confirms the conclusion of the McKinsey study: value appears when agility reaches the way the budget is allocated, targets are set and portfolios are governed, not just the way each team works. An organization with agile teams and traditional governance gets a fraction of the benefit.