Nine levels of Agile Hell... and how to get out!

schedule Sep 23rd 04:15 - 05:00 PM place Auditorium people 7 Interested

Government Agile transformations can feel like overwhelming efforts – but do not abandon hope! This interactive, audience-driven presentation reviews how government and large organizations ESCAPE common Agile adoption challenges.
You - the audience - will prioritize your pain points; we’ll focus on the five Agile hells most highly prioritized. We will discuss real examples of “escaping” out of each Agile hell, with pro tips and success patterns you can apply.
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
  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, and as accepted at Agile 2019.

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.

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

No prerequisite! Please bring a smart phone for interactive questions.

schedule Submitted 4 months ago

Public Feedback

comment Suggest improvements to the Speaker

  • Liked Jeff Dalton
    keyboard_arrow_down

    Jeff Dalton - Big Agile is Coming: Will Technology Leaders Blow it?

    Jeff Dalton
    Jeff Dalton
    Chief Evangelist
    Agile CxO
    schedule 3 months ago
    Sold Out!
    45 Mins
    Keynote
    Executive

    2019 will be the year of Big Agile, where large adopters like General Motors, the Department of Defense, the State of Michigan, Lockheed Martin, and others, who have combined IT budgets exceeding 100 Billion dollars, have all announced their desire to “go agile” at a scale not yet seen in our community. Are technology leaders who cut their teeth in a low-trust, command-and-control, high-documentation environment prepared to make a successful transformation? What will Big Agile look like, and how will it affect the rest of the community?

    This will be our industry’s biggest challenge, and I've been studying it for years. As the large adopters in the federal government and corporate sector begin to adopt agile, they’ll bring their habits, culture, and bureaucracies with them, and they need to get in front of the wave.

  • Liked George Dinwiddie
    keyboard_arrow_down

    George Dinwiddie - Making sure the submission system is open

  • Liked Richard Cheng
    keyboard_arrow_down

    Richard Cheng - How to REALLY use the Agile values and principles!!

    Richard Cheng
    Richard Cheng
    Principal
    Excella Consulting
    schedule 2 months ago
    Sold Out!
    45 Mins
    Workshop/Game
    Beginner
    Your organization is doing Agile, which great, but what does that really mean? Perhaps they are implementing Scrum, or Kanban, or one of the other Agile methods, but are they really being Agile? Does it feel like you are you are doing Scrum, but you’re team isn’t really Agile? There's difference between doing Agile and being Agile and this session explores that concept.

    In this session, we’ll understand what Agile really means and how that relates to the way we implement our Agile methods within our organizations. We'll identify how we effectively use the Manifesto value points so that we can maximize the value of our products while still ensuring that we have quality and governance built into our process. This session will also explore the use of Agile principles to guide our strategic and day to day decisions.

    This sessions is great not only for beginners, but for anyone who wants to get past simply implementing Scrum or Kanban by the book, but really understand how to use Agile values and principles to build better products and organizations.
  • 45 Mins
    Talk
    Beginner

    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 David W Kane
    keyboard_arrow_down

    David W Kane - Hang Out with the DevOps Folks!

    10 Mins
    Lightning Talk
    Intermediate

    One of the things I like about AgileDC is that I see a lot of familiar faces. Not just familiar from previous AgileDC events, but from other Agile events in town, other conferences, Meetups and such. I also go to local DevOps events, and I see familiar faces there too, but I don't observe much overlap between the two. In this talk I will discuss whether this division is real, or perhaps just a figment of my imagination, whether we as an Agile community should care, and what we should do about it.

  • Liked Mark Grove
    keyboard_arrow_down

    Mark Grove / Julie Wyman - What’s REALLY Going On? An Observational Skills Workshop

    45 Mins
    Workshop/Game
    Beginner

    Imagine you are asked to sit in on a team’s sprint review and retrospective. The team has been having difficulty forming and the Scrum Master has asked you to observe the team dynamics during these two sessions. Are you simply going to watch what’s going on or is there more you can do? Perhaps you are seeing interactions and team dynamics at play without truly realizing what you are observing. And when you do observe, are you injecting your own biases into those observations? Observation is a powerful tool, but one which we may not take advantage of to its true potential. After all, what exactly should we be observing, anyway?

    By learning how to expand our observational skills in a non-biased and non-judgmental manner, we can gain a deeper understanding of team dynamics and interactions allowing us to offer more meaningful and impactful support, coaching, and empathy. Because there are many observational aspects that pass us by, the best way to become more observant is through deliberate practice. So, let’s practice together with a group exercise in a fun and safe setting!

    In this highly interactive workshop, we’ll start by sharing tools and tips to make you a better observer. Then we’ll ask for a small group of volunteers (“builders”) to be observed performing a brief task. The remaining attendees will practice applying the observation techniques, and, after the builders finish, will share their observations in small groups. We’ll conclude with a full-group debrief and discussion of the key takeaways and opportunities to improve our effectiveness and observations.

    If you’re looking for new ways to connect with your team, to enhance your agilist toolkit, or simply participate in an informative and interactive workshop, this session is for you!

  • Liked Mathias Eifert
    keyboard_arrow_down

    Mathias Eifert - Complexity is the Enemy! How Agile Practices Allow Us to Operate in a VUCA World

    45 Mins
    Talk
    Intermediate

    One of the key advantages of Agile over plan-driven approaches is that an Agile mindset acknowledges our ever-diminishing ability to usefully predict the future and focuses our efforts on managing change instead of trying to suppress it. This “new reality” has become pervasive enough to drive its own buzz word – VUCA, which stands for Volatility, Uncertainty, Complexity, Ambiguity. But beyond the hype lies a truth that Agile leaders need to understand and embrace – that certain problems really do respond differently to our attempts to manage and solve them. Why does this matter? Because problem contexts that defy straightforward cause-and-effect expectations significantly impact productivity while simultaneously presenting much higher risks to success. Even worse, applying leadership approaches that aren’t matched to the problem context dramatically increases the danger of catastrophic failure.

    In this session, we’ll examine how the Cynefin framework helps us make sense of what kinds of problems we’re dealing with and how we should approach them. We will then look at ten ways in which Agile frameworks, approaches and technical practices help us manage or even reduce complexity and one where they fall short. You will walk away with a deeper understanding of how - and why - the things we do as agilists increase stability and reduce risks for our teams.

  • Liked John Hughes
    keyboard_arrow_down

    John Hughes / Tara Lemieux - Value-driven CMMI: An Agile Approach to CMMI for Agile Companies

    45 Mins
    Talk
    Beginner

    CMMI and agile haven't shared many beers at the bar over the years. But there is no reason they shouldn’t be best of friends. They both long for continuous improvement, creating learning organizations that strive to reduce risk and increase quality. I believe that a major cause of dissonance is the lack of perceived value in the way the CMMI models have been applied and appraisals performed in the past.

    So, what would it look like to implement CMMI and prepare for an appraisal focusing all of our effort into creating value and removing waste, instead of adding it? That was the question we tackled this past year and are seeing a completely different practice and outcome given our approach, including enthusiasm and appreciation from the project teams for this approach as opposed to the more typical dread.

    Participants in this presentation will hear from both a CMMI Lead Appraiser and an agilest who lead this value-driven approach to CMMI. They will learn how agile mindset, practices, and tools can be used to apply the CMMI model to our delivery, with intentional focus on creating an ever-maturing practice that reduces risk and increases quality. Participants will also hear how agile was used in the appraisal preparation, enabling continuous improvement across the organization and even reducing the amount of time and effort needed for the SCAMPI A appraisal.

  • Liked Mark Koenig
    keyboard_arrow_down

    Mark Koenig - Continuous Modernization

    Mark Koenig
    Mark Koenig
    Scrum Master
    Excella
    schedule 2 months ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    Rather than engaging in an intense modernization effort followed by years of minimal maintenance, a better alternative often is modernizing a system continuously, balancing operations, maintenance, and renovation. Ideally you can improve, update, and upgrade the software system one piece at a time while it continues to operate, avoiding feature freezes and scary cut-overs.

    There are always trade-offs to be made, but some approaches better fit IT systems with long-lived missions. At a certain point, a whole-sale rewrite is the best option for replacing stale, decaying software before it leads to major headaches and eventual catastrophe. Big rewrites have big risks and big failures, however. Because of the stability and enduring mandates of some software systems, long-term investments in IT systems pay off and give room for smart maintenance strategies.

  • Liked Adam Parker
    keyboard_arrow_down

    Adam Parker - NoEstimates at Scale in the Federal Government

    Adam Parker
    Adam Parker
    Agile Coach
    Excella
    schedule 3 months ago
    Sold Out!
    45 Mins
    Experience Report
    Advanced

    Come learn how our 3 teams, operating in a LeSS-style scaled model, experimented with a NoEstimates approach to development work and then adopted that as our way of working for a year in the Federal government. Included in our story is a switch to Kanban, returning to Scrum, and eventually returning to pointing work. It has been a remarkable journey that I'm excited to share!

  • Liked Raj Indugula
    keyboard_arrow_down

    Raj Indugula / George Lively - Being Test-driven: It's Not Really About Testing

    45 Mins
    Talk
    Beginner

    Good news: Test-driven practices have jumped the chasm to general acceptance! The bad news, though, is that while TDD, BDD, and ATDD are prominent buzzwords in the industry today, they are rife with misconceptions, with many people incorrectly assuming that being test-driven is all about testing.

    In this talk, learners will leave with a clearer understanding of Test-Driven Development (TDD), Behavior Driven-Development (BDD), and Acceptance Test-Driven Development (ATDD), and gain practical insights into how these practices can help teams develop better software. We will gain an appreciation for TDD as being primarily a specification and design technique, and how to get the whole team involved earlier in the delivery cycle using a BDD approach.

  • 45 Mins
    Workshop/Game
    Beginner

    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.

  • Liked Nicole Spence-Goon
    keyboard_arrow_down

    Nicole Spence-Goon - Peaks or Valleys? The power of Scaling Agility in the alphabet soup of Government agencies

    Nicole Spence-Goon
    Nicole Spence-Goon
    Agile Coach
    Excella
    schedule 2 months ago
    Sold Out!
    45 Mins
    Experience Report
    Beginner

    Do you feel like Agile Scaling has become a goal rather than the means to an end for your organization? To determine where you stand on the Scaling spectrum, ask yourself a few soul-searching questions: Why do we need to scale? Is this the right time for us to scale? If you’ve checked these boxes, you may wonder “where do I go from here?”

    This talk will focus on 3 areas that emerged as common themes throughout my experience working on government Agile Scaling projects and ultimately influenced the trajectory of each agency's scaling journey:

    • Communicate vision consistently
    • Focus on your people genuinely
    • Create your own path intentionally

    I've seen successes and some struggles with Agile Scaling efforts in government agencies. Regardless of the agency acronym or the frameworks used, these key elements shaped their scaling outcomes.

  • Liked Mark Ginise
    keyboard_arrow_down

    Mark Ginise / Joshua Seckel - My Government Agency Is Unique...Just Like All The Other Agencies

    45 Mins
    Experience Report
    Intermediate

    Many people have implemented successful agile transformations in a federal agency on a project or program, some even converting entire agencies. Then they tried to take that method and apply it to another program or agency - and failed. What went wrong? Most government agencies are roughly the same size as a company, Departments are collections of companies, and the entire federal government is massive at a scale beyond most enterprise changes. Just like companies, each agency has unique cultural differences and technical proficiencies. But there are overall federal practices and ideas that can help with an agile transformation.
    Are the governance practices from USCIS adoptable in other agencies? Can the leadership champion at FBI Sentinel be duplicated? Is the recovery from healthcare.gov something that should be emulated on other programs?
    Based on discussions with many federal employees and a few contractors working in various agencies, including Departments of Homeland Security, Defense, Treasury, Transportation, the Intelligence Community and others, this talk will dissect and analyze anecdotes and stories across various federal agencies with advice on what seems to work universally, what seem to be anti-patterns, and what is very agency specific.
    We looked across several vital areas for agile adoption and transformation: technical practices, leadership engagement, governance, procurement, and mindset. For each area, we will summarize, with specific examples from federal agencies, practices that have worked across multiple agencies, practices that have seen success in one or two agencies, and practices that have not been successful at any agency in promoting change.

  • Liked Ben Morris
    keyboard_arrow_down

    Ben Morris - Agile the Hard Way - Lessons from a Government Project

    Ben Morris
    Ben Morris
    Consultant
    STSI
    schedule 3 months ago
    Sold Out!
    45 Mins
    Case Study
    Intermediate

    "Agile OSS" jet on the ground, with an arrow leading to "the cloud"

    The talk walks through lessons learned from a specific government project, jumping head-first into agile, open source, and (oh dear) the cloud. In the jet plane metaphor, it's not about the theory of why a plane should fly (as a physicist), but about the big and little forces that will act on it in practice (as a test pilot).

  • 45 Mins
    Talk
    Beginner

    On average Agile transformations get into trouble at about 14 months from the time they start. Have you ever wondered why?

    Is it because you started from 'the bottom up?" Or is it because you spend time, money, resources and people creating great teams and didn't pay attention to having a professional, empowered Product Owner organization?

    Agile transformations that target department level and not the organization have a very low success rate and you end up with an agile department enveloped by a traditional organization. That leads to dark work, decision delay and dysfunction.

    So, what can you do?

    Come and learn some of what I learned the "hard way" over 7 transformations.

  • Liked Dave Witkin
    keyboard_arrow_down

    Dave Witkin - Go Big Without Blowing It: How Does Scrum@Scale Help?

    Dave Witkin
    Dave Witkin
    Principal
    Packaged Agile
    schedule 3 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    Do you work on programs requiring collaboration of 30 people or more? Have you heard of Scrum@Scale? While many people have heard of SAFe, far fewer are familiar with Scrum@Scale. Did you know Scrum@Scale was built by Jeff Sutherland, the co-creator of Scrum? And that the very first scaled Scrum project began in 1983?

    Come learn about Scrum@Scale, where it is being used, and why it may be a better fit for your organization than other scaling methodologies. I am both a SAFe and Scrum@Scale practitioner and trainer, and will provide a balanced comparison with pros / cons.

  • Liked Glenn Buckholz
    keyboard_arrow_down

    Glenn Buckholz - Moving Your Pipeline to Kubernetes, Things I Wish People Had Told Me

    Glenn Buckholz
    Glenn Buckholz
    Technical Manager
    Coveros
    schedule 4 months ago
    Sold Out!
    45 Mins
    Case Study
    Intermediate

    Kubernetes married with a cloud provider elastic, highly available infrastructure. Many CI engines today (Jenkins, Bamboo, Gitlab, CircleCI), provide native integration with kubernetes so that your build and deploy workload can be elastically executed. This allows your pipeline to meet the needs of your schedule, be it the 4pm pile on to commit code before going home, the mad rush to get a hot fix to production, or the surge of an unexpected customer ask. Gone are the days of the build queue growing and you CI engine collapsing under the weight of a hundred build requests. In order for a pipeline to leverage this capacity changes must be made to the pipeline architecture. Tools must be dockerized, the ephemeral nature of running docker must be considered, kubernetes specifications or helm charts must be generated for the application, automated testing must be adapted to work in the new architecture, and then there is the database. Each one of these issues, plus many others I’ve missed contained unfortunate, unforeseen pitfalls that translated in schedule delays. Join Glenn as he helps you short circuit the pitfalls of migrating to kubernetes off of your static in-elastic virtual infrastructure.

  • Liked Dane Weber
    keyboard_arrow_down

    Dane Weber - Undercover Scrum Master

    Dane Weber
    Dane Weber
    Lead Consultant
    Excella
    schedule 2 months ago
    Sold Out!
    45 Mins
    Experience Report
    Intermediate

    After three years as a Scrum Master and Agile coach, I hit a wall coaching a team that did not want to try popular Agile engineering techniques such as TDD and pair programming. I had become a Scrum Master after four years working on the business analysis and account ownership side of things and could not speak from personal experience about engineering practices. In order to get some first-hand experience and to gain a new perspective, I chose to spend a year or two as a software developer on a Scrum team.

    The experience has been eye-opening. I experienced a tremendous cognitive load working with a wide array of technologies; this pulled my attention away from many of the collaborative and process-oriented activities I cared about as a Scrum Master. I was surprised to feel strong pressure to complete work quickly, cutting corners, even when the Product Owner and Scrum Master were not asking me to. When this pressure was explicit, it usually came from my fellow developers. On the other hand, there is real joy in writing code and seeing a system do something worthwhile that it wasn't doing before. My outlook has changed tremendously and is something I want to share with anyone who works with development teams, especially Scrum Masters and other coaches. I am still enjoying my time as a developer, but I'm looking forward to returning to coaching and incorporating this experience into my approach.

  • Liked Katrina L. C. Tanner
    keyboard_arrow_down

    Katrina L. C. Tanner - Playdoh...play on!

    Katrina L. C. Tanner
    Katrina L. C. Tanner
    Scrum Master
    Cvent
    schedule 3 months ago
    Sold Out!
    10 Mins
    Lightning Talk
    Beginner

    What happens when 25 product owners, developers, and quality engineers reflect on their previous sprint through the eyes of a child?

    Playdoh took my teams, remote and collocated, from showing up to an obligatory meeting on their calendar to intentional interpersonal and intrapersonal dialogue.

    Between the carpet and the sticky fingers, adults are usually cleaning up more Playdoh than playing with it themselves. Even to my own surprise, in this “Play Retro,” our team members connected, not only on a professional, but also on a personal level in ways they had not done before.

    This session will give an overview of our experience using a “Play Retro” and leave you with tips and things to consider planning a retrospective.