DHS FLASH was a grand experiment to develop a truly agile software development contract for all of the Department of Homeland Security. It was impressive in scale ($1.5b) and its innovative prototype-based competition model. 111 firms put in proposals and 11 were successful.

Unfortunately, the contract was cancelled after a protest process. However, procurement and contracting are perhaps the biggest constraint to improving IT delivery for government.

This panel examines this experience to discuss what happened, what went well, and what could be improved. Members of successful FLASH awardee teams will discuss the experience and process, then facilitate a discussion of how to make this model work.

Note: the panel members will be refined in prep for the session. At a minimum, we can get some diversity of vendor participants from winning teams - and would welcome government-side participants as well.

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

What do the commercial world and Federal government share in common? Agile success! Yes, it is true that agile grew from the commercial world and has been a shining story of success there, but the Federal government has been adopting agile’s brilliant ways more recently and has success stories of its own to share.

In getting to the point of successful agile delivery, especially at the organizational level, the Federal government has had to clear many hurdles and transform the way it works. This hasn’t been an easy task and is still in its infancy. The commercial world has cleared its share as well and has many war stories along with their success stories.

This session will be delivered as a moderated panel discussion. Two panelists from progressive Federal programs join two shining examples of agility from the commercial space – and entertaining fellows to boot.  Panelists will discuss topics that provide insight into their organizations and the work they did to implement agile successfully on their teams, across their programs, and throughout their organizations.

• Alastair Thomson is the Chief Information Officer for NIH’s National Heart, Lung, and Blood Institute
• Joshua Seckel is the Applied Technology Division Chief at the USCIS Office of Information Technology
• Nate McMahon is a Vice President of People and Technology at The Motley Fool
• Bob Payne is the Vice President of Enterprise Agile Consulting at LitheSpeed

Ever wonder if a major Federal program has been able to achieve Continuous Delivery or implement a Zero Defects strategy? How have the commercial companies been able to increase their output so well while decreasing risk at the same time? What can Federal organizations learn from the commercial world about agile contracting and procurements? How did commercial companies have to change to enable self-forming teams and could our Federal government, with its myriad contractors and its layers of separation, benefit from the same? What can the commercial world learn from Federal agile success? Do successful agile approaches differ between products and services? What do the Feds see as their next agile conquest on the horizon? What is hot for commercial companies to tackle now?

You will leave this session understanding some of what the commercial world has done to achieve great success with agile. You will also hear about agile success in the Federal government, bureaucracy busting moves, and what the government had to do in order to achieve those feats. Both sides will share their stories, describing the impediments they faced, the benefits they have seen, and even the areas they have not been able to conquer just yet, attempting to drive agile throughout their organizations and into every aspect of their delivery. Panelists will also discuss topics and answer questions the session participants have for them to ensure everyone has an opportunity to take back valuable and pertinent knowledge afforded by these experienced agilists.

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.