Documentation in Agile Development Christina Gu Jason Lee Stephen Smith

Agenda Background Problem Statement Methodology Agile Overview Literature Search Case Studies Scrum Agile Document Development Framework (S.A.D.D.) DoD’s effort to embrace Agile Conclusion and Recommendation Website Reference Questions?

Background The current economic situation is driving contractors to look at more lean operating methods for project development. Especially true for government contractors working with the Department of Defense. One method pursued is to switch from a waterfall model to the more lean Agile method. Figure 1: Defective and Wasteful Requirements in Traditional Development Process [4]

Problem Statement Sponsor: Boeing Problem statement: Deliverables: Is Agile sufficient for satisfying documentation needs on DoD mission-critical systems? How is documentation impacted by adopting an Agile methodology? Deliverables: Report on Agile’s ability to meet documentation needs with a framework developed for documentation generation.

What is a mission critical system? Systems critical to DoD’s ability to meet its responsibilities and include command and control systems, satellite systems, inventory management systems, transportation management systems, medical systems and equipment, and pay and personnel systems

Documents of primary interest Milestone Review (Per DoD 5000) Documentation of Relevance SRR SSS – System/Subsystem Specification SRS – Software Requirements Specification IRS – Interface Requirements Specification PDR SSDD–System/Subsystem Design Description SDD – Software Design Description IDD – Interface Design Description CDR TEMP- Test and Evaluation Management Plan SEP- System Engineering Plan Figure 2: Technology or Initiative Transition to Program of Records (MITRE, 2010)

Methodology Literature research Case studies Ideas behind the Agile method and how it impacts documentation Existing methods for generating documentation in Agile Case studies Interview various companies with regards to projects using Agile. A look at the approach to documentation used in each of the projects.

What is Agile A set of software best practices strung into an official set of principles in 2001 as the Agile Manifesto. Principles of Agile: Individual and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Respond to change over following a plan

Key Aspects of any Agile Methodology Agile Methodologies Iterative Planned modification of parts of the system. Assists with modification of design and requirements Incremental Develop parts of the system separately and integrate. Assists with improving overall methodology Self-Organizing The team has the responsibility of organizing its internal dynamics. Emergent The set of tools, techniques, development environment, and requirements emerge in the process

Agile Misconception Agile is a “Pizza Box” Methodology Agile is an All-or-Nothing Methodology Traditional Development is Inferior Becoming Agile Only Affects the Developers

Scrum Agile Key Components of Scrum Agile: Origins of Scrum Cross-Functional Teams Product Backlog Timeboxed Development Iterations End of Cycle Origins of Scrum Japanese OR Advancements Incremental Development in the U.S. Object Oriented technologies in software

Scrum Agile http://www.scrumalliance.com/pages/what_is_scrum

Traditional Systems Engineering Documents Generation Traditional Systems Engineering Document Generation vs. Agile Systems Engineering Traditional Systems Engineering Documents Generation Agile Systems Engineering Document Generation SRR REQUIREMENTS -->SRS, IRS, SSS, etc. SDR System Design Review --> SEMP PDR Preliminary Design Review -->SDD, IDD, etc CDR Critical Design Review --> SEP, TEMP

DoD’s Effort to Embrace Agile The DoD is in the process of changing its Defense Acquisition Guideline to better serve Agile Software System Development Figure 3: MITRE’s suggested DoD IT Acquisition Process [2]

Principles of Agile Documentation Generate “just enough” documentation Should satisfy the objectives of the use for the documentation. Do not generate if not planning to be used. Used to transfer knowledge in the team and between teams. Agile tends to keep knowledge within the team. Knowledge transfer is essential for add-on projects

Two Approaches to Documentation in Agile Method 1: Adapted Agile Use DoD standards as binding constraints to the Agile effort. Documentation must be generated to support periods of customer reviews Full and complete documentation expected Plan a full documentation update with each appropriate iteration with emphasis on the last iteration to generate complete deliverable documents. Ideal for contracts already in work with waterfall style program management.

Two Approaches to Documentation in Agile Method 2: Aligned Agile Documentation is generated as needed during the Agile implementation. Customer understanding of the differences in Agile method is essential. Customer must agree to less documentation that is generated only to meet documentation objectives. In-progress reviews and supporting documentation are also broken down to match better with shorter development iterations. Ideal when terms of documentation can be negotiated with the customer. Suggested for company-wide migration towards the use of Agile methods.

Project Case 1 Raytheon Method: Scrum Agile Documentation method: Adapted Agile Size of Project: 6 months Notes: emphasis on generating documentation to meet customer review dates, heavy on documentation updates on the last iteration

Project Case 2 MITRE Method: Hybrid Scrum Agile Documentation method: Adapted Agile Size of project: 3 years Notes: Used a requirements governance council. Phased project according to spiral development ideas but fit with Agile development on every spiral.

Project Case 3 MITRE Method: Hybrid Scrum Agile Documentation method: Aligned Agile Size of project: 1 year Notes: Most documentation was done after the fact to reflect the true state of the system and to reduce rework on documentation. Placed heavy emphasis on labeling documentation as complete only if it can transfer knowledge to a team that has not previously worked on project.

Project Case 4 MITRE Method: Hybrid Scrum Agile Documentation method: Aligned Agile Size of project: 2 years with 4-week long sprint cycles Notes: Used a requirements committee to continuously align with customer needs. Heavy emphasis on documenting requirement changes.

Key Concepts of the Framework Designed to align with Scrum Agile Integrates to become a seamless part of Scrum Agile The Core Concept: Definition of Done

Framework Detail (1 of 2) Examine Required Documents Perform detailed analysis of projects documentation requirements defined by stakeholders Finalize Contract Agreement Reflect any changes/additions and finalize contract in terms of documentation requirements Develop Product Backlog Add relevant tasks associated with documentation to Product Backlog

Framework Detail (2 of 2) Sprint End of Cycle Review Work on document(s) End of Cycle Review Evaluate completed work on document against definition of done. Present current work to stakeholders for review. If completed, handle accordingly, if not, prep for next sprint.

Conclusions The Agile methodology can be used to satisfy documentation needs for mission-critical software development for the department of defense with some modifications from its pure form. Customer interaction and acknowledgement of the differing needs for documentation using Agile is key.

Website For more information please visit our website at: http://mason.gmu.edu/~slee32/index.html

Reference Larson, E., Peters, J. Preparing the U.S. Army for Homeland Security: Concepts, Issues, and Options, Issue 1251. RAND Corporation, 2001. D. K. M. R. B. M. C. Carlton Northern, Handbook for Implementing Agile in Department of Defense Information Technology Acquisition, The MITRE Corporation, 2010. Standish Group. (2010). Chaos summary 2010. Boston, MA: Author. Session R. (2009). The IT complexity crisis: Danger and opportunity, Houston, TX: Object Watch. Beck, K., Beedle, M., Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., et al. (2001). Manifesto for Agile Software Development. http://agilemanifesto.org/ Accessed April 24, 2013.

Reference- cont. Scrum Is an Innovative Approach to Getting Work Done. The SCRUM Alliance (2010) http://www.scrumalliance.org/pages/what_is_scrum Accessed April 27, 2013. Burton, D., Hammons, C., Lapham, M., Schenker, A., Williams, R. (2010) “Considerations for Using Agile in DoD Acquisition.” http://www.sei.cmu.edu/reports/10tn002.pdf Accessed March 19, 2013. I. G. Stamelos and P. Sfetsos, Agile Software Development Quality Assurance, Idea Group Inc (IGI), 2007. [also steve figure 1] C. G. Cobb, Making Sense of Agile Project Management: Balancing Control and Agility, John Wiley & Sons, 2011. P. Schuh, Integrating Agile Development in the Real World, Charles River Media, INC, 2005.

Reference- cont. K. S. Rubin, Essential Scrum: A Practical Guide to the Most Popular Agile Process, Addison-Wesley, 2012. Ralph Hughes and the Ceregenics Data Management Team, Agile Data Warehousing, Delivering World-Class Business Intelligence Systems using Scrum and XP, iUniverse, 2008. Forward, A. (2002) Software Documentation – “Building and Maintaining Artifacts of Communication,” www.site.uottawa.ca/~tcl/gradtheses/aforward/aforward_thesis.doc Accessed March 30, 2013. DAGS (Defense Acquisition Management System), Enclosure 2 of DoD Instruction 5000.02, Operation of the Defense Acquisition System, Defense Acquisition Guidebook Dr Steven J. Hutchison, Achieving Enterprise Agility in DoD IT Acquisition, 2010

Reference- cont. K. A. Saleh, Software Engineering, J. Ross Publishing, 2009. R. Mall, Fundamentals of Software Engineering, PHI Learning Pvt. Ltd., 2009. D. Panchal, "Scrum Alliance," 03 September 2008. [Online]. Available: http://www.scrumalliance.org/articles/105-what-is-definition-of-done-dod. [Accessed 27 April 2013]. Scrum Alliance, "Scrum Alliance, Transforming the World of Work," [Online]. Available: http://www.scrumalliance.org/pages/scrum_artifacts. [Accessed 4 April 2013].

Questions & Comment