Exhaustion. Numbness. Emptiness. As Agilists, all too often we are seeing teams, organizations, and people that have been transforming for a very long time, and many feel like they have no end in site. Where they were first excited about transformation and trying something new, they are now wanting to be left alone for a hot minute. Transformation isn't something to be completed but rather endured.

In this session, Erin and Yogita will help you to understand what transformation exhaustion is and how to recognize it. We'll also help you to develop--and practice!--ways to show teams their transformation progress as well as how to connect and reconnect with teams. You may have entered the session tired and footsore, but you will leave with new ideas and insight on how to transform your agile transformation.

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.

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.

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.

Agile adoptions hit a speed bump when big, complicated organizations expect User Acceptance Testing, and don't see an Agile equivalent. We'll demystify UAT, and show the multiple places in where it can be found in Agile delivery.

Big and complicated organizations -- particularly government! -- conflate two different ideas in UAT: final sign-off of satisfactory delivery, and (badly delayed) user feedback.We'll explain how getting that user feedback early and often dramatically reduces delivery risk and increases user satisfaction. We'll review tips and ideas to change the approach and walk from the term "UAT" safely.

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.

TSA Agile Services (TAS) began on January 4th, 2017 after extensive collaboration with contracting officials, various bids, and the Agile community. Come hear the aspects that have enabled successful delivery within a government agency. TAS encompasses over 65 applications supported by a team of 80+ people. Also - because transparency is a large key to our success - we will cover the failures we have experienced and the struggles we are still working on. Lastly - it is important for contractors and government to work closely together - this presentation will be co-presented by two Agile Coaches: one is a federal employee and the other a contractor.

In today's IT industry, Agile methodology has become a household word. My 6th grader talks about Agile principles that they learnt in elementary school. Self-organizing teams is one of the principles of Agile methodology. Yet, time and again, I hear Scrum Masters and Agile teams doubt the existence of these said "self-organizing" teams. Can teams really self-organize? What do self-organizing teams look like? What process should I follow to make my team self-organizing? Join me for a talk to decide for yourself.