Dan Luttrell, Northrop Grumman USC Agile Experiences Workshop March 17-19, 2004 Agile Process in a DOD Environment - One Project’s Experience

Copyright 2003 Northrop Grumman Space and Mission Systems Corp. All Rights Reserved. 2 Agenda  Where We Started  Demonstration Phase  Development Phase  Stumbling Blocks and Potholes  Digging Our Way Out  There Are Benefits to be Gained  Next Time  Conclusion

Copyright 2003 Northrop Grumman Space and Mission Systems Corp. All Rights Reserved. 3 Original Concepts  Build a large system of analyst workstations working across different databases and networks in a rapid iterative environment using agile processes –Abandon traditional “shall” statement based requirements development –Quickly develop a common understanding of how the analysts will utilize the system through a use case development –Developers to be responsible for implementing use cases not individual subsystem components. Everyone responsible for daily integration and integrity of the entire system. –Schedule use case development through a series of priority setting meetings with the customer and users

Copyright 2003 Northrop Grumman Space and Mission Systems Corp. All Rights Reserved. 4 Demonstration Phase  Level of effort, fixed time period, fixed cost, with a prioritized list of requirements to work off. –Work down requirements list as far as possible given the schedule and cost limits. –Very little customer/user interaction. –Use cases developed from contractor knowledge of the heritage system implementation –Demonstration only with no formal sell off –Simulate real databases and interfaces  Successful demonstration held with customer and their management

Copyright 2003 Northrop Grumman Space and Mission Systems Corp. All Rights Reserved. 5 Development Phase – “Reality Sets In”  Customer had high level System Requirements Document (SRD) – No detailed requirements.  We had developed high level use cases without a defined process and plan for developing the detailed use cases –The high level use cases do not directly trace to the high level SRD –We are unsure how detailed the use cases need to be for formally selling off the system in place of shall statements. –We have not resolved how many high level and detailed use cases are needed.  Since we have not resolved this, how will we or the customer know when we are done?  Project has multi layer security requirements that have arcane and rigid standards for what constitutes success –This is a difficult system issue that does not easily lend itself to Agile techniques for solutions

Copyright 2003 Northrop Grumman Space and Mission Systems Corp. All Rights Reserved. 6 Stumbling Blocks and Potholes  Customer and user groups do not agree on –Scope of the system –Priorities of implementation  They ask us to prepare a Chinese menu of mid level capabilities for them to pick from but unfortunately: –The capabilities derived are not independent from each other –Since stakeholders do not agree, priority setting sessions did not work  The customer assumes that agile means that they can redirect us on a daily basis with no impact to the end schedule or cost  The customer’s management asks how many SRD requirements have been satisfied and what is the schedule for completion

Copyright 2003 Northrop Grumman Space and Mission Systems Corp. All Rights Reserved. 7 Digging our way out  Develop standards for what comprises a detailed use case and functional specification that would allow system to be sold off  Tighten up the configuration management of code, use cases, and function specifications  Build a tree mapping SRD to use cases and functional specifications –Or Attempt development of lower level requirements  Difficult to interpret and reach consensus with stakeholders  Other than facilitating sell-off, this would be a non-value added step  In the near term, focus on Security Certification over increased functionality

Copyright 2003 Northrop Grumman Space and Mission Systems Corp. All Rights Reserved. 8 The Benefits  Use Case based requirements provides a better foundation for developing a common understanding of the system  Use Case based implementation with continuous integration and daily builds provides a more stable system earlier and better defect removal than an implementation based upon assigning individual components to each developer –All the implementers see and must understand all of the code to make necessary changes –They identify and debug as they see problems in the code  Early estimates of productivity and product quality show significant improvement over standard process

Copyright 2003 Northrop Grumman Space and Mission Systems Corp. All Rights Reserved. 9 Next Time  Agree with customer on what Agile is and is not  Build a hierarchy of use cases from the start and obtain agreement with customer on what defines completion  Once you deliver the first copy for evaluation, schedule rework effort in every delivery –Prioritize all effort jointly with customer  Multi-level security certification still a tough nut to crack –Don’t assume that agile methodology is going to make it easier. Customer security personnel are not inclined to compromise on requirements  Build in schedule slack for each iteration to deal with working off discrepancies from previous iterations

Copyright 2003 Northrop Grumman Space and Mission Systems Corp. All Rights Reserved. 10 Summary  There are gains to be made in productivity and reduced delivered defects with use case based system specification and implementation –Need to determine the detail required and configuration management required to successfully manage this process –Need customer buy in at the beginning along with agreement on how the system will be sold off. –The cost to refine the system specification from high level to implementation level is still present, but the result of doing this refinement with use cases is a better common understanding of how the system will function at the end state.  Embedded Government representatives with the developers are a necessity for rapid development and acceptance –They must have the authority to make cost/schedule/function trade- offs within the current iteration