By Steve Kelman

Blog archive

A government agile veteran reflects

agile (Elnur/

Justin Fanelli is a principal engineer for the Navy. In 2009 he was working on IT at the Defense Information Systems Agency -- he came to the Navy in 2012 -- when he led one of the government’s first-ever agile software development implementations.

Fanelli has since then led about a dozen agile projects, making him both agile pioneer and veteran. I got to know him when he participated in a recent executive education program at the Kennedy School. He has a youthful appearance -- I ribbed him in class for wearing gel in his hair. He looks more Silicon Valley than Navy, with a bit of the Defense Digital Service look.

In any case, Fanelli agreed to talk with me about his experience in agile implementations. The 2009 project that was Fanelli's first involved taking an open-source command and control system, and developing a dashboard and interfaces for it with existing systems – essentially using APIs, though the term was not well known outside developer circles in those days. “The project was low dollar value but high importance and visibility,” he said.

The impetus for trying agile was that the leadership wanted the project done fast, and the leaders above him had heard about agile and were willing to give it a try. Fanelli himself had learned something about agile by reading in his spare time. At the time he worked on his first agile project, agile was not new to the world – the pathbreaking “agile manifesto” had been issued in 2001, Fanelli said, and the idea of agile was by 2009 being discussed in many corners of government. But the number of actual agile projects that he knew of was close to zero.

Though a need for speed drove leadership interest, it turned out that agile had a different, complementary set of advantages. There were many different users who wanted their requirements prioritized, and in a classic environment, there would have been bitter and lengthy political battles over that. “Under the cover of agile,” Fanelli said, they could set requirements by a less political, more objective process. “It let us clean up some things that needed to be cleaned up anyway.”

The biggest struggle in that first project was user involvement. According to agile principles, users needed to be frequently giving feedback, as often as daily.

One of Fanelli’s jobs was to explain to users why this was important – it was very different from how users had interacted with the technical team before, at meetings or briefings if at all. “It was more work upfront,” Fanelli noted. But he said that two-thirds of the users were willing to devote time to thinking about how they could do their jobs better. The government also had no product owner. (“At the time I didn’t even know what a product owner was,” he said.)

The heavy lifting on the project was done by the contractor chosen to do the development. The contractor chosen had agile chops, which was fairly rare at the time. Much of Fanelli's work on the project was technical oversight of the contractor and explaining to user that the project needed a more intensive and new kind of user involvement.

Fanelli now spends about half his time working on/overseeing agile projects.

He said that obtaining user involvement in frequent feedback is if anything harder than it was when he first started. People are now more aware of why this is important, but with the growth of agile projects, the demand on the time of users for feedback and involvement in the various projects has grown by leaps and bounds. Fanelli was encouraged to bring in contractor business analysts to play the role of users, but has rejected that solution, because he wants to talk with users directly when possible. It’s hard to get genuine user involvement because “users are grinding at their day jobs, their time is a hot and scarce commodity,” he explained.

Fanelli said developing personal relationships, and making a case for why the involvement is worth it, are crucial to getting user involvement.

He also emphasized the importance of vendor selection. This, he said, is even more important for agile than waterfall projects, because for the latter it is easier for the government to backstop if the vendor runs into problems. Although he hasn’t used tech demos (where bidders do some actual development work as part of source selection), oral interactions are a source selection tool that he trumpeted for speed and quality. He likes bidders being asked “tough detail-oriented questions” rather than proceeding using only canned vendor materials. He also spoke highly of statements of outcomes where practicable, because of increased opportunity for critical thinking rather than just spewing back the government’s words.

What are his biggest lessons learned? Fanelli cited two: the importance of a product owner and the necessity for discipline.

“On product owners, it’s not where it needs to be yet,” he said. “It is still early on in terms of training and incentivizing them. I think there would be a lot of value to having been a product owner as part of a career ladder.”

Fanelli believes that an agile team on a project needs to choose what agile implementation framework to use upfront, and not to change it midstream. “The better the entire team, contractor and government, understands the specifics of the agile implementation being used, the better equipped they are to deal with challenges effectively and efficiently as they arise,” he said. “For this reason, it is essential for everyone on the extended team to not just understand what agile means but to understand the specifics of your given agile implementation.”

I objected to him that this sounded like waterfall, where everything was cast in stone before the work began. He responded that agile promotes reflection and incremental adaptation when solutions are being crafted, but that a strong foundation and discipline along the way were important for agile processes so people could move down the learning curve.

Fanelli is concerned, however, that “people sometimes want to take some parts of agile but not hard parts,” such as real user involvement and trained product owners. This is the challenge he – and we all – will face going forward.

Posted by Steve Kelman on Dec 11, 2019 at 11:56 AM


  • Workforce
    White House rainbow light shutterstock ID : 1130423963 By zhephotography

    White House rolls out DEIA strategy

    On Tuesday, the Biden administration issued agencies a roadmap to guide their efforts to develop strategic plans for diversity, equity, inclusion and accessibility (DEIA), as required under a as required under a June executive order.

  • Defense
    software (whiteMocca/

    Why DOD is so bad at buying software

    The Defense Department wants to acquire emerging technology faster and more efficiently. But will its latest attempts to streamline its processes be enough?

Stay Connected