by clicking on the page. A slider will appear, allowing you to adjust your zoom level. Return to the original size by clicking on the page again.
the page around when zoomed in by dragging it.
the zoom using the slider on the top right.
by clicking on the zoomed-in page.
by entering text in the search field and click on "In This Issue" or "All Issues" to search the current issue or the archive of back issues respectively.
by clicking on thumbnails to select pages, and then press the print button.
this publication and page.
displays a table of sections with thumbnails and descriptions.
displays thumbnails of every page in the issue. Click on a page to jump.
allows you to browse through every available issue.
FCW : May 30, 2016
May 30, 2016 FCW.COM 19 I n the preceding pages, Dan Che- nok and Joiwind Ronen discuss some management challenges for agile contracting — most notably, the fear that some principles of agile cannot be reconciled with existing procurement regulations. As I’ve noted on FCW.com and elsewhere, however, good practice suggests — and procurement regula- tions allow — issuing a solicitation for an agile contract or task order under an umbrella indefinite-delivery, indefinite-quantity (IDIQ) contract without specifying requirements at the beginning. Specifying every detail upfront, of course, would violate the whole idea of agile. The government should give only a very general description of the work but be specific about the process it will use to develop and refine require- ments during agile sprints. My own view is that less specificity upfront results in greater attention and rigor in the post-award evaluation of deliv- erables that contractors produce dur- ing agile sprints. Recently, I had a conversation with Mark Schwartz, the dynamic CIO at the Department of Homeland Securi- ty’s U.S. Citizenship and Immigration Services (USCIS), to explore such trade-offs in more detail. He had great insights on two important and practi- cal issues: post-award management of agile contracts and task orders, and past-performance evaluations in an agile environment. In my view, his advice should be read carefully by everyone in the federal community who is working on agile — government and contrac- tor alike. Too much of a good thing? Schwartz strongly believes that agile contracting enables better post-award monitoring of contrac- tor performance for two reasons. One is that the government gets the results of a contractor’s efforts very frequently, not only after long periods of performance against a complex requirement. The second is that agile development often entails the use of automated tools that signal when dis- tinct parts of the work on a sprint are done and transparently communicate that to the government. There are definitions in agile task orders of what constitutes “done,” and they usually specify that the soft- ware has been tested. The tools also transparently communicate other information about various aspects of the process, such as what defects have been uncovered. I asked why agencies and contrac- tors couldn’t use the same auto- mated tools for traditional waterfall requirements and signal when at least part of the work, if not the whole requirement, was done. Schwartz said no piece of software — even in a waterfall environment — can be con- sidered done until it has been tested. And in waterfall contracting, only limited testing can be done before the full requirement has been completed, many moons later. In waterfall development, contrac- tors submit reports of the estimated amount of the requirement that has been completed, but those reports are subjective and not nearly transparent enough. Agile sprints are either done MANAGING AGILE AFTER THE CONTRACT AWARD Frequent performance evaluations can dramatically improve outcomes without burying an agency in FAR bureaucracy BY STEVE KELMAN 0530fcw_016-020.indd 19 5/4/16 9:22 AM
May 15, 2016
June 15, 2016