Detecting Agile BS in the Department of Defense

I am currently a contractor and Scrum Master at the Software Engineering Center (SEC) of the U.S. Army. Since 2013, I have helped the Army Research Lab (ARL) and am now helping SEC implement Agile/Scrum at Aberdeen Proving Ground (APG). Our SEC contract is currently up for re-compete. This session will give participants a window into real world Agile contracting in the Department of Defense (DoD) using language from the current Request for Proposal (RFP) for our contract.

If you work in a "highly matrixed," command and control organization driven by deadlines where contract language matters, then this session is for you.

I can't promise you the "secret sauce" of making Agile work in the DoD, but I will share the challenges we face and the patterns we are using to nudge the organization toward Agile.

1 favorite thumb_down thumb_up 1 comment visibility_off  Remove from Watchlist visibility  Add to Watchlist

Outline/Structure of the Experience Report

1. Common challenges challenges to implementing Agile in the DoD.

2. Patterns and Anti-Patterns in the current SEC contract language, what they mean and possible mitigation strategies.


Let me quote one section from our current RFP:

C. STEP 10 RETROSPECTIVE: After the Sprint is complete, the team looks back on how the Sprint went. This typically includes all Sprint team members, including the PO. This process often involves discussion on what went well, what went poorly, and areas of improvement. If a Sprint goal fails during the demo phase, the Sprint team will collectively determine during retrospective step 10 if the Sprint goal failure is contractor caused or Government caused. The review results of the Sprint goal failure will be documented (IAW E008 Software Development Plan) and signed by the PL and SM. Sprint goals not completed in a Sprint will be pushed to future Sprint(s). In accordance with C.14.13.8 below, if the Sprint goal failure was the contractor’s fault, any re-work costs paid to the contractor will result in a reduction in fixed fee by the corresponding amount.


We will spend a little time in the session understanding the origins of the Agile B.S. in the above RFP.

Note: The RFP above assumes matrixed, mixed teams with both Organic (Government) and Contract Labor.

Learning Outcome

Participants will be able to:

1. Identify and describe several challenges to adopting Agile in the Government, specifically the Department of Defense

2. Identify anti-pattern (Risks) in government Agile contracts and some mitigation strategies.

Target Audience

Contractors, Contracting Officers, Civilians, Military, Enterprise

schedule Submitted 1 month ago

Public Feedback

comment Suggest improvements to the Speaker
  • George Dinwiddie
    By George Dinwiddie  ~  1 month ago
    reply Reply

    I like these aspects of the submission, and they should be retained:

    • Contracts supporting Agility

    I think the submission could be improved by:

    • Use the Abstract to attract attendees. Describe their problem and tell them what this talk will help them do better.
    • Use the Outline to describe the talk to the reviewers. Let them know what you're really going to do.

  • 45 Mins

    How do you get people to agree on priorities when they may have different objectives? You may be facing an issue now where stakeholders are pushing against each other in order to get their work done first. What would happen if we could create an open dialog among stakeholders and have them understand different perspectives and focus on the goals of the greater good instead of just their own? Let’s face it, proper prioritization is the difference between writing code and developing valuable solutions.

    In this simulation style workshop, you’ll learn practical methods for bringing stakeholders together and openly discuss their different priorities to agree on what’s most important overall. You will see first hand how a combining group discussion with proven prioritization methods such as Weighted-Shortest Job First and (WSJF) and Must Have, Should Have, Could Have and Won’t Have (MoSCoW) work.

  • 45 Mins

    Have you tidied up your personal life with Marie Kondo and are now wondering how to achieve the same effect in your work life? Do you have the feeling that the most valuable product backlog items (PBIs) are getting lost under a mountain of old stories, bugs, and tasks? Maybe you know a change is needed, but feel completely overwhelmed about where to start? If so, join us to learn how to make your product better through the life changing magic of tidying up your backlog.

    We’ll start by exploring the costs of a large, cluttered product backlog and share a short quiz you can use to gauge the current state of your own backlog. Next, we’ll cover how we’ve adapted the KonMari method and introduce five easy steps you can take to get started in your tidying process. We'll share real-life examples along the way, calling out potential pitfalls to avoid (don’t become a storage expert!), and illustrating how story mapping may be the magical backlog equivalent to Kondo’s “vertical folding” technique. By the end of the session, you’ll know the specific next steps to take so that you too can realize the many benefits of a tidied-up product backlog: improved visibility, increased self-organization, and easier decision-making.

  • Liked Thomas Stiehm

    Thomas Stiehm - Shifting Security Left - The Innovation of DevSecOps

    Thomas Stiehm
    Thomas Stiehm
    Coveros, Inc.
    schedule 1 month ago
    Sold Out!
    45 Mins

    DevSecOps uses application security practices that have been around for a while. The innovation of DevSecOps is incorporating security into the daily workflow of the team rather than leaving them to the end of a release like many legacy processes do. Shifting security left is made possible by the ability to automate many aspects of security testing and verification. DevSecOps leverages DevOps practices to make application security a first-class citizen in the practices of modern software product development. DevSecOps starts with a culture change mindset of cross-functional teams creating software through collaboration and fast feedback cycles.

    The security in DevSecOps starts before the code is written by using techniques like threat modeling and risk analysis to help figure out who might want to attack you and how they might do that. This often ignored security practice can be enabled by following the DevSecOps practices of having a cross-functional team involved in the process from the beginning, including security professionals.

    Next, DevSecOps maps application security practices into the build pipeline for a project in order to provide quick feedback about the security posture for any change made to the software. By using automation to allow the team to move quickly while maintaining confidence in the health of the code base, DevSecOps extends that health check to include application security checks. While automation can be used to make security data collection easier it is important to understand what security practices still require a human being.

    This talk focuses on how, when, and where practices should be incorporated into a build pipeline to get the most value out of your security practices through automation. It explores what manual security work still needs to be done by a person and how to maximize value while minimizing the effort of human beings.