This highly engaging and dynamic workshop will focus on examining the ways to optimize a flow of work through the entire organization. Participants will learn how to expand traditional boundaries of a Scrum team by including Operations, Release Engineers, and Security roles. Inspired by ideas from “The Phoenix Project” and “The Goal", this workshop will use elements of Gamification to make a learning experience fun.

The participants will be using LEGO blocks and chocolates to learn about theory of constraints, continuous flow, minimizing waste, amplifying the feedback loop, leveraging the power of cross-functional teams and multi-skilled team members to improve overall effectiveness in responding to the market change and delivering value.

This workshop has been recently presented at Toronto Agile and Software ( Rating - 8.2 out of 10)

More info about it: https://www.linkedin.com/pulse/article/20141116191200-10274141-introducing-devops-gamify-it-with-chocolates-and-lego?trk=hb_ntf_MEGAPHONE_ARTICLE_LIKE

As a business analyst on an agile team, do you spend your time gathering decisions from Product Owners (or stakeholders) and passing them on to development teams? Are you tired of simply being a “proxy without power?” What can you do to boost your impact and become invaluable to your team?

In this workshop, Diane Zajac-Woodie demonstrates how any team can benefit from the communication and facilitation skills of an experienced BA. Through some experiential exercises, you will learn what impact collaboration has on results and why requirements are just as important as ever. Diane also teaches you how to document requirements so people will actually read them. Using Acceptance Test Driven Development (ATDD), you will practice writing requirements that describe the exact behaviors that you expect in a format that everyone understands.

Be inspired to embrace your role in an agile environment and leave with new techniques that encourage more cohesive teams and ultimately lead to higher quality software.

If you could single out just one Agile practice which gives the most bang for your buck, that would undeniably be a retrospective!

Retrospective allows a team to inspect and adapt it’s process. For a team that is distributed across different locations and time zones retrospective becomes a must!

This workshop will examine the ways of using  elements of Gamification to reenergize retrospectives and help the team to become better.

We will  looks closely at some of the most common retrospectives anti-patterns. As part of this hands-on workshop attendees get to experience, compare and contrast a number of facilitation frameworks that they can bring back to their organizations. 

This session proposal is a fourth iteration on this topic. It combines some of the ideas from Gamification lightning talk ( Agile2014) and incorporates feedback from Opens Space sessions that were facilitated at Agile Day NYC, Global Scrum Gathering Berlin and NYC Scrum User Group. 

Ken Schwaber, a co-creator of scrum, says that only 25% of teams trying Scrum actually realize the gains they had hoped for. Another informal poll shows teams callling themselves "Scrumbut", "Scrumerfall", or "Scrumish" than actually claim to successful!

It is as if something conspires to make Scrum ineffective. 

Let's get real. Scrum is designed to expose problems. It does not, by itself, solve the problems. In theory, Scrum provides a framework for the team to work through the solution themselves. In practice, politics, rhetoris, and lack of training often get in the way.

This talk is about understanding common Scrum problems and breaking through ruts.

In this conversation Matthew Heusser and Wade Wachs will discuss the heart of Scrum, where it goes wrong, how testing can enable Scrum success - and how team members can improve their visibility and role while contributing to Scrum and team long-term success.

As an enthusiastic problem solver and solution designer you were thrilled to be asked to {design the UI | architect the system | design the kanban board | solve the bottleneck | plan the office mini-golf course | storm the castle}. You researched the problem, weighed the options, considered the alternatives, and put your best effort into the final deliverable. Your presentation to the team was flawless - not one PowerPoint slide with more than 5 words on it! But, while everyone knew that your solution was awesome, it was ultimately trashed, warped, abused, tortured, discarded, and ignored.

What happened? You fell victim to one of the classic blunders - the most famous of which is "never get involved in a land war in Asia" - but only slightly less well-known is this: "Your design sucks because it isn't mine."

At this point you must be wondering - "If we only had a wheelbarrow (i.e. Design Studio), that would be something." Join me for a workshop on using the Design Studio Approach to achieve effective collaborative design. Have fun storming the studio!

Improvisational Comedy (also called Improv) is a form of theater where the performance itself is created in the moment. Successful improv involves using a variety of skills and techniques, which allow performers to quickly adapt to a constantly changing environment and new information. Now, reread the last sentence, but replace “improv” with “testing”. This mildly interactive presentation will highlight a few of the many similarities between improv and testing. Creative metaphors and critical analysis will provide novel and notable ways to think about testing. From stage fright to test summary report, and everything in between…attendees will laugh, learn, and leave with knowledge to help Improv(e) Your Testing!

Creating a backlog of user stories is pretty straight forward but it doesn't help you when it comes to decisions like what to build first, how to prioritize and groom the backlog, how to slice your stories, how to scope and plan the project, and how to visualize progress. The traditional backlog is simply too flat and often too long to help you see the bigger picture and make good decisions. User Story Mapping helps simplify all of these common project issues. By adding a third dimension to your backlog, your team will make better decisions about priorities, scope, and planning while improving your ability to visualize progress.

In this practical tutorial we'll focus strictly on creating story maps. We'll start the tutorial by creating an introductory map that will help you understand the basics. The remainder of the tutorial we'll create and then refine a story map map based on a project overview and some given scenarios. After this tutorial you'll be ready to create maps for your own projects.

As individuals we often struggle to move from working together simply as a collection of people to acting as a cohesive team. Establishing shared understanding of the problem we are trying to solve and the capabilities we bring to the task can be difficult. At the heart of the challenge is making our thoughts tangible and meaningful to others.

Using Lego® SeriousPlay™ materials and methods to surface and express what is inside ourselves is a powerful technique for energizing teams. Based on cognitive neuroscience and learning theory these techniques have been proven to be effective in a broad range of contexts and group sizes. Deliberate play is a key component to social interaction and creative problem solving in groups.

And it's fun!

Are you ready to begin your journey as an agile coach? Are you already a coach who is looking to grow your mindset and skillset? Are you in an organization and want to see its agility go to the next level? If so, invest just 45 minutes in this experience report about growing coaching within an organization.

Building coaching skills isn't the exclusive domain of a multi-day training session. In fact, the best way to build a new skills is to gradually introduce them over time and use intentional practice to build those new skills into a habit. This session is based on running coach mentorship programs that spread the learning and practice over a period of months.

Questions we will answer in this session include:

Why is a coach mentorship program integral to growing an organziation's agility?

What are some mistakes to avoid when creating a coach mentorship program?

How can intentional practice be integrated into a coach mentorship program?

What can be done to have an effective program where participants are in different time zones?

How do you build support for investing time and money into a coach mentorship program?

You will leave this session with a set of practical tips for setting up your own coach mentorship program.

While this experience report is based on multiple iterations of building a Coach Mentorship Program within a Fortune 500 company, the lessons apply to an organization of any size.

Experience agile in a fun, insightful, high energy, simulation where you will work in iterations to build products, test them, and apply feedback.  You will participate on a team and use a backlog, business values, sizing, and prioritization.  You’ll plan, execute, deliver, and reflect.  

This session is a great way for you to experience working on a team in quick iterations and to see first hand how team members can gel quickly, combine skills, learn by doing, and achieve together.  If you have  been working on teams for a while, this simulation will help you see your current process in new ways and open up new opportunities for improvement.  

Don’t worry, no technical skills are required - anybody can participate.  We have run this exercise with a number of different groups and the results are consistent - lots of energy, lots of insights that can be taken back to the real world, and lots of fun!

There has been a lot of talk lately about Software Craftsmanship. Most of this talk has been centered around how to take existing, skilled programmers and turn them into Craftsmen. What about those who are just entering the field? In this talk, we will explore a new approach to fulfilling the entire journey from Apprentice to Master, both from a personal and organizational level. We will also look at how to get such a program started, and how to bring the existing team along.

Are you tired of TDD workshops that make you do boring things like calculate bowling scores and prime factors or demonstrate how to win at the game of life? If so, this is the session for you In this TDD workshop we will be building the domain model for EverCraft -- a new MMORPG from Blizzards of the Coast. We have lots of story cards prepared covering features from combat to magic, classes to spells, and races to items. Plus, we'll be defining some of these cards during the session in case you want that +9 knife of ogre slaying or enjoy casting magic missile at the darkness.

This workshop is language agnotisic and for all levels of developers. The focus is on TDD and emergent design but pair programming will be covered as well. The only requirement is that you bring a laptop and that you be able to test-drive you code with your language of choice. When you are done you will emerge a better programmer for the experience but there is small chance you will have a craving for Cheetos and Mountain Dew.

In many respects, developing training is a lot like developing software. Define the needs, identify scope boundaries and buckets, build, deliver … and cross your fingers. And, like all interesting software projects, the scope and need changes after the project gets started. What’s a trainer to do? Use Agile, of course. But that’s often easier said than done.

We’ve adapted Agile for instructional design and development projects – we call it LLAMA (the Lot Like Agile Methods Approach) – and it’s gotten a lot of traction in the training industry.

When delivery issues are made visible, there is often an immediate and natural change in behavior. In this session I will demonstrate a simple technique we have used with several teams at my current client to track Cycle Time and Process Cycle Efficiency (PCE) using Lego. In some cases, team members started to behave differently right away, as soon as they saw where the time was going. Two interesting effects occurred naturally, without any training. First, teams that saw a lot of red Lego on their boards adjusted their work in process (WIP). They didn't know the term "WIP" but they could see the effect and acted appropriately on the information. Second, the moment a team mate placed a red brick on the board, other team members asked what the impediment was and how they could help remove it. 

Scrum suggests that business analysts, testers and developers shed their old job titles and don the badge of “team member.” And current trends like mob programming further encourage team members to abandon their individual goals in the interest of team achievements. It seems there really is no “I” on some teams...but should there be?

In this session, Diane evaluates the pros and cons of eliminating job titles and examines the concept of becoming a generalizing specialist. What does that really mean? What are the impacts to the team? Can you maintain your individual skills while your contributions to the team are getting blurred?

Come and join in the discussion!

Agile Manifesto sez: Our highest priority is to satisfy the customer through early and continuous deliveryof valuable software.

Why doesn’t being “Agile” always mean creating innovative, world-changing, valuable software?  This session will focus on the tools and techniques of Requirements Craftsmanship and Lean-Start-up including understanding and creating Business Value, Value Stories, Story Mapping, and Getting out of the Building, that are the building blocks of value for Agile teams and, importantly, the customer and stakeholders for whom Agile teams create.    Participants will also explore the differences between measuring the output from Agile teams and measuring the outcomes that indicate value acheived.   This session will give participants real experience Requirements Craftmanship and introduce them to the challenges of making sure that Agile teams produce valuable software early and continuously, which is the highest priority of the Agile Manifesto and the goal of Requirements Craftsmanship.

Have your retrospectives turned into nap time?  

Whether it's a minor typo on a page, a major failure causing a severe outage of a system or anything in between, the software industry is fertile ground for examining problems and their causes. From the problems that plagued HealthCare.gov to defects that allowed some lucky people to purchase airline tickets for almost nothing from United airlines, we hear a constant stream of issues with software systems.

With our society becoming increasingly dependent on software, we need to "up our game" with respect to tracking down problems with they happen, ensuring that defects are caught before entering the wild, and are prevented from occurring in the first place.

Root Cause Analysis is a process that enables this form of continuous improvement and uses techniques borrowed from other engineering disciplines. The aviation industry, for example, constantly seeks to improve due to the dire consequences of any failures in that domain.

This interactive workshop will explain when and how to use Root Cause Analysis (RCA) to investigate problems and determine actions that will ensure that those problems can never happen again. Using real world examples the attendees will explore simple, lightweight RCA practices as well as a more involved example using fault tree analysis.