Scrum in a Snap: Using Snap Circuits to Excite & Educate Scrum Newcomers

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.

 
 

Outline/Structure of the Workshop

In this workshop, you'll learn a "Scrum in a Snap" simulation exercise that you can use when you introduce Scrum to your co-workers, peers or students. In addition, we'll provide you with a few other "Scrum in a Snap" ideas and encourage you to experiment on your own.

As a bonus, four lucky attendees will also win their own Snap Circuits Jr kit so they can develop their own Scrum simulations and practice one of the "Scrum in a Snap" simulations provided.

Here's the session outline:

  • Explain the "Scrum in a Snap" Exercise (5 minutes)
  • Scrum simulation (30 minutes)
  • Sharing & feedback (10 minutes)

During and after the exercise, key lessons about Scrum and why Scrum is so effective for solving complex, uncertain problems will be called out by attendees and the moderator.

Learning Outcome

When finished with this workshop, attendees will be able to introduce others to Scrum and reinforce key Scrum concepts using Snap Circuits.

Target Audience

Individuals seeking a fun, clever way to introduce newcomers to Scrum. This is most likely to appeal to agile champions and change agents, including ScrumMasters, Product Owners, coaches and trainers,.

Prerequisites for Attendees

Individuals attending should be familiar with the basics of the Scrum framework, including Scrum ceremonies, artifacts and roles. Three months of participation on a Scrum team is sufficient.

schedule Submitted 1 year ago

Public Feedback


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

    • 45 Mins
      Talk
      Intermediate

      Despite thinking that organizations are slow to innovate, innovation actually abounds at many companies. Kodak, DEC, and Xerox did not fail due to lack of new, cutting-edge innovation; they failed because their organizations were tuned to their traditional markets, and a failure to change their business models and organizations led to their eventual disruption.

      The key to achieving business agility lies in leadership that transforms organizations. Transformational leaders succeed by changing the system, leading with purpose, and steering from the edges. They own their responsibility and boldly lead their organizations into the future. As leaders, we can accelerate this evolution by enabling true self-management and team-based governance.

      Join Bob and Sanjiv to learn how leaders can transform organizations with a flatter organization structure, work anywhere flexibility, participatory profit sharing, and delegated hiring and firing. Explore the agile leadership journey needed for true business agility.

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

    • 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 / Wm. Hunter Tammaro - Breaking Up is Hard to Do: How to Split a Team (Without Breaking It)

      45 Mins
      Experience Report
      Beginner

      Struggling to fit your Agile team into one room for ceremonies? Daily stand-up meetings dragging on? Finding it harder to keep the whole team informed? It might be time to split into the three- to nine-person teams the Scrum Guide recommends for better communication, collaboration and decision making. But abruptly changing the team structure can disrupt the larger group's dynamic and culture, and by breaking existing lines of collaboration, hurt the sense of team and organizational unity that already exists. By sharing our experience working with a large team at a non-profit client, we will illustrate the challenges that can face an Agile transformation when a team already has a culture of collaboration worth preserving. The lessons learned from our story will highlight not just the principles for nurturing Agility in a team's culture, but also specific strategies we used to overcome challenges and ensure the journey was one all our teams could embark on together.

    • 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 Salah Elleithy
      keyboard_arrow_down

      Salah Elleithy / Ganesh Murugan - Mobbing for learning!

      45 Mins
      Talk
      Intermediate
      “We don’t have time for learning but we want to deliver value fast. And by the way, we need to develop new skills and attract talent but we have limited to no budget!” Huh!
      Does that sound familiar? If it does, you are not alone! This is one of the most prevalent patterns we have seen in organizations. We see this almost everywhere. Leaders and Managers demand that teams deliver value fast with no time to learn new skills. It's an oxymoron or may be a paradox!
      It's difficult (dare I say impossible) to attract talent if your organization keeps doing what it has always done. And if your organization needs to develop new skills internally, how will it be able to do that without dedicating time for deliberate learning?! A vicious cycle to say the least not to mention the impact on morale.
      I am not a mind reader but I could imagine you looking at us with a puzzled look and a thought that goes like, "Ya think!" It would be a valid response, I say, as I am sure you have seen or experienced this vicious cycle in many places. You may be even experiencing it right now!
      In this session, Salah and Ganesh can help you explore concrete ideas for experimentation on balancing speed and learning using concepts from Mob Programming. We can't promise any silver bullets however we do believe in experimenting and learning fast!
      Questions to explore:
      1. What is Mob Programming (or Mobbing)?
      2. Where to find talent/skills currently in your organization?
      3. How to introduce Mobbing to accelerate the learning?
      4. What does it take to amplify the good? (or as Woody Zuill puts it "turn up the good!")
      5. What is mobbing for learning and how does it help solve this problem?
      At the end of this session, you will be able to introduce Mobbing to your organization (perhaps even with a demo), attract developers who really want to shake things up and start finding places to "turn up the good!".
    • 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 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 David Bujard
      keyboard_arrow_down

      David Bujard / Chris Meaker / David Fogel - Impossible deadlines? Fail safely, learn rapidly with Spaceteam

      45 Mins
      Workshop
      Beginner

      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.

    • Liked Jonathan Kauffman
      keyboard_arrow_down

      Jonathan Kauffman - Accept Kanban, or Keep Living a Scrum Lie?

      Jonathan Kauffman
      Jonathan Kauffman
      Consultant
      Coveros, Inc.
      schedule 1 year ago
      Sold Out!
      45 Mins
      Talk
      Intermediate

      Are you lying to yourself? Do you keep using Scrum even though you should have switched to Kanban months ago? Scrum is a popular Agile development methodology, but if it doesn’t make sense for your team, then you might be better off switching to Kanban. I will describe my experience working with a team transitioning to Agile and attempting to use Scrum. We initially did a good job at planning, but external dependencies and unplanned work disrupted our commitments. We stopped planning and fell into the pattern of moving most of the stories to the next sprint at the end of every sprint. I will discuss some telltale signs to help you identify when you shouldn’t be using Scrum and might benefit from a Lean methodology like Kanban. I will also provide you with some practical suggestions that you can use to help your team make the transition from Scrum to Kanban.

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

    • Liked Dr. Patrick McConnell
      keyboard_arrow_down

      Dr. Patrick McConnell - 5 Myths Killing Agile for Government

      45 Mins
      Talk
      Executive

      Over the last 5 years, Agile approaches have seen widespread adoption across the US Federal Government. Where real commitment is given to proven Agile frameworks and techniques, programs do see significant improvement in value delivery and speed. But unfortunately often, ‘Agile’ nomenclature is used while perpetuating behaviors that make real improvement impossible, and may actually make the lived experience worse for participants or stakeholders. And where Agile approaches fail, they add to a narrative that real methods won’t work in this environment. Many of the anti-patterns I’ve seen working as a Coach in the Public Sector are rooted in decision-makers clinging to 5 myths about Agile in Government. This talk will explore these 5 myths, where they come from, and some ways out of them.

    • Liked Kanika Tolver
      keyboard_arrow_down

      Kanika Tolver - Agile Adoption for Federal Government Cybersecurity Teams

      45 Mins
      Talk
      Intermediate

      The process of rapidly addressing cybersecurity attacks and data breaches have become a big challenge for Federal Cybersecurity teams. The agile methodology has been known to work well for Federal software development projects. But, its time for cybersecurity teams to fully adopt agile and the DevSecOps approach to effectively increase transparency, promote security readiness and better secure data within Federal systems. Let's protect the public's data through reducing vulnerabilities, reducing insecure defaults, and increasing code coverage. If cybersecurity teams adopt agile they can begin to break team silos and enhance their risk management processes.

    • Liked David Bujard
      keyboard_arrow_down

      David Bujard - Lightning in a Bottle: Federal DevOps Lessons

      10 Mins
      Lightning Talk
      Intermediate

      The resistance is real in federal programs. We often hold back the power of DevOps by blocking access to production. We’ll see how DevOps leaders bridge the gap in federal delivery, with leadership lessons from lightning.

      Lightning overcomes air’s enormous resistance in short bursts. Government DevOps proceeds in the same way, with significant cultural and policy barriers forming resistance – but also with local champions and moments of alignment that allow DevOps programs to begin to cross that resistance in abrupt, sometimes jagged progression. We'll discuss what helps reduce that local resistance to rapid deployment in federal programs:

      • Breaking governance silos
      • Changing the culture of “No”
      • Decoupling release authorization from deployment authorization
      • Team managed deployments
      • Ongoing security authorization
    • Liked Donald Patti
      keyboard_arrow_down

      Donald Patti - Sure, Delegate...But How?

      45 Mins
      Workshop
      Beginner

      As agile practitioners, we are well aware that we need to delegate decision-making and responsibility to members of the team, but it's often easier in principle than it is in practice. Frequently, delegating triggers some angst in most of us, usually revolving around our biggest fear: "What if they fail miserably?"

      Fortunately, there are better questions to ask before we delegate, including:

      • How can I determine whether the person is capable of handling the responsibility delegated?
      • If they're not ready, how do I help them to acquire that ability?

      In this combination tutorial and workshop, we'll answer both these questions so you can be more successful when you delegate. We'll also give you an opportunity to apply your newly acquired knowledge via in-class simulation and provide information to help you coach others in effective delegation.