Often, we will use the phrase agile acquisition when we really mean acquisition for agile. Both agile acquisition and acquisition for agile are necessary to deliver efficiently across government organizations. The processes within the federal government for doing acquisition means that we may spend a year or more to award a contract for work to begin. This creates a significant delay is beginning projects or programs that impedes the speed of delivery. Instead, we need to move toward a true agile acquisition process where we change how we execute acquisition so that we can begin delivery in much faster fashion.

This workshop will examine how to change our acquisition processes to become more agile and able to support the delivery of IT services in a much faster manner. We will look at both successes and failures in acquisition and determine what changes need to be made in order to meet the quickly changing needs of government. Both contractor and employee viewpoints will be considered and discussed. We will look specifically at ways that government is trying to make these changes in the DHS Procurement Innovation Lab, the Office of Federal Procurement Agile training, as well as others and how those activities may play into your organization and procurement activities.

Agile is executed many different ways across projects and programs. But it is necessary to track and report progress against the enterprise goals and mission. Within government, using a metric like ROI is not as useful for comparing programs as the more basic issue is meeting mission needs for services delivered rather than making a profit.
With passage of FITARA, issuance of the digital services playbook and TechFAR, and departments updating their System Engineering Lifecycle and issuing agile guidance and policy, there is more official agile push than ever before. Additionally, OMB300's TechStats, and other mandatory reporting remain a constant within the federal government. However, programs will execute agile adoption in unique ways because of short feedback loops and inspect and adapt cycles within the execution of any program. The best department and government level guidance allows for this to provide a forum for experimentation and improvement within delivery of value. Even if one agency or department tries to standardize, the overall government is unlikely to settle on one way of actually delivering software. Of course, many agencies are not focused on one way of executing and are focused instead of delivery.
With the fifty (or more) shades of agile across the federal government, how can congress, or even just heads of departments, provide sufficient oversight and ensure that the mission needs are met?
This presentation explores the different ways that government agencies are executing agile and how those programs can still provide the information and insight to provide executives the ability to manage the large scale direction of the government entities

We have heard a lot about no defects or zero defects, but is that reasonable or achievable in the government context?  How else can each sprint be deployable? Or how can you get to true flow with each story deployed to production?

 This session will explore how to get to a no defects posture across all of the tests required in a government setting. 

We will look at the various types of testing:

Unit, Functional, Integration, Security, 508, System, User Acceptance, etc 

We will look at what defects mean and how (or if) they should be tracked

We will look at what potential impediments from government organziations may exist in reaching a no defect state of software delivery

We will look at what tools and techniques can be used successfully in the government setting to address the impediments and achieve no defects in released software

Retrospectives are great! They result in great process changes for a team to adopt to become more efficient.

But how do you determine when the process change adopted by one team should become part of the overall recommended practice for the organization?  What worked in one team very well might not be helpful or effective on another team, and at the same time, the organization needs to take advantage of the innovation happening at individual team levels and adopt the best ones as recommendations.

This talk will look at a more formal method of tracking the effectiveness of specific retrospective improvements and how to decide when to make team process changes into organizational recommendations. This will show how to us Bayesian Statistics to track the effectiveness of specific process improvements and setting threshholds for organizational wide recommendations can lead to a good process for organizational process improvement based on team successes.

Specifically, we will look at how to set up the process at the organziational level and the team level:

      What processes need to be agreed to?

      What changes in governance need to be agreed to?

      How to decide when to make recommendations?

      What changes should be made at the team retrospective level?

I will also discuss how this experiment is working and what we have learned from trying to adopt this methodology.

This method should be very helpful within organzations with high oversight and governance, such as the government, to allow for continuous process innovation while still maintaining concurrence from those bodies.