Only the international development crowd could take all-time great branding like Agile management, and turn it into mouthfuls like “problem-driven iterative adaptation”, or “politically smart, locally-led development“.
Both of the latter approaches paraphrase the core principles of Agile: relationships over tools, workable approaches over doctrinal clarity, and small work batches to solve concrete problems rather than long-term over comprehensive plans. But alongside marketability it seems that the most potent message of all has been dropped. This is closeness to the customer.
This point was driven home for me at a recent event on change management at the Overseas Development Institute. The subject was “agile” approaches to institutional reform, with a case study on security sector reform in Tunisia.
At the outset, this felt like a breath of fresh air. Security sector reform (SSR) is an area where a big-bang, all-inclusive model is still considered best practice by many donors and multilateral institutions. (Without a skerrick of evidence to establish that fact, and plenty of examples where it has been hugely destabilising.)
Against that orthodoxy we heard good common sense principles. Program staff followed the priorities identified by local counterparts; stood ready to seize opportunities; tried hard to build relationships at various levels in target institutions.
So far, so good. But then the other shoe dropped. For it turned out that “feedback” had a rather specific meaning—best captured in one slide which depicted the program’s critical relationships as a triangle comprising the Ministry of Interior, the implementing agency, and the donor.
This is deeply ironic. In political science an “iron triangle” is a situation of regulatory capture, i.e. one where policy elites, lobbyists and legislators agree on self-serving definitions of the problem they need to solve. Moreover this is a phenomenon that is particularly well-documented and well-studied in … the defence sector.
Regulatory capture is problematic anywhere. But it’s outright dangerous in a situation of political transition, where institutions have limited legitimacy to fall back on. Here the wrong policy moves can easily damage, or break entirely, the fragile relationship that marginalised groups have with the government.
That’s why recent years have seen such heavy emphasis on “inclusive-enough” approaches to policy-making in fragile states, as I noted in a recent post.
Who is the “customer”, really?
I can’t judge the merits of the Tunisia program—in fact I know next to nothing about it. But it is fair to say that the language we were hearing reflects a real weakness of the thinking around “problem-driven iterative adaptation” (PDIA) and its various spinoffs.
The paper that coined this phrase, from Matt Andrews at Harvard, criticised “narrowly engaged change processes”. But it’s telling how he defines the alternative (my emphasis):
‘Convening’ typically involves bringing groups of leaders together with key implementers to craft local experiments and solutions, while ‘connection’ involves ensuring second and third degree interactions with frontline workers who will ultimately have to implement final changes.
Let’s compare a passage from Eric Ries, in the frequently irritating but also quite powerful The Lean Startup:
Lean thinking defines value as providing benefit to the customer; anything else is waste. In a manufacturing business customers don’t care how the product is assembled, only that it works correctly. But in a startup, who the customer is and what the customer might find valuable are unknown.
Or here’s another foundational text of the agile-istas, Steve Blanks’ Four Steps to the Epiphany:
The flaw in this thinking is that “first customer ship” is only the date when Product Development thinks that they are “finished” building the product. The first customer ship date does not mean the company understands its customers or to market or sell to them.
Now ask yourself: In a setting like Afghanistan or the Congo, are security sector institutions like factories—with products that citizens already understand and expect? Or rather, is it violently contested what these institutions should do, how they should be administered, and whose interests they will serve?
Stated in fewer words: Isn’t identifying what citizens feel is legitimate and effective really the lion’s share of the problem?
None of this is to suggest that the principles of PDIA are invalid. In fact, they make a lot of sense at the level of program or operations design.
The problem is rather at the level of the institution, or as an overall diagnostic method. Here it is very risky to rely primarily on collaboration with institutions that are neither effective nor legitimate from the point of view of citizens. Conversely, it is simple prudence to bring in a “reality check” as soon as possible. (Even if that feedback turns out to be rude or unwelcome. )
And here we circle back to that presentation at the Overseas Development Institute. Out of 2+ hours of discussion this was the phrase that stuck with me: the safe-to-fail experiment.
It’s a difficult phrase. Nobody wants to talk about “experiments” when there are lives at stake, and real urgency. But this is nonetheless the nut that must be cracked for agile management to really take root.
In short, we must always be asking ourselves aggressively: Where can we pilot? How can we test the key elements of our approach in real conditions, with real citizens, before we go too far down the road with that complex design process?
If you have examples where you’ve “gone live” in this way, I’d love to hear them.