A series of cartoons depicts the terrible things that happen when agile practices aren’t followed. This session is valid for any persona, but especially for the product owner who will suffer when their product fails because they follow a process that isn’t helping their team deliver!

Starting up an Agile team is one of the first things you might be asked to do when a company wants to “go Agile.” What do you need to know before starting up a team? In the start-up, how much do teams need to know about Agile before they “go”? What do they need to know about each other…what the project is all about…who they will become as a team? These and other questions are answered as we walk through good ways to start-up Agile teams.

How do you become agile with all the constraints surrounding you and your team? This tutorial introduces a new way to approach agile adoption efforts. We will go through important and key concepts related to agile adoption such as adopting values not practices, the difference between education and training, readiness assessments, and the process of organizational change. One of the tangible outcomes from this tutorial is a roadmap to agility that consists of five different levels, or steps, along with the different practices that can help an organization achieve each level of

Inkubook.com came into existence in March 2008 when an existing software development and marketing organization received a new CEO and was immediately tasked with building an entirely different product. This report discusses the evolution from the existing Scrum process through four major changes as the team’s process shifted to meet the team’s goals and management’s demands. Focus will be given to the barriers benefits that the team perceived with each stage. Where possible, a discussion of the unintended consequences of the team’s actions will be explored with specific examples.

Over the last ten years, Test-Driven Development has grown from something exotic, that only a handful of people knew about, to near- commodity. So there’s nothing left to say, right? We don’t think so.

In this talk, we’ll review some of the landmarks in the history of Test-Driven Development and what they tell us about how to develop software; the ideas, techniques, objections, and misunderstandings.

We’ll talk about our experiences of discovering TDD and what we’ve learned about how to do it well, how to adopt it, and how to bring it into existing code.

The Agile Alliance states that “The Gordon Pask Award recognizes two people whose recent contributions to Agile Practice make them, in the opinion of the Award Committee, people others in the field should emulate.” This panel brings together some of the previous winners so that they may share their contributions and help encourage others to participate in building the body of Agile knowledge. For the intermediate practitioner, it should reinforce the notion that as we practice Agile and learn how to adapt for the best outcome, sharing what we learn helps the whole community.

This report describes how scrum was adopted by more than half of the software developers at Amazon.com (and counting). The adoption was due largely to the efforts, both accidental and purposeful, of an internal employee. Amazon’s corporate and development cultures played important roles, both positive and negative. With no executive sponsorship, adoption occurred primarily a team at a time. The wide range of success across teams and organizations leads to a number of important lessons learned with regard to enterprise scrum adoption. The lesson: you can cause this to happen.

This talk summarizes the results of 4 years of industry surveys concerning the adoption and effectiveness of agile techniques. Very often the reality is significantly different than the rhetoric presented in mailing lists, in articles, and even in books. How effective are agile approaches compared to traditional approaches? To iterative approaches? Are people modeling? Writing documentation? Doing TDD? How much co-location is actually going on? How many organizations are really doing agile? To what extent? Come and find out answers to these questions and more.

Engaged as a software consultant at a financial services company, we brought up the topic of Agile early on and were told, “No!” A Vice President at the company said that Agile had been tried there and failed, so the management decided that Agile was a waste of time and money and would be prohibited. Despite this edict, our team cleverly succeeded at covertly injecting “The approach that shall not be named” into a couple key projects. Our success caused management to reverse its firm anti-Agile stance, and the whole organization is now moving in that direction.