With the growth of agile comes the need to add a new line to the Agile Manifesto: Success over Dogma. The number of people who can say agile is growing faster than the number of people benefiting from agile practices. There are now many successful agile projects, yet there are also a growing number of projects claiming to be agile but not seeing any of the benefits agile methods provide. This session will discuss successful adoptions of agile, dumb things you can do to muck it up, and more.

Just saying you are an agile project does not mean you will benefit. If agile methods are going to work for you, you will need to make them work in your culture. This session will review the healthy and no so healthy use of agile methods. Drawing from a wide variety of examples across many companies and domains, the session will provide guides for adopting or tuning agile methods that will work within your company culture and not simply in some text book. We will also cover near misses and common landmines that many agile projects encounter.

Why do we wait to test? Of course when you read this your thoughts went to testing code. While we still wait to test code and products early, we also wait to test ideas, projects, product direction, meetings and more. This session will show you (or challenge you) to think about test driven beyond the coding realm. You will be doing some thinking and talking and other things that involve more than just listening to someone blather with slides for 90 minutes.

Along with testing driven development, it is possible to test drive projects, meetings, and more. Using vehicles like project chartering, release planning, story tests, we will discuss concrete techniques you can use to infuse test driven into your project community, allowing you to remove duplication and discover dependencies and create stronger, leaner ways to deliver software.

Being agile does not mean living life one iteration at a time. Agile projects without a long view can run into the common design problems of the past. Planning iteration by iteration is often foolish and feeds the myth that agile projects do not think beyond a few weeks. Successful agile projects plan within iterations and across iterations. The later planning is called release planning and it is the forum where agility first engages architecture and other cross cutting concerns.

Architects who think that agile projects evolve code one test at a time are only partially correct. Agile projects review and evolve architecture with unit tests, acceptance tests, architectural spikes, and continuous review of the system's ability to adapt and respond.

There is a home for architects and architecture on agile projects, and other traditional roles, but the there are some new variations. This session will talk about the relationship of agile methods and architecture and design and how they can work together to make stronger products and systems. The session will draw on information and anecdotes will come from projects of all sizes within companies of all sizes, including some large and complex systems.

Although there are many books about agile, but few provide a path for guiding you through the beginning of an agile project. Whether you are preparing for your first agile project, or taking the lead for the first time, this session will provide a guided tour filled with practical advice and a pile of anecdotes.

We will start with things to do to prepare for the first iteration: assessments, project chartering, setting up a lab, iteration 0 and creating your first backlog. From there we will move into coaching practices like fostering discussions, facilitating retrospectives, social radiators, developer manifestos, talking in tests, and more. These are the techniques that will help you lead and successfully guide a newly forming agile community.

Once your agile project is rolling along, there are many bumps and roadblocks which can derail the train. Whether you are leading the project formally or informally, there are techniques you can use to keep the project alive and innovative. This session will cover skills and techniques for leading sustainable project communities.

We will walk through some basics which need to be in place and then we will move on to advance topics like maintaining a living backlog, adapting to change, growing meaningful metrics, radiating information, working with project members, anti-coaching and more. We will also discuss a collection of monitors (spontaneous pairing, ?us? and ?them?, presence of pride, emergence of leaders) used by working coaches to determine which practices to use.

Agile methods have cut through the noise and lighten the burden of crafting requirements documents. While this is good, it also shows clearly see that defining and guiding the creation of software products is challenging work. Most agile projects use a product backlog as a place to hold anything that will improve the product.

Creating strong product backlogs is less defined than many of the other agile practices. Backlogs contain many items: user stories, architectural spikes, investments in updating and maintaining development and other environments, and more. While it is clear that developers primarily code, it is often less clear who adds to and grooms the backlog.

The sessions covers the creation, prioritization, maintenance and grooming of a product backlog. We will cover core topics like user stories and personas, and we will also dig into the challenges of keeping a backlog healthy. We will examine various ways that project communities contribute to and draw from a backlog, and we will examines several example projects and how they have learned the best way to collaborate around the backlog to make sure the product evolves in the most valuable direction.

Why should the value of test driven development (TDD) stay stuck in the realm of coding? The ideas behind TDD are now being successfully applied to the automation of business value. While this has been going on for some time within the agile community, it is not starting to spread to main stream development.

There are more tools are coming available everyday which allow developers, testers, and customers (or product owners) to work together to automate acceptance tests. This process helps clarify the needs of the end user before development begins and removes more of the wasteful work based on incorrect assumptions from vague requirements.

This session will talk about how to get people working together to automate acceptance testing. We will cover the creation of testable work units, like user stories, the collaboration around creating the initial acceptance tests, and several ways for various people in your project community to come together to automate acceptance tests and delivery more and better software.