Detecting Agile BS in the Department of Defense (And What to Do About It)

I am currently the Scrum Master at the Software Engineering Center (SEC) of the U.S. Army. Since 2013, I have helped the Army Research Lab (ARL) and the SEC implement Agile/Scrum at Aberdeen Proving Ground (APG). 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.

Update 8/23: Our contract has just been awarded to General Dynamics (GDIT). I will be part of the transition team to bring them onboard, giving background on the Agile implementation at SEC. This is why I have proposed this as an experience report. The incoming contractor often has no idea what they've just signed up for in Government Contracting. Often called the "winner's problem," successfully executing against a poorly written RFP, including an "Agile" one, is common in the federal space.


Outline/Structure of the Experience Report

1. Detecting Agile BS and the reasons for Agile BS.

2. Patterns and Anti-Patterns in the current SEC contract language and it possible origins. Agilists, please update your Agile/Scrum information!

3. Possible mitigation strategies for Agile BS.


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.


Read the above again. The Retrospective is supposed to be used to assign blame for "missed" Sprint Goals.

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

In my experience report, I will show how the Army Contracting Command (ACC) has cherry picked wording from a previous Scrum Guide, using the Sprint Review as a "Report Card" that leads to assigning a "grade" and "punishment" in the Retrospective.

Learning Outcome

Participants will be able to:

* Better detect Agile BS in Government RFPs.

* Identify several common reasons why RFPs have Agile BS.

* Describe several "plays" you can use to nudge the Federal Government to become more Agile.

Target Audience

Contractors, Contracting Officers, Civilians, Military, Enterprise, Agile Transformation Coaches, Scaled Agile

Prerequisites for Attendees

Read the following:

C.14.1.3 Note: SEC utilizes industry standard Agile Scrum methodologies and terminology which can be found at Attachment 0015 in Section J of this document.

C.14.2 ROLES:

C.14.2.1 Project Lead (PL): Government; Project Lead will provide sign-off for entrance and exit criteria for Sprints. Ensures that Government standards are being met (e.g., development standards, backlog /Sprint tracking, testing standards, etc.).

C.14.2.2 Scrum Master (SM): Contractor or Government; Keeps the team on task, has strategy for how to remove impediments, ensures Agile milestones are being performed. Focus on Process Improvement.

C.14.2.3 Product Owner (PO): Government; Prioritizes work in the backlog, works directly with the team.

C.14.2.4 Technical Lead (TL): Contractor or Government; Leads a small programming team to design features and prioritize tasks. Supports team by answering questions and solving problems.

C.14.2.5 Sprint Team: Mix of Contractor & Government technical staff carrying out the software development. When referring to the Sprint Team, one can often include the PO, PL, and SM.

Attachment 0015 is the Scrum Guide that * I * got them to use as part of the RFP. Who can point out all the Scrum "roles" that are "Industry Standards" that are not part of the Scrum Guide?

Dealing with anti-patterns like the above as part of your daily work is the primary prerequisite for all attendees.

schedule Submitted 1 year ago

Public Feedback

    • 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.

    • Thomas Stiehm

      Thomas Stiehm - Shifting Security Left - The Innovation of DevSecOps

      Thomas Stiehm
      Thomas Stiehm
      Coveros, Inc.
      schedule 1 year 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.

    • 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.