Agile Hell II: post apocalypse Agile Hell... and how to escape

In 2018, Dave Fogel (DoD employee) & Dave Bujard (DHS contractor) defined "9 levels of Agile and Hell and how to escape".  At multiple conferences, we filled the tables and the standing room - staff had to stand outside the room to enforce fire safety.  That was before the pandemic!!!  Some things have changed, and a LOT has been amplified.  The Dave's are ready to share their ideas/thoughts.. in this sequel to their Agile Hell presentation... including how to ESCAPE Agile Hell.  Combined we have a half century of experience in Government - ranging from technical to Agile contracting... and yet we are hopeful and optimistic!

The Agile hells we've escaped include:

  • No Transformation hell - A federal program or department wants to change but can’t start or can’t finish
  • Too Fast hell - Newly Agile federal programs sometimes respond TOO rapidly, too often changing priorities.
  • Technical hell - Programs can become bogged down in technical debt and manual processes.
  • No Trust hell - Government delivery can be slowed by lack of trust between contractors and feds, between business and IT, or between compliance and delivery groups.
  • Product Owners hell - Government Product Owners can be unavailable, think they are managers, aren’t empowered to provide vision, or struggle with prioritization
  • Too Big hell- A frequent pattern in federal Agile! Large batches produce slow progress, low visibility and high complexity, seen in big programs, big deployments, and big contracts.
  • Collaboration hell - Government teams can struggle with collaboration within the same organization across roles and across the fed-contractor divide.
  • Stove-piped hell - Government organizations can struggle to collaborate across contractual or organizational boundaries within the same enterprise
  • Leadership hell - An organization can only be as agile as its leadership. In the government, how can you work with leaders who aren't ready to be agile?

For each Agile hell, we focus on successful techniques to escape from these common dynamics. Unlike other presentations, we won't be doing a deep dive, but we will cover the most important challenges our audience face.



Outline/Structure of the Talk

  1. Here are the nine Agile Hells (4 min)
    1. describe the nine levels (1-2 sentences each)
    2. POLL EVERYWHERE:of these nine hells - what do you want to hear about?
  2. INTRODUCTION (2 min)
    1. I’m Dave - an Agile Coach, Geek, Dad
    2. I’m also Dave - an Agile Coach, Geek, Dad
    (We'll discuss the top five based on poll, offering additional examples and nuance for the top two) (34 min)
    1. Transformation hell
      • Real example of a program which just went through the motions of Scrum but never progressed
      • The solution: coach worked with a number of teams in turn, leading with why and training a agile advocate within each team
    2. Too Fast hell
      • Real example of a program trying to pivot too fast, always breaking sprints with the "emergency" of the day.
      • The solution: coach worked with both customer and team to make visibile the trade offs involved in interrupting flow to address emerging priorities
    3. Technical issue hell
      • (we'll provide examples and solutions for each remaining hell; see the presentation to hear them!)
    4. No Trust hell
    5. P’Owners hell
    6. Too Big hell
    7. Collaboration hell
    8. Stove-piped hell
    9. Leadership hell
  4. SUMMARY (5 minutes)


Your feedback in 2018 helped shape our talk as presented at Southern Fried Agile, Agile+DevOps West, AgileDC, and Agile 2019... at Agile 2019, extra purple shirts had to come around because folks were entering AFTER the room was full. 

We put a high value on prioritization and fast feedback loops - and we model this in the presentation itself. When we give the Agile Hell presentation, prior to actually introducing ourselves, we spend about 5 minutes explaining our Nine levels of Agile Hell. The Audience then prioritizes the Hells using the Poll Everywhere app - because we want to do everything on our backlog but we commit to the things that provide highest value. We the discuss each hell in a lean coffee style with time increments based on the available time. During each Hell, the audience creates a heat map of topics so that we can deliver higher value by responding to the audience

There is a lot to cover - and this will be a relatively fast paced event and will be responsive to audience interests via instant polling. Dave and Dave have given this presentation a half dozen times to audiences up to 120 - each time following our Agile mantra of highest value for the audience. That can be achieved because the Dave's draw upon (combined) experience of four decades in IT and two decades with Agile teams - all within Government projects.

We have given the Agile Hell enough times (in public and practice), to be very confident in Poll Everywhere (PollEv). Nevertheless, we recognize there is a risk since PollEv is a significant catalyst for our interaction with the audience. In the unlikely event that we cannot make use of PollEv, we have a pre-defined order in which to convey topics and will use the 1-2-4-all method to respond to the attendee insights (

We share escapes government programs have used to avoid these agile hells, citing the program and speaking from our (combined) 40 years experience with IT in federal government. While we are not committing to speak on the following escapes, because we adapt Agile Hell to the audience in real time, examples we’ve used before include:

  • No Transformation hell - At [FEDERAL AGENCY] a cadre of coaches embedded with teams to build pockets of agility, then trained successors within each project to continue the transformation long term.
  • Too Fast hell - At USCIS ICAM, coaches used DHS ALMSS (JIRA) to make tradeoffs visible to product owners and business stakeholders who kept demanding rapid pivots before delivery had progressed.
  • No Trust hell: The only currency that buys trust is delivery. If your trust budget is small, make small, low risk deliveries. USCIS Transformation addressed a lack of trust about background check integration by taking stakeholders’ concerns seriously, meeting with them on a regular cadence, and bringing data by cross-checking thousands of background checks - at first through a manual sample, then by building automation. USCIS Avant built trust by asking customer subject matter experts be the ones leading a monthly system demo. The SMEs trust in the team deepened as they realized they were part of the team and jointly responsible for success. The SMEs built up significant trust from their stakeholders by demonstrating working software and speaking to how it will be used.
  • Product Owners hell - At TSA TAS, the contract’s technical monitor offered a “product owner agreement” as a non-binding document signed by the PO’s reviewer. Even though it is non-binding, the document empowers the PO, clarifies scope of the PO, and helps keep other responsibilities at bay.
  • Too Big hell- Contracts can be too large. The FADS II contract found that vendors could bring on four or five development teams, but performance declined sharply for the eighth, ninth and tenth team from the same vendor. One vendor escaped this by staffing slowly, one team every two months. Deliveries can be too big. Some years ago a delivery for USCIS Field Operations Division required over 400 user stories and nine months of development before it could be operationally test. We learned we needed to break up the functionality into smaller deliveries for low risk, end-to-end testing. We started field tests instead where as soon as feasible we’d run a few cases through the system, then ramp up as the system was tuned and proven out.
  • Collaboration hell - While in the US Army, Sergeant Fogel led team members who were weak and strong in different areas. When the team ‘formed up’ they would sound off “GOOD ENOUGH” - which was a daily reminder to focus on helping team members over excelling in a specialty. The chain of command heard this and supported the idea of team success over individual excellence. Similarly, USCIS D-QATS measures the agile health of DevOps programs by tracking which team members lead deployments. Programs with a log “bus factor” depend on person heroics, while programs with high rotation reduce risk through rich collaboration.

We have similar examples from government projects for the other hells (Technical, Stove-Piped, and Leadership) - we are prepared to discuss further if the program committee is interested.

Learning Outcome

  • Audience will get an appreciation of some aspects of Agile that are known to be difficult impediments.
  • More important: the audience will have specific actionable solutions to their concerns.

Target Audience

Anyone in an Agile transformation, particularly for Government and other large organizations

Prerequisites for Attendees

Please bring a smart phone for interactive questions.

schedule Submitted 7 months ago

  • Tara Scott

    Tara Scott - Showing Up: Building Better Behavior on Collaborative Teams

    45 Mins

    “How does psychological safety add value to my workplace? Does investing in psychological safety reduce the ability to deliver on quarterly deadlines? There’s no time!” 


    These are actual questions and statements I’ve heard recently from leaders who are so concerned about delivery they feel like they can’t invest in the value of their people. The fear of not hitting dates and deliverables becomes the driving factor of decisions, and things like psychological safety get looked at as an “extracurricular activity,” or perhaps a function of HR. Many individuals don’t recognize that by enabling and empowering people they’re actually immediately creating high performance teams, helping them get to what they’re looking for faster. 

    Psychological safety is directly related to performance and is something actionable that can be practiced every single day, as certainly a lack of psychological safety is often felt by people every single day as well. Scoping projects, creating stories, roadmapping sessions, code reviews - let alone performance reviews and tracking velocity - all require us to interact with other people. Real psychological safety is something we can build a consciousness around  within our ecosystems.


  • Richard Cheng

    Richard Cheng - Agile Estimation – What it really means…

    45 Mins

    In this session, we will look at estimation techniques that many Agile teams use.

    This session starts off by exploring the concept of estimation via time based estimates (such as hours and days) compared to relative sizing (like story points, Fibonacci, t-shirt sizes).  We will explain what relative sizing means and the advantages and disadvantages of relative sizing and time based estimates.

    From there, we dive deeper into story points and will conduct an estimation simulation with story points using the planning poker estimation technique.

    The session then delves into how to calculate and properly use velocity and how velocity is often misused.

    We conclude this session with thoughts on how to stabilize your team’s velocity.  Some teams often struggle with stabilizing velocity and we will walk through a checklist on how to stabilize velocity.  We conclude with techniques on how to get started with relative sizing.

    Coming out of this session, attendees will:

    1. Understand when to use time and when to use relative sizing for estimation
    2. Know how to perform estimation as a team
    3. Identify velocity and how to stabilize it
    4. Know how to get started with relative sizing
  • Paul Boos

    Paul Boos - Organic Scaling

    Paul Boos
    Paul Boos
    Principal Fellow
    schedule 7 months ago
    Sold Out!
    45 Mins

    The Manifesto for Scaling Agility has one its values Organic Growth over pre-defined structure. What does this mean in terms of scaling? How do development efforts scale organically?

    This talk will begin by examining the Scaling Manifesto's values and principles and how they fit within the context of the . Using this lens, we'll look at how organizations can entrust their teams to scale appropriately and confidently to meet the needs of the business. We'll look at prerequisites for making this growth successful, various starting points, and organizational prerequisites.

  • Michael Santens

    Michael Santens / David Fogel - Is there a reason why Agile contracting isn’t?

    45 Mins

    In the Government, agile contracts are not agile owing to rules (FAR) and policies. We fail expectations. Customer interactions over contracts are in the stated manifesto.  Using Agile principles, processes, and metrics, can you effectively bid on RFPs? Win Contracts? Observations from a former ‘unlimited’ warranted contracting officer (ACO & PCO) for the Government.