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
3. ESCAPES FROM HELLS
   (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)

FOR THE PROGRAM COMMITTEE:

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 (http://www.liberatingstructures.com/1-1-2-4-all/).

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.