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.