Agile Development in the Federal IT Environment

Transcription

1 Agile Development in the Federal IT Environment Presented to CMMI Conference: North America

2 AGENDA Agile and Waterfall Agile Manifesto Federal Government Adoption of Agile Principles Federal Acquisition Management Challenges Software Estimation Approaches Framework for Developing Cost Estimates for Agile Projects Case Study 2

3 AGILE AND WATERFALL Agile Software development paradigm involving time-boxed development, small multifunctional teams, evolving requirements, test-driven development, and early delivery of functional software Agile umbrella represents adaptive software development methodologies (Rational Unified Process, Scrum, Extreme Programming) popularized in the late 90s Agile was a response to heavyweight waterfall methodologies, which some consider rigid, unresponsive and with high management overhead. Waterfall Sequential, serial process where milestones must be reached to move to next phase Inherited from the hardware manufacture strategies and construction strategies that were in practice during the 1970s. Easier to baseline and manage, and enforces requirements solicitation at inception Testing issues not identified up front, functional software is not delivered until end of project 3

4 WHAT IS AGILE 5

5 AGILE MANIFESTO Developed by the Agile Alliance in 2001 ( 4

6 FEDERAL GOVERNMENT S ADOPTION OF AGILE 2010 Federal IT Reform Plan 1 identified that technology has outpaced budget formulation in regards to modular development contracting Office and Management and Budget (OMB) and Congress were asked to create working capital (revolving) funds Office of Federal Procurement Policy (OFPP) was tasked to develop contracting guidance and templates to increase modular contracting flexibility All of this was a shot in the arm to the Agile community! OFPP has not yet issued this guidance, or the required templates and samples supporting modular development. An OFPP official explained delays due to challenges in ensuring consistent definitions of modular development across the government and industry (GAO As of 2012, GAO reported this objective has only been partially met. OFFP did deliver contracting guidance in Kundra, Vivek. 25 Point Implementation Plan to Reform Federal Information Technology Management. U.S. Chief Information Officer. Dec 9,

7 ACQUISITION MANAGEMENT CHALLENGES Two years later, GAO identified agile implementation challenges that include Procurement practices do not support agile projects, as some federal contracts have waterfall criteria Teams had difficulty collaborating and transitioning to self-directed work Difficulty in adopting of Agile tools Inconsistent software development guidance (strategic guidance aligned to waterfall practices) EVM and status tracking does not conform to agile principles 7

8 FRAMEWORK FOR ESTIMATING AGILE PROJECTS Iterative development did not begin with the Agile Manifesto, and traditional estimation techniques can still be leveraged Agile projects are not inherently more or less productive Process 1. Size project according to conventional methods (requirements-based sizing, analogy) and express in SLOC or function points 2. Confirm and model typical Agile tenants (Experienced, cohesive team, focus on internal communication, complex integration reduced documentation) 3. At each sprint, calibrate productivity (at team level, not Story Point level) 4. Include delivered scope as risk if not mandated contractually 5. Leverage Agile tools wherever possible, which can serve as database of project You can t estimate the impact of a paradigm; you can only estimate the impact of the practices that may occur as a result of that paradigm -Arlene Minkiewicz, PRICE Systems Chief Scientist 9

9 SOFTWARE COST ESTIMATION CHALLENGES Software cost estimation has traditionally been based on software size (SLOC or function points) for requirements identified at inception, software complexity and other factors Productivity is typically analyzed in SLOC/Person month Scope is generally fixed, while team size and schedule are variable Agile projects are baselined from iterations (sprints) and story points per sprint (velocity) Each sprint s stories are determined at the beginning of Sprint planning Story points are a measure of expected effort based upon size and complexity Story points differ by team and are inherently subjective In Agile, schedule and team size are fixed while scope is variable Government oversight agencies lack familiarity and acceptance of Agile metrics 8

10 CASE STUDY COMMERCE The Problem An ongoing Agile project at Commerce identified the following A hybrid of Agile and Waterfall was implemented causing confusion and management problems Agile Program Management tools were not used Developers did not follow software design (cowboy coding) Limited support of Senior Management Poor metrics collection Software testing identified many requirements that could not be tested due to dependencies to other open requirements Software did not meet requirements 10

11 AGILE PROJECT MANAGEMENT TOOLS Agile PM Tools are useful to track monthly performance Automates velocity and assists with schedule planning

12 CASE STUDY COMMERCE The Solution /Compumatics team implemented market survey and tested Agile tools implemented project management tool, Agile training, and metric collection process Management, developers, and our team collaborated to rebaseline the development schedule Organic development team was assisted with determining story points for open requirements (stories) Remaining estimate was updated through traditional software estimation methods (function point analysis, calibration, parametrics) 11

13 Q&A 12

14 LOCATED IN THE CITY OF FALLS CHURCH, VA Picture of George Mason Square 13