1. Backlog
1.1. Contractual Support for Agile
1.1.1. DoD acquisition process is not structured for Agile
1.1.2. Contractual constraints are the biggest impediment to us implementing standard agile processes.
1.1.3. The milestones and deliverables that are put in place to ensure the customer is delivered what they need, unintentionally inhibit the ability of the consumer to shape the product as their priorities change.
1.1.4. Perhaps the biggest problem is the contracts that we work are all written for waterfall, and so there is a disconnect to begin with.
1.1.5. The old waterfall method strongly engrained in the DoD acquisition process adds challenges to agile development, however, the very nature of agile helps to mitigate the risks
1.1.6. Budget versus requirements satisfaction
1.1.7. Customer contracting office prefers to definitize rigid scope before award.
1.1.8. How to construct contracts that work with short iterative release cycles.
1.1.9. How to reduce proposal preparation costs and build in flexibility to scope after contract award.
1.1.10. How to make a flexible Agile Development environment match up with DoD needs for firm requirements satisfaction within current contract scope.
1.1.11. Customized processes created to implement Agile are difficult to manage due to the requirements of the contract
1.2. Implementing Agile
1.2.1. Understand other program's viewpoints of Agile and how they mold the process to fit into the defense environment
1.2.2. Learn about the successful applications of agile practices in acquisitions
1.2.3. The benefits and setbacks to using the agile process
1.2.4. Bringing Agile methods on to the gov't side of applications development/maintenance
1.2.5. How to implement agile but still meet defense artifact requirements in regards to testing mainly but also things like gate reviews, program milestones
1.3. Collaboration
1.3.1. Understanding both government and contractor perspectives (building trust)
1.3.2. Insight to tasks worked by team members and their priority
1.4. Volatility
1.4.1. Changing priorities and funding availability
1.4.2. Requirements management
1.4.3. Lack of control over total development, test, and production environments.
1.5. Acceptance of New Methodologies
1.5.1. Customer and software developers acceptance of new methodologies.
1.5.2. Paradigms associated with "the way we've always done business"
1.5.3. Organizational inertia makes change difficult
1.5.4. Management shift from command and control to servant leadership / Agile coaching
1.5.5. Agile not fully embraced; lack of training/experience
1.6. Org Structure
1.6.1. No Product Owner
1.6.2. Agile roles when applied in Defense
1.6.3. Stovepipe organizational structure not always supportive of Agile team environment
1.6.4. Detailed planning is required to ensure tasks are being worked when coordinating with other teams to prioritize work.
1.6.5. How can we transition these separated groups into cross functional teams and knock down the barriers between us.
1.7. Training/New Skills
1.7.1. Development infrastructure does not support agile software engineering practices
1.7.2. Untrained product owners
1.7.3. Weak and poor requirements and testing
1.7.4. No teams with the range of skills for modern software developement and software tools
1.7.5. Way too many software languages and technologies to maintain
1.7.6. When is estimating performed and how are different level of requirements handled/gathered (e.g. system, technical [software], derived) during the Agile process?
1.7.7. Test Driven Development (TDD) and Frequent Refactoring
2. Agenda
2.1. Introductions
2.2. Review Backlog
2.3. Presentation on Agile ROI
2.4. Offutt Case Study
2.5. Questions?
2.6. Future efforts
3. Introductions
3.1. Organizers and Speakers
3.2. Purpose
3.3. Where is everyone from?
4. Sally Elatta
4.1. Business Value/ROI of Agile
5. Offutt Case Study / Col John Shepley
5.1. Career Background
5.2. What went wrong with product development?
5.2.1. DoD Acquisition Cycle
5.2.2. War Fighter needs changing rapidly
5.2.3. Frequent funding changes after requirements defined (e.g. sequestration)
5.2.4. Delivered SW not what the user wanted
5.3. Enter Agile
5.3.1. Transparency
5.3.2. Users can talk directly with developers
5.3.3. Tools
5.3.4. Ability to adapt to evolving requirements
5.3.5. Incremental delivery
5.3.6. Product owner
5.4. ORM
5.4.1. High priority/risk features can be delivered first
5.4.2. Funded efforts in smaller segments to encourage delivery of functionality and halt low performing efforts
5.4.3. Frameworks such as Scrum enforce frequent inspect and adapt loops
5.5. How to encourage Agile Practices?
5.5.1. Ensure actual users are involved upfront when defining deliverables
5.5.2. Ensure milestone do not restrict ability to delivery features based on user priority
6. Questions?
6.1. How do you approach Competing Priorities vs Lack of Capacity?
6.2. How do we Achieve a Higher Level of Trust
6.2.1. Demos every iteration earn trust on both sides