Paving the Bare Spots and Following the Guidon

This is a set of speculations as to whether, and how, a large number of loosely-coupled small projects (less than the $1M threshold at which mandatory OMB guidance kicks in) might be coordinated so that large-scale agency improvement occurs over time.
$1M buys ten developers for a year at a burdened salary of $100K each. That is two small agile development teams or one large one, and a year is 24 biweekly sprints. That may seem like small potatoes to SDLC advocates, but agile  teams can pull off amazing things in a year and 24 sprints leaves lots of opportunities for redirection and convergence. Question is, how could such teams be coordinated so that they converge over time on something useful at larger scales (where large means government-  or at least agency-wide).
Although it may seem wasteful to launch projects without the usual heavy planning, notice that there are no billion- or even million dollar projects at risk. There is just the risk of a single sprint, about $1M/24; a little over $40K. Performance is easily monitored during each sprint review so non-performing projects can be terminated or redirected quickly. And perhaps best of all, costs are so affordable that all agencies could participate. There is no approval process that would prevent some agencies from improving their performance through information technology.
Let's assume that central management is commensurate with the small ($1M) project sizes and consider how to accomplish the most at the periphery with minimum management at the center. Two notions seem productive:
Paving the Bare Spots: This is explained in this paper (pdf) from just after my time with the architecture team for DISA's Netcentric Core Enterprise Systems (NCES). The title refers to a novel way of keeping students off the grass once "keep off the grass" signs have been tried and failed (as they always seem to do). The new approach is to just let the students walk where they wish and paving the bare spots behind them. Works every time.
How might that apply to the president's agenda of radically improving agency performance? See the paper for details, but in short, it involves a digital "enterprise space" modeled after some standards bodies and especially the Apache Software Foundation. This space is what you'd expect of such organizations; a download area for ready to use software (and someday "trusted components" as explained elsewhere on this blog), a source code repository for sharing code, a wiki or similar for sharing ideas, and so forth. And there's a governing body that helps coordinate the work (as distinct from managing it; management is largely handled by each team) and accepts long-term ownership of the results.
Follow the Guidon: This is based on the role the flag-bearer once played in  military formations. Troops were taught to follow the guidon. They were free to exploit local tacit knowledge, route around obstacles, duck and cover if need be, yet converge on the goal set by management. The key thing here is that it was apparent to all that the leadership (or at least their flag bearer!) was out there in front, leading the way and assuring that everyone converged on the goal.
A guidon is just a flag on a stick; a lightweight and easy to follow governance model if there ever was one! The digital equivalent can be seen in the paper, in the governing body and the behind-the-scenes work of establishing enterprise standards and reference implementations of the same.