Impossible deadlines? Fail safely, learn rapidly with Spaceteam

Communication chaos under looming deadlines - sound familiar? We'll level up our teamwork, practice rapid learning, and identify ways to calm the chaos and focus on getting to done, all using Spaceteam, a chaotic and collaborative card game.

You'll work with your teammates to repair a failing spaceship before it falls into a black hole. in order to escape, you'll communicate problems, request help, assist colleagues and respond to constant change -- all in five minutes!

You'll learn from your failures, improve as a team, and gain insights into what helps organizations and teams collaborate effectively and achieve flow.

 
 

Outline/Structure of the Workshop

Before the session: I'll begin with materials in place on each table, including very brief rules for the game, and space for participants to note observations during the session, and notes for what they'll take home to their colleagues after the session.

During the session: I'll introduce the problem -- a failing spaceship falling into a black hole -- and quickly review the rules. Each time I've run this session, we were up and playing the first game within the first eight minutes.

Each run of the game lasts five minutes, and features shouting, changing seats, unheard requests for help, and usually, implosion in a black hole.

After five minutes, we'll retro.
I'll ask: "How was this like your daily work?" We''ll have 60 seconds to pair share and four minutes for table discussion.

I'll then ask: "Knowing what you know now, what will you do differently?" I'll give them the same 60 seconds pair share and four minutes table discussion, which is never enough, but it's enough for them to share some ideas and try again.

Then we'll play another five minute round. More shouting, some victory, generally teams having a growing sense how to work together.

Then we'll retro again. This is the last meaty section, so I'll ask for success stories:

Who found a good way to make requests that were listened to?

Who found ways to reduce the number of problems you're working on simultaneously?

Who found an idea you'd like to try at with your colleagues at work?

Each person, please write down your Ah Ha!s. How will you share these with your colleagues?

As time permits, teams can choose to play one last five minute game. (I find there's a strong interest in "winning" the game for closure.)

Learning Outcome

We'll leave with a vivid experience of how organizations can calm chaos by limiting work in progress and focusing on the group mission.

Target Audience

Anyone looking for a vivid way to bring home the value of retrospectives and limiting WIP.

Prerequisites for Attendees

We'll learn together during the session, so you don't need to know or do anything to prepare.

schedule Submitted 1 year ago

Public Feedback

comment Suggest improvements to the Speaker
  • David Bujard
    By David Bujard  ~  1 year ago
    reply Reply

    Updated with video and links from the most recent run of this session.

  • David Fogel
    By David Fogel  ~  1 year ago
    reply Reply

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

    • I really like the iterative nature of the session and the relative easy of transferring the session back to "reality"

    I think the submission could be improved by:

    • seems like a lot of chaos to manage as one person
    • falling toward a blackhole sounds like a "space waterfall"
    • Chris Meaker
      By Chris Meaker  ~  1 year ago
      reply Reply

      David joined me at ScrumRVA to present an abbreviated version of this (25 min). https://www.meetup.com/Scrum-RVA/events/251133360/

      There were about 40 participants (4 tables of 6 playing the tabletop and 2 tables playing the mobile App).

      The group really enjoyed it and wanted to continue but we did meet our committed timebox. 

      Some learning that can apply for this or future sessions:

      • there was added overhead by playing the App as well as tabletop versions
        it was nice to be able to show the different possibilities but we did not have time to debrief the similarities and differences

      • assistants are helpful at the setup and initial game play and for resetting but are not heavily needed during the game- having 2 assistants for 6 total tables was more than enough

      • 25 min does not leave much space to process the learning, we got some key questions asked and time for a few answers and then pointed to the facilitator guide for more in depth use

  • Liked David W Kane
    keyboard_arrow_down

    David W Kane / George Paci - Approval Tests in Action: A LEGO Exercise and an Experience Report

    45 Mins
    Workshop
    Intermediate

    Are you daunted by the prospect of introducing automated testing to a code base without it? Does your code base have automated unit tests, but no one has confidence about what the tests say about code? Consider approval tests to confront these challenges. Approval tests simplify assessing the behavior of a system by taking a snapshot of the results, and confirming that they have not changed. They are useful for both bootstrapping testing automation and for creating more expressive tests. In this session participants will join in hands on exercises using LEGO bricks that illustrate the concept of approval tests, and will share the results of a case study where the approach was used to improve software testing.

  • Liked Gene Gotimer
    keyboard_arrow_down

    Gene Gotimer - Building the Pipeline of My Dreams

    45 Mins
    Case Study
    Beginner

    I often suggest to teams that they should be using all sorts of tools in their pipelines- from simple static analysis checks and automated builds to security scans and performance testing. I've done presentations and talks at conferences. I've lobbied to clients. I've commiserated with my colleagues. But I've never put together my dream pipeline in one of my own projects.

    There are always reasons that some tests and tools get left out- our policies won't allow them, they will take too long to get approved, we don't have time, we have bigger problems to deal with, it just isn't what the client is looking for right now. And I usually think, if only I were in charge, I'd make sure we were using those...

    In late 2017 I took over maintenance on an open-source project. Now I have no restrictions. The sky's the limit. No one is around to tell me what I can't do. So why don't I have my dream pipeline in place yet?

    I'll talk about the trade-offs and compromises I made when building out the pipeline. Why I decided to focus on some tools and tests but skipped others, and what I need to do or change to make this delivery process the pipeline I've always dreamed about, now that I have no one else to blame.

  • Liked John Hughes
    keyboard_arrow_down

    John Hughes - Agile FTW: Competitive Advantage and Happiness Through Business Agility

    45 Mins
    Talk
    Intermediate

    We all know the story of how the Agile ‘Software Development’ Manifesto emerged out of Snowbird in February of 2001. And we all know that Agile is still the current best practice for software development. What remains to be fully realized is that Agile has evolved to a best practice for business in general; a way of life for that matter.

    I had the privilege of bringing Agile into business over the last couple years. In that time, I introduced my executive leadership team to Business Agility. After getting executive participation in the inaugural Business Agility conference in Feb 2017, we partnered together to seek the benefits of a comprehensive Business Agility adoption.

    Using our corporation’s strategic planning and execution effort to exemplify, I will share with you how the Agile mindset and practices apply to business and drive the highest impact possible towards the most valuable goals and initiatives. Modern leadership and business practices such as those under the Business Agility umbrella bring a value-driven, data-driven, efficient focus on impactful delivery.

    • Revenue and growth accelerate as we focus the company’s resources on delivering in the most valuable way
    • Corporate processes lean out as we remove wasteful bottlenecks, saving money, time, and providing competitive advantage
    • Employees are more capable as corporate practices are more meaningful and less taxing
    • Back-office tools and data are integrated into a unified experience allowing real-time awareness and predictive analytics, increasing effective decision-making and enabling empowerment at lower levels
    • Employees are happier. Customers are happier. The corporate bottom-line reflects this happiness.

    I am enthusiastic about the spread of Agile beyond IT. And as such, I am excited to illustrate the brilliance of Business Agility to session participants, adding examples from my most recent corporate transformation effort to exemplify the mindset and practices presented. It is my interest that participants come away with an understanding of how Agile mindset and practices benefit the corporate back office as much as they do software delivery, and how their companies can begin to benefit too by applying what they learn from this presentation.

  • Liked Richard Mills
    keyboard_arrow_down

    Richard Mills - DevOpsing Your Greenfield: Cultivating New Growth

    45 Mins
    Talk
    Intermediate

    You have a golden gem of an activity. There's a brand new project and your project sponsor says "I want to do some DevOps on our new Agile project!" Sigh. You respond with "Well, how about this? Let's BE Agile and adopt a DevOps approach to structuring our teams, designing our architecture, and leveraging automation to rapidly deliver value to our customers." There. At least we've set the mood.


    Regardless, greenfield projects provide a unique opportunity for us as DevOps professionals. You don't have the established baggage of a legacy project. The project is probably open to modern tools and architectures. The project is trying to set up team structure that will have the right skill sets.


    The problem is: where you do you actually start with greenfield projects? When we introduce DevOps to an existing project (brownfield) we have a unique set of challenges and we can prioritize where to start based on our biggest problems. What do you do when you have a blank page? "Do everything!" Well, what actually makes up "everything" and where do we start?


    Putting a solid DevOps solution in place involves some key things. You can follow the religion of the "Three Ways of DevOps" (fast delivery, fast feedback, constant learning) made popular by Gene Kim, but you still have to start somewhere. In this talk, I'll provide a pragmatic formula to setting up well-integrated teams, establishing a DevOps platform, organically growing an initial DevOps pipeline with continuous integration and continuous delivery, establishing some (useful) standards, and guiding the system architecture to support rapid build, deployment, and testing.

  • 45 Mins
    Tutorial
    Intermediate

    Slides: https://www.slideshare.net/Camille_Bell/kata-your-way-to-sw-craftsmanship

    Maybe you are a developer and want yourself and your team to become Software Craftsmen.

    Or perhaps you've a leader and heard about the greater quality and productivity of high functioning agile development teams.

    Or you could be in dev ops and know that you can't implement a CD Pipeline without a solid suite of automated tests. But your developers don't practice Test Driven Development, Refactoring or other agile technical practices, and you don't know how to guide them.

    Whatever your role, you would like your team to become software craftsmen, proficient in agile technical practices.

    Join Camille as she shows you how to Kata Your Way to Software Craftsmanship.

  • Liked Thomas Stiehm
    keyboard_arrow_down

    Thomas Stiehm - Failure is Inevitable But it Isn’t Permanent

    Thomas Stiehm
    Thomas Stiehm
    CTO
    Coveros, Inc.
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    Elevator Pitch:

    Agile Transformation is harder than it needs to be because we often find ways to consciously or subconsciously sabotage our efforts if we can recognize this behavior it is possible to intervene and make a change for the positive.

    Abstract:

    Have you ever been on a project where it seems like team members are preventing the team from getting better? Why do they do that? I don’t know either- a psychologist might have to answer that. What I can tell you about is my experiences in seeing teams become their own worst enemies and unwittingly sabotaging the projects they are trying to make successful. My goal is to help you realize when you or those around you are behaving in a way that is going to lead the team plateauing or even failing. I have often found that many teams can get stuck, or plateau, at a certain point along the continuum of agile maturity. These teams can meander around without getting better or even changing anything for long stretches of time. I have also worked with teams that put so many hurdles in their own way that they had no option but to fail. They often fell back into old patterns and gave up hope that things can get better. As an Agile Coach, I have often felt that one of the most valuable things I can share with the people I coach are my failures. I have worked on Agile projects for a long time, and I have failed in many different ways. Having been through failure, I have learned that to keep getting better you have to recognize the things that you do that lead to plateaus and failures to overcome them. This talk is for coaches and team leads who want to make sure their team isn't getting stuck in a rut, or who are trying to get out of a rut with their health and sanity intact.

    Failure signs and examples

    No process is defined and followed

    • ex. Projects that claim to be agile without any experience or training, or doesn’t have basic agile practices such as retrospectives, I.e. we are agile because we have hour long daily standup meetings.

    Process practices are ignored or removed with no compensating practices

    • ex. Agile practices hold each other together, supporting each other by the value they bring to the project, some teams decide to not do some practices without doing something else to get that value, for instance pair programming provides code review and knowledge transfer, many teams don’t pair program and don’t do code reviews and or knowledge transfer.

    Automation is not valued or planned into work

    • ex. We will automate tests later. Often that later never comes and the team is left with a code base that is hard to maintain and change because you don’t know what your changes break.

    No stakeholder expectations management

    • ex. The only way a project can negotiate scope and or schedule is to actively manage stakeholder expectations. An example of unmanaged expectations is the PO that never says no to a feature request or the executive that decides what must to delivered and when it must be delivered.

    Quality and testing practices are an after thought or short changed on schedule

    • ex. Teams that don’t complete sprint commitments because the testers get coded stories too late in a sprint to do all the required testing and the rest of the team isn’t held responsible to help test.

    No negotiation allowed in deliverables and or schedule

    • ex. Executives that dictate all of the terms of a project before a team is even selected.

    The team doing the work didn’t estimate the work but are held to an estimate

    • Many government projects have such a long procurement cycle that no one from the proposal team is put on the project.

    Part time team members are in the critical path

    • ex. Sometimes people with special skills are needed for a part of a project. If the person is part time but their work is in the critical path the project is in trouble.

    Heavy team turn over

    • ex. Heavy turn over is a sign of a project that isn’t on track, even if it hits its deadlines the quality and output will suffer.

    Political motivations more important than team’s ability to do work

    • ex. If the team is setup to fail for reasons outside the team, they will most likely fail.

    Distraction from issues outside the work that needs to be done

    • ex. Scrum Masters that don’t shield the team from issues outside the work that needs to be done during a sprint will end up with a team that doesn’t hit the mark.

    Examples of what can be done to avoid failed projects:

    Focus on shielding the team from outside influence

    • Have the team focus on the things they can control and prevent outside issues from distracting the team.

    Negotiate delivery with the team

    • The team can develop an understanding of what it can deliver. Trying to make the team do more is going to lower quality and potentially make the project take longer.

    Management of stakeholder expectations

    • Stakeholders always want more, that is their job. Let them ask for anything but set their expectations on what is really going to happen.

    Focus on technical excellence, quality, and automation

    • If you want your teams to get better, have them focus internally on things they can control like technical aspects of the project including quality and automation.

    Hire motivated team members and make it possible for them to work

    • People who care about what they are doing will always be better than the cheapest people that don’t care. Hire people who care.

    Maintain a progressive planning pace for getting requirements ready

    • Agile requires planning at different levels, skipping a level for any reason means there are going to be disconnects between your stakeholders and the people doing the work. Disconnects means the project will not product the results you want.
  • Liked Julie Wyman
    keyboard_arrow_down

    Julie Wyman - Responding to Change over Following a Plan: Agile Lessons from Antarctica

    Julie Wyman
    Julie Wyman
    Agile Coach
    Excella
    schedule 1 year ago
    Sold Out!
    10 Mins
    Lightning Talk
    Beginner

    I spent January in Antarctica hanging out with penguins, whales, and seals. It was about as different from my day-to-day work as can be. And yet, on my long flight home, I couldn’t help but reflect on how well my trip aligned with one specific value of the Agile Manifesto: “Responding to change over following a plan.”

    Antarctica is a place that truly drives home why we need both planning AND, even more importantly, the ability to respond to change. This trip helped me fully appreciate how true this value is - and not just in software development. And after being stuck in Antarctica six days longer than planned, it also built up my empathy for team members struggling with dynamic situations!

  • Liked Erin Randall
    keyboard_arrow_down

    Erin Randall / Yogita dhond - Can Selflessness Lead to Collaboration?

    45 Mins
    Talk
    Intermediate

    Does your team have a "me first" mentality? Are people so focused on getting their own work done, their tickets closed and moved to the right, that they seldom look up to see what is happening with others? What about your division--do teams appear to be siloed, concerned about only themselves, not looking around to see how their work affects others? Let's change this!

    Collaboration is not just working together. We can achieve real collaboration, the type where we inspire one another, challenge the way we work through problems and tackle work, do the things that scare us by making selflessness a daily practice. By making questions of "What did you do to help another person or team?" or "What did someone do to that really made a difference in how you worked?" into our retrospectives and mindset, we can build selflessness into the very fabric of the team. By bringing selflessness to the forefront and making it a talked-about, key ingredient to how our teams function, we can go from wishing for more opportunities to work together to achieving true collaboration.

  • Liked Jochy Reyes
    keyboard_arrow_down

    Jochy Reyes - Cognitive Biases in Agile Teams

    Jochy Reyes
    Jochy Reyes
    Agile Coach
    ANZ
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Beginner
    Picture a tiger in front of you at this very minute. A ferocious feline looking for its next prey. Chances are you'd bolt for the door without even thinking. Your body would flip its flight or fight response switch and in this case run for safety. This is called heuristics, mental shortcuts that help us make decisions without spending a lot of time.
    Now, ferocious felines in offices are most likely unlikely (and potentially questionable --someone call PETA!), however high pressure situations are not uncommon in Agile Teams. Situations that at times unconsciously flips our flight or fight switch in our brains and lead us to jump into conclusions about our work, our colleagues and lead us to make poor decisions. This the brain suffering from cognitive biases.
    This talk provides an introduction to cognitive biases and how they sneakily find their way in our teams and affect our team dynamics and productivity.
    I'll cover 3 aspects of teams that could be impacted by these cognitive biases - team dynamics, communication and productivity.
    I'll discuss the symptoms of these biases and show you how to proactively control and reduce its effects for more effective teams.
  • Liked Lisa Cooney
    keyboard_arrow_down

    Lisa Cooney - Brain Agility: Overcoming Cognitive Bias

    Lisa Cooney
    Lisa Cooney
    Principal Agile Coach
    Axios
    schedule 1 year ago
    Sold Out!
    45 Mins
    Workshop
    Intermediate

    Did you know that your brain tells you stories all day long, and that if they are good stories, you believe them? Come to this entertaining interactive session to experience some "cognitive illusions" for yourself, and learn what they demonstrate about how our brains' work. Cognitive science and behavioral psychology offer important insights for agilists, insights that can help us work more effectively with our co-workers and clients. You will learn how awareness of our brains' tendencies is a powerful tool to overcome our own innate cognitive bias, and the cognitive bias of others. This newfound awareness can open you to more varied perspectives in order to tell yourself a story that is both richer and more nuanced -- and closer to being "a true story."

  • Liked Joshua Seckel
    keyboard_arrow_down

    Joshua Seckel - Modern Agile 101 for Government

    Joshua Seckel
    Joshua Seckel
    Specialist Leader
    Deloitte
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    In 2001, a group of software developers got together in Snowbird, UT, and created the Agile Manifesto. The Manifesto was a statement of core value and principles. The core values are:

    • Individuals and interactions over processes and tools
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
    • Responding to change over following a plan

    These four values are supplemented by 12 principles of agile software. The original 17 signatories were joined by thousands of additional people with the ability to sign cut off in 2016.

    These principles are the foundation of much of the work in agile that has occurred in agile development, but have been mostly frozen as practices and agile has evolved.

    Modern Agile has been created recently to update the underlying foundational values and to provide a focus beyond software delivery. Those four values are:

    • Make People Awesome
    • Deliver Value Continuously
    • Make Safety a Prerequisite
    • Experience and Learn Rapidly

    This talk will walk through this reimagining of the agile values and what they mean for delivery within a government context. We will take each value and look at government cultural and technical challenges and opportunities to advance modern development practices.

  • Liked Gene Gotimer
    keyboard_arrow_down

    Gene Gotimer - Build a Better, Faster Pipeline for Software Delivery

    45 Mins
    Workshop
    Beginner

    The software delivery pipeline is the process of taking features from developers and getting them delivered to customers. The earliest tests should be the quickest and easiest to run, giving developers the fastest feedback. Successive rounds of testing should increase confidence that the code is a viable candidate for production and that more expensive tests—be it time, effort, cost—are justified. Manual testing should be performed toward the end of the pipeline, leaving computers to do as much work as possible before people get involved. Although it is tempting to arrange the delivery pipeline in phases (e.g., functional tests, then acceptance tests, then load and performance tests, then security tests), this can lead to problems progressing down the pipeline.

    In this interactive workshop, we will discuss how to arrange your pipeline, automated or not, and so each round of tests provides just enough testing to give you confidence that the next set of tests is worth the investment. We'll explore how to get the right types of testing into your pipeline at the right points so that you can determine which builds are viable candidates for production.

  • Liked Gene Gotimer
    keyboard_arrow_down

    Gene Gotimer - A Definition of Done for DevSecOps

    45 Mins
    Talk
    Intermediate

    DevOps needs to consider many different aspects of software quality, including security. The term DevSecOps was developed to highlight that security is a focus of the pipeline, not a second-class citizen.

    Fortunately, we can define done for our pipeline so that it includes security. Continuous integration can invoke static analysis tools to test for security errors and check if we are using components with known vulnerabilities. Automated deployments and virtualization make dynamic environments available for testing in a production-like setting. Regression tests can drive traffic through proxies for security analysis. From the code to the systems where we deploy the software, the process can be designed to make sure that we follow security best practices, and not produce insecure software.

    Participants will learn how to construct a definition of done that focuses on security in a DevOps pipeline. They will see how to define security practices that build confidence that they are doing DevSecOps, and how those practices and criteria might mature over time.

  • Liked Glenn Buckholz
    keyboard_arrow_down

    Glenn Buckholz - Failing Faster with Kubernetes and then Recovering

    Glenn Buckholz
    Glenn Buckholz
    Technical Manager
    Coveros
    schedule 1 year ago
    Sold Out!
    45 Mins
    Case Study
    Intermediate

    Kubernetes is quickly gaining popularity, but does the technology deserve so many accolades. In this talk we learn what exactly kubernetes has to offer in the DevOps world. We see that as a service it can provide resources for your DevOps pipeline, automated tests, and the application you are trying to build. We visit an example implementation of such a pipeline and discuss some lessons learned about how to balance these three needs. Additionally, we look at what design considerations your application needs to make, you should consider for your automated testing infrastructure, and how all of this can be leveraged to keep consistent CM while deploying rapidly. Lastly, we explore how threading it all together can help you fail fast and recover quickly as well.

  • Liked Victoria Guido
    keyboard_arrow_down

    Victoria Guido - Avoiding Pitfalls of Non-Technical Managers

    10 Mins
    Lightning Talk
    Beginner

    This talk is intended to help folks who are managing technical projects avoid common pitfalls, and help technical teams better prepare managers for overall project success.

  • Liked Yogita dhond
    keyboard_arrow_down

    Yogita dhond - Dynamic Reteaming and Agile

    Yogita dhond
    Yogita dhond
    Agile Coach
    Accenture
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    As an agilist I strive to build great teams and then keep them together as they set on their Agile journeys. However, when you are in an environment where teams change all the time, it makes me wonder if the idea of dynamic teaming can be used to inspire teams to grow in a different way. A couple of years ago, Heidi Helfand, did an experience report about dynamic re-teaming (https://www.agilealliance.org/resources/experience-reports/dynamic-reteaming-how-we-thrive-by-rebuilding-teams/). I have used a lot of material from her research to implement dynamic re-teaming on my program.

    The idea of dynamic re-teaming has been working for us for over 18 months now. We have seen several interesting outcomes from this implementation. For one, the developers, testers and Scrum Masters are constantly on their toes - no one gets too comfortable with their team. But since we are all part of a large 16 team program, we still have managed to build camaraderie, owing in part to team members being reassigned across teams. In supporting a large IT organizations, most of our teams work on small applications for a period of 3-6 sprints. At the end of each such application, the team starts work with a new product owner. This forces the team to do a "reset" and allows them to examine the good, the bad and the ugly from their previous experience. It almost gives the team a chance to wipe the slate clean and start over. This alone has been a great source of inspiration for the teams to continue to grow. Another example of re-teaming is when someone from the development team rotates into a production support team. This idea was initially put in place to ensure that every developer has the experience of fielding user calls for the application that they put out. Being on the receiving end of these calls allows the developers to grow understanding the problems, first hand, from a users perspective. After their rotation, the developer goes back into a team with a renewed motivation to write better code.

    Dynamic re-teaming is core to what we do and I would love to share some experiences in this talk.

  • Liked Jesse Fewell
    keyboard_arrow_down

    Jesse Fewell - Cop-out or Capability? A coaching game for exploring advanced agility

    45 Mins
    Workshop
    Intermediate

    Is your agile stagnant? Are your teams "stable", but uninspired? Have the fancy new frameworks left you wanting more? Then this session is for you.

    When we started our agile journey, experts offered several warnings and checklists for bad practices. From seven agile sins to Scrum-butts, we all know what we must absolutely avoid. But what if the most common anti-patterns are a fertile ground for exploring high performance? What if the sporadic standup is a sign of deep democracy? What if your erratic velocity reflects a self-driven team that jumps on opportunities?

    In this hands-on workshop, participants will confront their deepest held agile convictions, and discover which practices have been holding us back this whole time.

  • Liked Donald Patti
    keyboard_arrow_down

    Donald Patti / Lisa Brown / Meghana Ekbote / Yogita dhond - Scrum in a Snap: Using Snap Circuits to Excite & Educate Scrum Newcomers

    45 Mins
    Workshop
    Intermediate

    The best way to learn Scrum is by doing, but it can be difficult to simulate Scrum and see how well Scrum helps team overcome technical hurdles without actually building something technically challenging. Lego's have always been a fun option for introducing Scrum, but it's difficult to recreate technical impediments, the need for spikes and managing technical debt with our tried and true friend, the box of Lego's.

    Arguably, a better alternative might be Snap Circuits, a toy designed to introduce children to electronics in a fun and easy-to-understand format. Like Lego's, adults gravitate toward Snap Circuits because they are colorful, quickly understood and snap together with ease.

    But, Snap Circuits have the added advantage of requiring a small amount of technical learning during the simulation that make it a closer match to the technical obstacles faced by a typical Scrum team.

    In this workshop, you'll learn one "Scrum in a Snap" simulation exercise. In addition, we'll provide you with a few other "Scrum in a Snap" ideas and encourage you to experiment on your own. Four lucky attendees will also win their own Snap Circuits kit so they can develop their own Scrum games.

    Past participants in "Scrum in a Snap" have said "The best Scrum exercise I've ever done", "I can't believe how much it's like coding - without actually coding", "What a blast - I'll never forget this activity!" and "Where can I buy one?"

    Attend this workshop to see why.

  • Liked Hunter Willett
    keyboard_arrow_down

    Hunter Willett - "Frameworks are Like New Golf Clubs, They Won't Fix a Terrible Swing" How Understanding the Principles of Agile is the First Step

    Hunter Willett
    Hunter Willett
    Agile Coach
    CapTech
    schedule 1 year ago
    Sold Out!
    45 Mins
    Case Study
    Beginner

    We have all been there, a shiny new and improved framework is released and we must implement it, but is this always the answer to improve your Agile organization? Frameworks are needed and provide guidelines for teams but if the teams/companies do not follow the principles and fundamentals of the Agile Manifesto it makes it very difficult for the framework to be successful. The belief is that switching up the specific framework is the answer but they soon realize that the framework is not the main issue that is the driving force. This can leave the teams/companies in a tough situation after committing to a framework that they are not ready for.

    I will be sharing my experiences across multiple different companies on how this assumption has let them down and how we had to return the teams back to the fundamentals to solve the issues they are experiencing.

  • Liked Sharyn Horowitz
    keyboard_arrow_down

    Sharyn Horowitz - Unraveling Red Tape – Being Agile in a Bureaucracy

    10 Mins
    Lightning Talk
    Intermediate

    Sure, we would like everyone to have an agile mindset and focus on continuous improvement, but sometimes as Agilists we need to work with stakeholders who don’t agree with our priorities or our methods. When you need to get something done in a bureaucracy, how do you adapt? Every place you operate has a unique combination of people, processes, and problems. We'll discuss general principles that will help you navigate successfully.