DevOps has become all the rage from a technical change perspective; it really has changed the game. And while it provides numerous benefits, only after you also embrace the human side of change within the organization, can you really get to full Agility.

What if we could take advantage of a continuous delivery of change just like we do in our development pipelines? As executives, managers, Scrum masters, coaches, or anyone else in a leadership role, we should desire to make each change focused, easy, and small to contain risk. Once this is done, changes can mimic a development pipeline that delivers towards a business outcome. This workshop will help you learn how to keep the number and size of changes in check and consider how to manage the risks of deploying change.

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.

Product owners face a challenge: potential new markets are vast and full of unknowns. Current thinking in successful product management recognizes the importance of learning about potential customers
and adapting product decisions to reflect those insights. However, many exercises and workshops
geared towards product owners treat target products and markets as a fixed, concrete objective—failing to include any market feedback

Dicey Markets is a product owner simulation designed to reflect many of the forces driving product owners, including unknown information about the market, competitive pressure, and technical debt. The simulation
emphasizes the role of rapid regular feedback in creating successful products in the face of uncertain markets.

The Agile Manifesto says, "Individuals and Interactions over Processes and Tools," but what I increasingly see in practice is "Tools are the Process, mediating all Interactions between Individuals."  Two years ago, I pointed out the dangers of letting planning tools take over your planning meetings.  I didn't realize that they could take over standups and even intra-team communication as well!

This talk will show how to get out of the Wholly Tool-Focused trap by (1) clarifying the questions your team should be asking about your process and tools and (2) presenting alternative physical tools with a proven track record.

It can be difficult for developers to find the motivation to write automated unit tests.  This workshop introduces a simulation that can demonstrate the value of automated unit tests to identify and localize defects.  In the simulation, participants will play the roles of programs and tests.  We will discuss barriers to creating and maintaining unit tests, and how this simulation addresses those barriers.

Theme: Games for Learning, Code and Test

  (We have not published slides for this workshop.  "Slides" link below is to representative slides from other presentations.)

Agile planning tools started simple: index cards, markers, and a table or wall. On many projects, for many reasons, these old stalwarts have been supplemented (or even replaced) by software solutions: Rally, VersionOne, Jira Agile, Trello, Trac, Scrumy, and literally dozens more, even BaseCamp. These tools have undeniable advantages over cardboard and ink in some aspects, but they're not superior in every situation.

This session will highlight the pitfalls of centering planning meetings around software tools—even the best ones, like [your ad here]—and make a badly-needed sales pitch for index cards on a wall (compensating for Oxford's oddly anemic marketing effort). You'll see how cards can make better use of your team's time and brainpower, promote parallelism in meetings, and increase engagement by all participants.

Lean Software Development, largely created and popularized by Mary and Tom Poppendieck, is a set of principles and tools for approaching software with a value-focused mindset.  Heavily influenced by Lean Product Design, itself the result of porting Lean Manufacturing insights over into the design realm, it can change the way you think about what you're doing and why.  Lean emphasizes the performance of the entire software-development system, and strongly cautions against optimizing pieces at the expense of the whole.

This session will be a whirlwind tour through seven principles of Lean Software Development, and one thinking tool associated with each principle.  The common thread of focusing on value, instead of on requirements or process or utilization, ties the concepts together.

You're hit with a problem, possibly repeatedly, and it's not clear what to do about it.  You know that Root Cause Analysis can help, and you know a Five Whys exercise is a good way to do that.  But how do you run a Five Whys?  There's more to it than putting everyone in a room and saying "Why?" five times, isn't there?

This session will prepare you to run your own Five Whys exercises, and to answer important questions like who to include, how to introduce the exercise, what to do when the group stumbles, how to deal with prematurely-offered solutions, and how to prepare for the exercise.