Project success =  f (listening, feedback, intentionality, practices) 

To make your agile practices and processes come to fruition, you need to cultivate an environment that promotes listening, learning, inquisitiveness, intentionality and top notch feedback that everyone is comfortable with. 

Agile projects succeed when there are frequent high-quality reinforcing feedback loops. I will share communication models based on Clean Language questions of David Grove and the Systemic Modelling techniques of Caitlin Walker that can greatly increase clarity, sense of purpose and listening skills within your team and collaborative endeavors.  These include: Clean Questions, Clean Feedback, and Clean Setup.

This is a hands-on, try it out, concrete practice session.

Great systems require active, capable Product Owners.  Functional innovation is not possible without their commitment and involvement in the project.  Too often in government contracting, the Product Owner is an Absentee Owner.  Agile Development teams often seek out tools and techniques to create great systems, however too frequently what is holding them back is the lack of an engaged Product Owner. Teams in this situation must face the elephant in the room if they desire to build a system that brings positive change in efficiency, productivity, quality, usefulness, and adoption.  This talk shares solutions I have used for challenges I see again and again on government contracts.

The talk begins with some introductory material on the problem, its causes, what I mean by functional innovation, and why this is required to build great systems.  I describe four challenges with Product Owner engagement that are not unique to government contracting, but that I see recurring on projects: committing staff, procurement practices, role ambiguity, and absentee ownership.

1. Many federal government organizations have a requirement to perform independent verification and validation (IV&V) of software development projects for purposes of risk identification and compliance
2. As more federal agencies move towards agile, they will need to devise agile-appropriate methods for evaulating agile teams and contractors for process performance and project risk identification
3. Traditional approaches to IV&V are heavily biased towards waterfall, gate reviews, and traditional SDLC artifacts and hence, do not work well within an agile envrionment
4. Agile programs have their own process-specific risks and issues that need to be evaluated uniquely.  The document-centric approach that has traditionally been used is innapropriate and ineffective for agile teams as it does not find the right risks and does not find them early enough in the development process.
5. We at DHS/CIS have developed a unique, agile-appropriate IV&V model for a large agile transformation effort within DHS
6. The model is used to discover process risks, design risks, code risks, and testing risks in real-time for agile teams
7. The model serves as actionable and real-time feedback to teams, contractors, and federal managers that can be used for process improvement, vendor evaluation, and as a means to find and elevate delivery risks on agile projects
8. Positive results, challenges, and recommendations related to the development, roll-out, and execution of this agile-appropriate IV&V model will  be shared

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

Many agile initiatives suffer from a feeble launch.  As Aristotle once stated “Well begun is half done”.  Performing the activities associated with developing a sound charter can help increase the likelihood of success for a team or organization .  

Beginning with the end in mind, we use retrospective techniques to develop consensus around objectives, vision, and mission.  In this workshop we introduce the components of a good charter and how those components help focus the teammates toward a common goal.  In addition, the development of the recommended charter components ensures that key questions are succinctly answered during the kickoff of a team.

Participants will learn the various types of charters and their recommended content.  During the workshop activity teams will develop a complete charter based  team of their choice or a provided case study.

Agile emphasizes self managing teams that regularly change how they work to improve productivity. Auditors and examiners want to ensure that management is actively providing oversight and that the team is following a consistent and repeatable development process. Continuous Delivery and Infrastructure as Code requires operations engineers to commit code into source code control systems and it encourages developers to have sufficient access to help troubleshoot production problems. Meanwhile, auditors and examiners are strong believers in separation of duties. These are just a few examples of how new development processes are creating serious challenges for audited and regulated companies. Given the conflicting priorities, how is a highly regulated or audited company supposed to implement either Agile or Continuous delivery without violating the core principles of these development approaches?

In this talk we will review 25 actionable items to help position Agile and Continuous Delivery so that your next audit is a success. Come with your own challenges as well as items that you are implementing so that the discussion period at the end of the presentation can include a meaningful session on additional tips and tricks you are employing or find solutions to your particular challenges.

In large Government and Commercial organizations with many interacting systems, architecture is necessary to collaborate effectively across disparate entities and systems. Traditional command and control approaches to architecture are often ineffective and cause great tension, especially when Agile efforts are part of the portfolio. We will discuss two principles, Vision and Partnering.  These principles provide insight and get results for both architects and Agilists; and present tools and approaches on how to effectively engage architects and architecture.

The White House recently created a new Government Digital Services group to deliver “customer-focused government through smarter IT.” As part of this announcement the Office of Management and Budget released the “Digital Services Playbook” and an accompanying “TechFAR Handbook for Procuring Digital Services Using Agile Processes” to make it easier for agencies to procure and implement agile.

In this session, we’ll review the TechFAR handbook objectives, key components and recommendations for getting agile adopted in your agency.

This session will be an interactive exploration of how delivery teams, product owners, and organizational stakeholders can get their "story cargo" moving without first having to tear down the mountain range or create a fission-powered maglev train to carry everything including an army of kitchen sinks.

Large organizations - especially Government ones, like to talk about change, but mostly they appear interested in changing everything but themselves.  Based on the concept of "The Little Engine That Could", this session is designed to help you examine ways to use Kanban and SAFe principles to get your release train accelerating even when you are being asked to haul MONSTER epic stories along the tracks that seem to be climbing up sheer cliffs of compliance regulations.  

Bring your favorite "Franken-story" examples and be prepared to have fun talking about ways of getting them over the mountain range.

United States Citizenship and Immigration Services (USCIS) decided to shift thier agencies current Transformation to include changing the entire development process all at one time. This included utilizing multiple contractors, shifting to a DEV/OPS structure, using a new cloud enviroment, transitioning from COTS to open source software all while introducing Agile concepts to the development team. This complete overhaul of "business as usual" was a complete culture shock to the enviroment and required close colloboration and consistent communication in order to create change and progress. As the Release Manager during this transition I will speak the lessons learned and how the team was able to progress after the introduction of so much change at one time, all while ensuring Government requirements were still met.

One of the values of the Agile manifesto is working software over comprehensive documentation. However many agile teams think that now we are Agile we don’t need to document. Come to this session to learn about lightweight documentation and how to strike a sensible balance between working software and documentation. Learn which documents are necessary and which documents you can do without as well. Learn about JIT lightweight alternatives to our tradition documentation set. Leave with specific techniques to evaluate the value of each document along with recommended alternatives.