Agile SE/Governance

1. Agile SE/Governance

2. Participants Charles Brown Nathan Scoggin Dennis Barnabe James Nemes Leslie Blackham JoAnn Lane Eliot Axelband Forrest Shull John Colombi Scott Lucero George Polacek Brett Peters Stas Tarchalski Facilitators: Ali Mostashari; Judith Dahmann

3. Agile SE/Governance Frameworks for structuring system development efforts that enable rapid, adaptable, incremental delivery of value, guided by an overarching governance and enterprise architecture Original Statement

4. Agile SE/Governance Frameworks for structuring system development efforts that enable rapid, adaptable delivery of value, guided by overarching governance Removed ‘incremental’ because this is a potential solution Enterprise Architecture What is the relationship between enterprise architecture and agility? Is it a hindrance or a help? Addressed EA in a very limited in the discussions Updated Statement

5. Problem Definition (1 of 4 ) Current traditional developmental models follow waterfall/V model with clear discipline and oversight When developers follow alternatives to the full process, they tend to reject the current SE models but the alternatives don’t provide basis for discipline/oversight If you don’t use the full process you tend to go ‘seat of the pants’ On an ad hoc basis, exceptions are granted for ‘heroic’ efforts The governance issue When you step away from the traditional V model/5000 approach, today the only option seems to be an ad hoc approach But is the current model really the problem? An example, GPS3a, has followed a V model with success with agility This was accomplished through the way the V model was implemented So what is the source of the problem? We may not be using the V model effectively Naïve implementation of the V may miss implementation options Really good people can take any model and be successful

6. Problem Definition (2 of 4 ) Urgent needs are met quickly with the objective of rapid response Heroic responses to meet immediate needs Trade development structure and oversight for rapid response An example: Need for networking of sensors which was rapidly supported with an in the field implementation of a SW solution to Immediate near term needs Discipline/reviews etc. was provided naturally by the constant reality checks of use of the new capability in the immediate operational environment What about the middle? Not an immediate user need but also not a large or complex system

7. Problem Definition(3 of 4) Can we develop an alternative approach which allows agility but provides discipline without full traditional SE/5000 ? Need an approach which average folks can be successful most of the time Are we in a business where we should leave this to average folks?) What is the process for Delivering capability to the field in 2-3 years or less Teams of 5 to 300 When 70% solution quickly is preferred to a more complete solution much later What type of development are we talking about? Full traditional SE/5000 process is for large buys or basic foundational systems SW on commodity hardware …. This type of system may be a different class of system than the large complex platforms or weapon systems Pace of change, means that the current model is too rigid for even for large complex systems Now that everything is networked, it becomes even more important to find effective ways to manage agile systems given their role in these larger ‘systems’

8. Problem Definition(4 of 4) Realistically there is no one process model which fits all situations….. however, in reality “Tailoring” only works if you have an exceptional situation In actual execution, few things are ever really eliminated Implementation (DIDs etc.) is focused on the full traditional process NSA dilemma Lots of innovation to address new and emerging problems in creative ways Need a way to appropriately apply discipline to these agile developments If you go to the full SE/5000 approach, you kill the innovation Problem summary There are circumstances where is agility is needed There are multiple impediments to doing things in an agile way When folks do ‘agile’, they walk away from the traditional SE process (or they walk away from the formal governance process) How do you apply SE to agile developments? What is the framework for SE in an agile development?

9. Dimensions of the Problem Obstacles to effective application of SE to support ‘agile development’ Organization Culture Processes Human capital Law Contractual issues (DIDs for standard process) Tools Wrong (or lack of) metric and measurements (incentives) How can we address these different dimension of the problem?

10. One thing we did agree on… There is no known approach to address all of these problems; this is a rich SE research area

11. Research Approaches Review the experience and distill successful practices Build on the urgent needs approaches based on continued iteration, regular reality check Consider an appproach based on parallel tracks of (1) deliberate spec driven development of one increment and (2) agile future looking development, defining the next increment Prototype early and iterate based on feedback from use Assess other existing models (e.g. ICM) Move from SE checklists to menus of options and calculate the risks associated with ‘skipping steps’ What risks are you taking when you adapt the process? (e.g. Speed/agility vs risk) Translate choices into risks and costs/savings in $ or time Automated tool to calculate this? Tools to automate basic SE processes (e.g. CM) Allow you to operate in a more agile way (more concurrently) but still maintain system integrity

12. Research Questions (1 of 2) How can you assess risk of an adapted DoD/IC process? What is the risk of not implementing steps in the traditional development/SE process? Scalability of agility? How big can an ‘agile’ process be? Agile SW development calls for tailoring up vs tailoring down; Can we apply this to systems? Experience vs agility. Agile processes call for mid to high capability people; can you really do this with ‘average people’ Agility metrics, how do you measure progress in an agile development? Types of agility – HW, SW, People Feasibility of continuous evaluation; Can you do this on a system, does it vary by type of agility?

13. Research Issues (2 of 2) Enterprise Architecture (EA) - Can you use EA as a platform to hang things on? Can you invest in the EA upfront as framework to enable rapid development of new capabilities How do you create the incentives to develop and adopt the ‘right’ standards to enable agility? We understand the agile SW process; Is there an agile SE process? SE aspects of ‘open source movement’; tension between discipline and control and an open, uncontrolled approach with opportunities Concept of ‘layers’ Different types of initiatives may need to have different approaches Current layers are defined by cost Are there other (better) ways to differentiate among types of systems and more effectively map SE/governance approaches to the layers

14. Contrasting Current SE Processes with Agile SW Principles Documents vs working product “Working product is the primary measure of progress” Product delivered at end of incremental development process vs frequent deliveries “Early and continuous delivery of working product” & “Deliver working product frequently” Freeze change vs encouraging change “Welcome changing requirements, even late in development” Structured interaction at key review points/milestones vs continuous interaction “Business people and developers must work together daily throughout the project” Repeatable process with ‘average’ SEs vs need for exceptional performers “Build projects around motivated individuals Give them what they need and trust them to get the job done” Communication via documents vs face to face exchange “Face-to-face conversation is best communications means” Objective is to address full set of requirements vs pursuing the minimum essential “Simplicity--the art of maximizing the amount of work not done--is essential” Formal structure vs self-organization “Best architectures, requirements, and designs emerge from self-organizing teams”

15. What is Agile? Agile SW Manifesto Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.