In “The Age of Agile,” Steve Denning argues that agile management is superior to traditional, hierarchical management styles. Companies that adopt agile outperform the rest, and will continue to do so. Agile is catching on, and not only in the software development sector that popularized it.

At a recent panel discussion, hosted and moderated by OnFrontiers, I joined Denning and a group of development leaders representing the U.S. Agency for International Development (USAID), the World Bank, and the Millennium Challenge Corporation to discuss just how well the agile model fits our sector. The punchline seems to be: yes, and no. The closer we get to projects in the field and the farther we get from our headquarters, the more likely it is that agile can flourish.

Steve Denning speaks on agile management. Photo courtesy: OnFrontiers.

What is Agile?

Denning describes three laws that comprise the agile model:

1. The law of the customer: Agile companies are obsessed with understanding, serving, and delighting their customers. Their customer focus is driven by new technologies and business models that shift power away from companies and toward customers. For instance, your ride-share driver’s rating affects her compensation.

2. The law of small teams: Small, responsive teams iterating solutions with the customer replace hierarchies and rigid work planning. An agile team makes decisions quickly, has minimal hierarchy, and is unafraid to fail. These nimble teams allow projects to prototype approaches and iterate them based on customer feedback.

3. The law of the network: The benefits of agile accrue best to companies that adopt it wholesale as opposed to within isolated units or departments. Importantly, the management model shifts from controlling and supervising staff to enabling teams to flourish.

The development sector is peppered with sporadic evidence of agile thinking, but it has not been adopted wholesale. What would it take for the sector to adopt the agile mindset?

At the customer level, many of us struggle with defining a key question: Who is the customer? Most of us believe we serve poor and low-income people in emerging and frontier markets, and their governments. But those people or institutions do not typically pay for our services. The direct customer is often a donor agency, such as USAID, the U.K. Department for International Development, or the European Commission.

In developing countries, these customers (whether governments, civil society, small businesses, or poor and low-income households) are becoming more discerning; they increasingly have access to information, improved education, and technology, especially mobile technology. At the field level, the development community increasingly recognizes this welcome development and has shifted its approach. For instance, in the early days of microcredit, an array of microfinance institutions (MFI) provided pretty much the same type of working capital loan. Today, providers have felt the pinch of increased competition. MFIs, banks, and other institutions—including mobile telephone operators—have innovated on product types and delivery in hopes of better catering to customers and winning their business.

In line with the typical implementation model, projects on the ground are often run by small, nimble teams. The closer to the field, it seems, the better our small teams of development practitioners can work with customers and end users to iterate solutions that offer increasingly better value. And donors can hardwire agile into project design. For instance, USAID’s Transparent, Effective, and Accountable Municipalities (TEAM) project in Kosovo embedded the Agency’s Collaborating, Learning and Adapting (CLA) model into the fabric of the project. Alongside more traditional indicators, USAID directly evaluates the project’s success in adapting to changing circumstances and seizing emerging opportunities.

Some donor agencies have incorporated small, iterative teams into their core processes. USAID regularly engages partners in co-creating solutions, inviting interdisciplinary teams to design and implement projects. The small team at the INVEST project helped the Agency usher in some important procurement reforms, enabling the Agency to access specialized expertise not normally tapped for development projects. Going back and forth with USAID, the INVEST project landed on a process that makes transaction advisors and investment bankers available to drive private capital into high-priority sectors—a process measured in weeks, not months or years.

Brigit Helms shares lessons learned from working for multiple clients. Photo courtesy: OnFrontiers.

While examples of agile teams dot the development landscape, and many organizations—donor agencies, multilaterals, implementing partners—are testing agile models in specific areas such as proposal writing, no single entity has managed to achieve the “nirvana” described by Denning where entire organizations adopt the model.

Agile is a mindset as much as anything else, and the development community, like other sectors, struggles to shift wholesale to that mindset. Unlike some sectors, though, our community often operates through a decentralized, project-based model that allows local teams to serve as the laboratories of agility. And in our industry, project work is often seen as the pinnacle of the profession, the people who lead it held in high esteem—so it shouldn’t go against the grain to institutionalize a principle of learning from the outside in.

Beyond learning from our colleagues in the field, we also need to ensure that our procurement and our monitoring, evaluation, and learning processes are up to the task of identifying and rewarding superior performance. If agile organizations really do outperform their peers, then they will rise to the top in development as in other sectors—but only if our playing field is level and transparent. For development funders especially, that means demanding better data and analytics, reducing barriers to entry, removing market-distorting practices, eliminating anti-competitive procurement vehicles, and so on.

Finally, we need to strike the right balance between bureaucracy and agility. The leaders of development organizations are often the stewards of taxpayer funds, so the burden of public accountability is necessarily high—particularly in frontier settings. Set the compliance bar too high, and we will fail to give appropriately free rein to our innovators in the field. Set it too low and standards will slip, abuses will proliferate, and confidence in our aid programs will decline.

No one said agile is easy.