(Full disclosure: when I decided to write a book based on my agile experience, I chose to write about agile in the enterprise: "Project Management the Agile Way: making it work in the Enterprise")
The lead article, "Scaling Agile Development" is by authors Craig Larman and Bos Vodde, the former known best for his 2003 book: "Agile & Iterative Development" but more recently for a two volume tome about scaling agile, from which this article is developed.
(Another disclosure: I've not read any of Larman's books; only this article)
In a word or two: OMG, No!
At best Larman and Vodde are examples of agile naivete; at worst, they're just plain wrong headed about how to do agile in the defense industry. And, it's a shame that Crosstalk, a worthy journal to be sure, but obviously not peer-reviewed, would publish such a poorly conceived paper.
Their basic idea is this: Agile, in the guise of Scrum, is scalable to any limit -- thousands of developers they say -- by the simple expedient of adding teams (in 10 person increments) and adding some coordination meetings and tools. Architecture, testing, and management -- unneeded they say except for that which a team can provide for itself -- are unnecessary burdens, even for huge projects.
They posit that all this is doable in three frameworks: First the single team for the small projects; second a framework that does for 10 team (100 team members); and then a third framework that is unlimited in its scalability. The differences in frameworks are some overhead services provided at each level for coordination and communication and management of the project-level backlog, and the idea that at the framework 3 level more than one product owner will be needed, and so a committee of product owners will be needed. Indeed, most of the discussion centers on the backlog and how it is to be distributed among teams.
At scale, for many skills, like architecture, the authors suggest the benefits of a "community of practice" birds-of-a-common-feather organization plan (I like this idea and it's generally endorsed in the agile large-scale community).
I also like some of their ideas about organizing the backlog -- which at scale will be tens of thousands of stories, etc -- into "areas", like protocols, but NOT into such broad categories as "performance".
There's no discussion of how these frameworks fit, or could fit, in a contractor/government environment; how the warfighter's interests are to be represented... they certainly aren't present to be the product owners; and how processes that obviously breakdown at scale -- like simple war rooms with sticky notes for stories -- would work with tens of thousands of stories. And, there's no discussion of interfaces to legacy installed base; no discussion of working through defined interfaces or APIs; and no discussion of how other swim lanes (or WBS verticals) would be brought into the project.
Even worse in some respects, given the need to honor "other people's money", there no discussion of a business case or how to present large-scale agile in a business case.
All the method discipline of XP is ignored; all the great practices of agile modeling and scaling, so well documented in the agile DSDM methodology and by such practitioners as Scott Ambler who has made a science out of agile-at-scale is ignored in favor of the lightest weight and least demanding of the agile methodologies: Scrum
In short, if these two guys have ever been close to a large scale agile project for real, it does not show. If they have ever tried to build programs and projects for the defense industry, whether business systems or warfighter systems, it is certainly not in evidence.
For more of my thinking on agile in the DoD, read this white paper. (Yet again, another disclosure: I worked for the DoD as a project manager and I worked for the DoD as a contract project manager doing software systems development). And, for agile in the waterfall: this posting.
Check out these books I've written in the library at Square Peg Consulting
