Skip to main content

Appendix


App A - Comparison of Traditional to Agile Thinking on Software Development

Comparison of Agile to Waterfall


App B - Examples of Team Members (IPT) Needed to Support Agile Software Development

Government

Contractor

*Cross functional individuals should occupy these roles (developers and testers are both able to work each position). Automated testing is encouraged where the tester can write and run automated tests that are supplemented with exploratory testing.


Appendix C - Sample Language for Government Contracts for Agile Software Development Services

This text is to help illustrate how the Agile principles in this handbook may be applied. It is not intended to set new policy or serve as default contract language.[30]

Scope, Technical Evaluation Factors, and Functional Area for Statement of Objective

Scope Language for BPA: “The goal is to implement cloud-based applications utilizing Agile processes that achieve results through continuous capability enhancements, minimal downtime, prompt response to emerging needs, demonstrated reliability, and optimized performance with resource utilization minimized. The scope of the BPA encompasses requirements for [insert certification standard] expert companies to provide the business analysis, development, implementation, enhancements, and maintenance services required to successfully implement the applications within a cloud-hosted environment. The platform will allow the user to provide an environment to build business applications. The Government wants to provide the option of a shared, enterprise service of hosting and platform support to drive down costs, realize efficiencies and allow Agency components to focus on the application rather than hosting. The task orders can be placed under one or all of the Functional Areas: (1) Business Analysis, Development Integration: creation of a technical architecture to establish business application, including development, integration with Agency’s existing systems; (2) Data Management and Securitization: data management may include data migration efforts, securitization with a Government provided third party Encryption tool, and creation of policy surrounding data implementation; (3) Program Management Support: additional support to assist in overall process; (4) Post-Implementation Maintenance Support: for production applications on the collaboration platform; (5) Post-Implementation Development: expansion or updates of production applications to meet ongoing unique objectives and requirements of specific Agency components; (6) Support: ongoing issue tracking and support desk functions for software development; and (7) Training: end use, administrator, knowledge management support for application.”

Technical Factors for BPA: Technical submission should include the following: Factor 1 – Technical Approach to Agile methodology (overview of performance-based solution and quality control and performance measurement approach); Factor 2 – Method for planning and sizing of work to be performed; Factor 3 – Past Performance Information; Factor 4 – Real Technical Factors (unit testing, pair programming, test driven development, approach to refactoring, and design philosophy).

Functional Area for Statement of Objective: Functional Area 1: Business Analysis, Development, Integration - Creation of a technical architecture to establish business applications, including development, and integration with Agency’s existing systems.

Key Personnel: The contractor shall identify key personnel and provide statements of qualifications for these individuals. Key personnel shall be current full time employees, contingent hires will not be accepted as key personnel submissions. The contractor shall identify key personnel who shall be the management lead and the technical lead for the task order as a whole. These individuals must have expertise in the Agile development methodology and experience using many of the tools included in the Development/Test Tool Suite identified previously. The management lead shall ensure that all work on this contract complies with contract terms and conditions and shall have access to contractor corporate senior leadership when necessary. The contractor’s management lead shall be the primary interface with the Contracting Officer’s Representative (COR) and Contracting Officer (CO) and shall attend status meetings and ad hoc meetings with stakeholders as required, accompanied by the technical lead when necessary.

Pricing and Incentives

Agile Language in Award Term Option Solicitation: “For this task order the Government will offer Award Term Options which may encompass future enhancements, releases, development efforts, or operations & maintenance related to the establishment of the platform or the application. Award Terms may only be awarded for an overall “Excellent” performance rating based on mutually accepted metrics. The Government will appoint an Award Term Determining Official (AFDO) who will provide the official performance review and approval for an Award Term Option to be exercised. The AFDO, in conjunction with the CO, will make a unilateral decision as to the exclusion of any portion of the performance period from the evaluation of ratings and calculation of the award term. Award Term Options are not required to be consecutive with the previous period of performance of the base period or additional options. They are contingent on continued Government requirements and funding availability for the platform or application. Award Term Options must adhere to the proposed Agile methodology and processes as awarded at the BPA level unless an exception is provided by the CO prior to award.”

Performance Metrics

Contract performance metrics should be relevant to the proposed methodology and should be tailored to the Agile process. “Offerors shall describe the Quality Control and Performance Measurement approach, including how proposed performance standards will be monitored, evaluated, and reported. The purpose of the notional Quality Control Plan is to provide evaluators with an understanding of how measures and metrics will be applied based on the proposed technical solution. These metrics shall cover planning, inspecting, and understanding progress under time. The metrics shall correspond with the “definition of done” as proposed in the PWS. These may include such measures as sprint/release success rates, defect resolutions, time to market, end user satisfaction, etc.”

Other

Language for Enterprise Engineering Support: “The contractor shall provide capabilities engineering design to improve data interoperability, integrity, and quality for new systems and initiatives. The scope of this contract focuses more on integrating new systems and initiatives into the enterprise. The contractor shall evaluate commercial and Government software, freeware, shareware, tools, techniques, processes and standards. The contractor shall deliver design specifications, technical papers, reports, analyses, recommendations, and Service Level Agreements. The work effort will be performed using the Agile method, with work planned in sprints, periodic sprint reviews and planning meetings and product deliverables planned as releases.”

Language for Maintenance of Software: “The contractor shall maintain the software to include fixing defects, application software, tools, capabilities, and databases for the software applications, and related functionality in support of the user community and the Program Management Office. The contractor shall apply Agile and iterative development methodologies in order to provide timely capabilities to the user community. The maintenance tasks also include maintaining system/software engineering, integration activities, system security, program lifecycle documentation, application documentation, and database documentation required for continued software support and requirements management. Target release timeframes will be conducted in 2-week iterations with releases to production at least once every two months.”


Footnotes

1 “Information Technology” is defined in FAR 2.101.

2 While the FAR offers flexibility in contracting, agencies must adhere to restrictions imposed on the appropriated funds used to pay for IT.

3 The FAR System is established for the codification and publication of uniform policies and procedures for acquisition by all executive agencies. The FAR System consists of the Federal Acquisition Regulation (FAR), which is the primary document, and agency acquisition regulations that implement or supplement the FAR. The FAR System does not include internal agency guidance of the type described in FAR 1.301(a)(2). The FAR is issued as Chapter 1 of Title 48, Code of Federal Regulations (CFR) and is accessible at https://www.acquisition.gov/?q=browsefar. Executive agency FAR supplements are accessible in Title 48, CFR at http://www.ecfr.gov.

4 Agile software development encompasses various Agile methodologies that share the same philosophy, but have their own practices and tactics. Some examples are Scrum, Kanban, DSDM, FDD, XP, etc. Based on the specific Agile methodology being used, note that the requirement document may vary.

5 In this document, “development” refers to software development from scratch, as well as the configuration and implementation of commercially available off-the-shelf items.

6 “The term “contract” is being used generically in this document and may also include purchase orders, task orders and/or delivery orders.

7 See http://www.fai.gov/drupal/certification/certification-and-career-development-programs; https://acc.dau.mil/CommunityBrowser.aspx?id=17631

8 One of the core features of all agile processes is small team size, normally less than 10, with a clearly identified leader.

9 The Contracting Officer is responsible for the determination to use business process innovations in accordance with FAR 1.102-4(e). This determination is distinct from the IPT determination of which Agile methodology will be used. Additionally, the processes used by the agency are subject to any restrictions imposed on the appropriated funds used to pay for the software development.

10 In the 8th Annual State of Agile Survey conducted by VersionOne, 88% of respondents stated that their organizations are practicing Agile software development with the top business benefits being the ability to manage changing priorities (92%), productivity (87%), and project visibility (86%). Source: 8th Annual State of Agile Survey (2013)

11 Less than one-third of waterfall procurements (28%) succeed. Larman, Craig. Agile and Interactive Development: A Manager’s Guide (2001) at 101. Only 20% of features are used often, 30% get used only sometimes or infrequently and 50% are almost never, if ever, used. The Standish Group, Inc., The CHAOS Manifesto 2013. See also Appendix A: Comparison of Traditional to Agile Thinking on Software Development.

12 See Section 804 of the National Defense Authorization Act (2010); FAR 39.103(a); FAR 2.101 definition of “major system.”

13 See OMB Circular A-11 Exhibit 300 Guidance and Contracting Guidance to Support Modular Development for more information on Integrated Product Teams.

14 Agile principles promote “Individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; [and] responding to change over following a plan.” Source: The Manifesto for Agile Software Development.

15 Some users will have initial baselining sprints that may not produce usable software.

16 The term “solicitation” is being used generically and includes RFPs and RFQs.

17 Some practices involve deploying a product more frequently – even more than once per day.

18 OFPP Policy Letter 11-01

19 Note that some agencies view the procurement of Agile IT processes as a commercial method that is being adapted to manage Government requirements. Under a FAR Part 12 Commercial Item purchase, cost type contracts are prohibited. Use FAR part 12 for T&M and Labor Hour, at FAR 12.207

20 Note that a T&M contract may only be used if a determination and findings that no other contract type is suitable is prepared in accordance with FAR 16.601(d).

21 Larman, Craig. Agile and Iterative Development: A Manager’s Guide (2001) at 101.

22 A team’s velocity is the rate at which the team is completing user stories and delivering them to the product owner. A team’s velocity is measured by the sum of story points for each story completed during a sprint.

23 Consideration should be given to the value of top talent agile developers when determining best value because such talent is typically able to deliver more consistently. Agencies are encouraged to factor in the skill of the developer and make a best value determination of the highest quality and most usable software (not necessarily the least expensive) within time and budget constraints.

24 If agencies have experience utilizing an Agile process for a similar size and type of effort, they may feel comfortable with stating the number of sprint cycles in the solicitation (e.g., small development: 1-5 sprints, medium development 6-12 sprints, large development 13+).

25 Effective Practices and Federal Challenges in Applying Agile Methods, GAO-12-681, July 27, 2012

26 The Standish Group, Inc., The CHAOS Manifesto 2013

27 Velocity is calculated by adding up the story points that the team successfully delivers in each iteration (five 2-point stories = velocity of 10). Within a short period of time, velocity typically stabilizes and provides a reliable basis for improving the accuracy of planning. Agile delivery cycles are short in length, so velocity is validated very early in a project and then relied upon to improve project predictability.

28 When meeting with the contractor, caution should be taken to not waive any rights the Government has to terminate for default.

29 Justification and Approval (J&A) is a document required to justify and obtain appropriate level approvals to contract without providing for full and open competition. This does not mean that J&As will never be required with contracts for Agile software development, just that they will not be needed for refinement of system features.

30 This language is mainly compiled from an RFQ for an order against a Federal Supply Schedule BPA. It serves as one example of BPA language. Bolded text highlight Agile software development processes specifically.