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 : June 30, 2014
Since the exposure of HealthCare.gov s dif culties, media and technology commentators have touted agile software development as one clear solution for what ails the way agencies buy IT. But there s no consensus on how to buy it, and today s government is understandably cautious about the calculated risk-taking that innovations like agile require. The agile approach generally refers to iterative software development and continuous rapid delivery of working mod- ules, based on constant collaboration between users and contractor and internal IT staff. Prototypes are tested and re ned as they are delivered. The good news is that agile development is cheaper than conventional approaches. It takes less upfront investment, and it squeezes out bugs and soaks up lessons through deliv- ering and testing usable pieces of software along the way. Traditional development saves testing until the end, when xing a complex, almost-completed application is harder, takes longer and costs more. Other distinctive aspects of agile: • It demands adaptability, openness to change, and accep- tance of trial, error and changing course. Neither the Federal Acquisition Regulation (FAR) nor its modi cations speci cal- ly address agile, so it also calls for acquisition professionals to exercise creativity, alliance building and critical thinking. • It is not a product. Agile development is a service that builds a solution and is acquired using a broad statement of need rather than traditional detailed, lengthy requirements. When organizations embrace agile development, they agree to be agnostic about the shape of the nal solution as long as it meets the need and is delivered within budget and on schedule. • It fails without teamwork and trust. Program and contracting professionals must agree on an end-state vision but avoid de ning the features or functionality of the solu- tion that s delivered to achieve it. That de nition occurs throughout the development process as the product team and contractors build and test each new prototype and apply what they ve learned to the next. Agile requires buyers to allow change, adaptation and inno- vation during development in exchange for software uniquely suited to solving their problems at the end. Consequently, the agency must trust its buying team, and it, in turn, must trust the contractor team. Achieving that level of mutual reli- ance is no small feat in government, where today any change in course can be considered failure, waste, fraud or abuse. Fortunately, experience has taught us a few things that can help limit the risk of the agile approach and make it well worth trying. FAR Part 39 already recommends using a modular acquisition strategy for IT so that capability is deliv- ered throughout versus at the end of the development cycle. Although there are no rules for choosing a contract type for agile development, some work better than others: • Fixed-price contracts for the whole solution are less than ideal because they necessitate modi cations and change orders to address each unforeseen challenge, which inhibits trial and learning. Using xed pricing for sprints or releases can work, but only after the government/contractor team has agreed on a development schedule and how to oper- ate within it. • Cost-type contracts offer schedule and cost exibility and the ability to provide performance incentives --- all of which are ideal for incremental delivery of segments of working software. Cost contracts require more skill and attention, however, to ensure that companies control their costs. • Time-and-materials and labor-hour contracts have come under re in recent times, but they re well-suited to agile projects. They require using FAR Subpart 16.6 to make the case upfront that no other contract type will suit the Buying agile without jumping through hoops BY KYMM McCABE Agile development can be less risky than the traditional approach, but it takes exibility and continuous involvement by government and contractor teams 24 June 30, 2014 FCW.COM AcquisitionMatters
May 30, 2014
June 15, 2014