The introduction of Scrum at a CMMI Level 5 company doubled productivity and cut defects by 40% compared to waterfall projects in 2006 by focusing on early testing and time to fix builds. Systematic institutionalized Scrum across all projects and used data driven tools like story efficiency to surface Product Backlog impediments . This allowed them to systematically develop a strategy for a second doubling in productivity. Two teams have achieved a sustainable quadrupling of productivity compared to waterfall projects. We discuss here the strategy to bring the entire company to that level.

The design goal for Scrum teams is 5 to 10 times waterfall performance yet the majority of Scrum teams never achieve this goal. A pattern is emerging at MySpace in Beverly Hills and Jayway in Sweden, for bootstrapping high performance Scrum teams. Rigorous implementation by an experienced coach creates a total immersion experience akin to Shock Therapy. Unfortunately, management disrupts hyperproductive teams by removing key resources. Velocity data is provided on five teams at MySpace and one team at Jayway where management repeatedly “killed the golden goose.”

When my Scrum-style backlog grows up, it wants to be an FDD feature list … or is it the other way round?’ Why does Feature-Driven Development (FDD) organize its feature lists into a hierarchy? Why does FDD use a specific template to name the items in a feature list? While a Scrum-style backlog for a single team may never grow to more than a couple hundred items, backlogs serving multiple teams may easily do so and become hard to work with. We compare Scrum-style backlogs and FDD-style feature lists, and consider the relative merits of different ways of working with large backlogs.

Our ability to identify patterns of behavior and the likely reasons behind them helps when addressing team dynamics issues. The popular Scrum characters chicken and the pig turn out to be just two of many behaviors that comprise the Scrum Bestiary. Other examples include the seagull - who derails the team and leaves - and the fox - who is intent on stealing vital resources. This humorous workshop presents a taxonomy of some common behaviors on teams and looks at the drivers behind them and strategies for addressing them.

There is no better way to gauge an organization’s culture than to watch its meetings - usually dull and lifeless. Meetings are often cited as one of the most wasteful activities in business - yet Scrum demands more meetings more often. Engineers find themselves micro-managed with little time left to get “real” work done. This session provides leaders a whole new perspective and techniques for Scrum Meetings in building high-performing disciplined teams through focused, active, engaged, visual and time-boxed facilitation techniques to take teams from DOING Scrum to OWNING Scrum!

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.

So what is Scrum anyway? And what is Scrum not? How do I apply Scrum in practice?

Scrum seems to be the most popular agile method at the moment and Scrum jargon is used everywhere. This session is for those of you who have perhaps heard the word Scrum, but never really received a proper introduction to what it actually is. Hopefully you’ll feel less alienated afterwords :o)

When adjectives and adverbs appear in User Stories, they can be easily overlooked and seen as simple adornments to the story. There are a couple schools of thought on how to handle non-functional requirements on Agile projects. Mike Cohn recommends writing a User Story for each non-functional requirement, while others recommend creating task cards to drive out specification using Thomas Gilb’s approach. In this session, examples of various techniques for handling non-functional requirements will be demonstrated, with a discussion of pros and cons of each technique.

This demonstration will show how the Scrum process and many XP/Agile practices can be implemented using Visual Studio Team System, Team Foundation Server, and the Conchango Scrum Process Template in a .NET development environment. The demonstration will follow a User Story from being added to the Product Backlog, through development during a Sprint, to deployment to production, and back again via a reported defect; covering the entire lifecycle cradle to grave.