Learn how the Corporate Internet Solutions group at Nationwide Insurance found creative ways to manage the competing and vague priorities of corporate silos by incorporating ideation into the portfolio pipeline. As the connection point between otherwise disconnected corporate entities, the Product Owner team adapted the Scrum process to better manage 17 dependent projects, reluctant internal business partners, and suspicious methodologists, by articulating clear Pre-Discovery activities, RITE usability testing, scenario planning, and kanban in the quest for continuous flow.

Plan an iteration - sounds pretty easy right? It can be easy using a well defined framework. This sessions will cover the following:

• Owner or facilitator of the meeting
• When to hold the meeting
• Whom to invite
• Materials - please note that this session is not tool specific other than Sharpies and Sticky Notes! But the plan can be input into your tool of choice.
• Purpose
• Agenda
• Planning Data - what to bring to the planning meeting
• Output & Deliverables - All contribute to the iteration planning meeting

A handout will be provided for future reference.

You’re negotiating a project with a client or internal customer, but they balk when you don’t present a fixed budget and a predefined list of requirements. How do you convince them that the benefits of an Agile team outweigh a top heavy and fragile requirements document? Based on Agile experience with government and commercial clients, we will discuss ways to make your customer feel comfortable with process changes that don’t always result in the same set of documents they are used to.

We are going to traverse the long and winding history of Agile at Yahoo! – beginning with the period just prior to the introduction of Agile over 5 years ago, to its current (and unfinished) state – all from the viewpoint of the Agilista in the trenches. Whether the adoption is driven from the top down or bottom up, progress hasn’t always been in a straight path. We hope that the experiences we share will provide valuable insight for others in their roll-out of Agile in the enterprise, and how the DNA of Agile can survive and even thrive in both supportive and challenging circumstances.

You championed Agile adoption in your organization. Interest grew as your projects become predictable. You led a group of agilists who helped spread the word to more groups. Life was good. Then senior management took notice of the improvements and decided to mandate adoption of Agile. They’ve skimmed some of the books, but don’t have any practical experience. Your agile adoption has just reached a critical stage as it moves from grass-roots effort to management directive. You’re about to lose control of your baby. You’re about to learn that you’ve created a monster.

In 2007 a large consumer electronics retailer faced significant business challenges. In pursuit of new modes of strategic flexibility and fast execution, the e-commerce division transformed its culture around Agile principles and the user experience team adapted its practices to the new paradigm. How would increased velocity affect the quality of the functionality produced? How would time-intensive activities like usability research be affected? This paper presents a case study describing successes and failures while integrating continuous research into Agile projects.

Over the life of a product, Product Owners maintain an ever-evolving Product Backlog. As features rise in rank, the PO breaks them down into stories, eventually sized small so the team can deliver increments of valuable functionality in an iteration. In this tutorial, we will explore examples of how to evolve a product backlog from vision to iteration acceptance. Participants will practice breaking stories down, with an emphasis on understanding the considerations that guide that process. We will provide several examples from different types of projects/products.

Aren’t code, backlog-items, tests, designs & documents all just different forms of system knowledge at different levels of detail? Why can’t the same tools help refactor, browse, search, and provide build/test automation for non-code forms of knowledge without requiring a separate tool/repository for each format?

You create iterations from a backlog of user stories managed via a taskboard with a simple “workflow” from “todo” to “done.” You use Continuous Integration. But in your source control system you’ve just got files and branches. You could create a branch for every story, but that’s a lot of branches to manage! How can you ask the source control system which versions/files correspond to the stories that are done in order to build the “done” version and do exploratory testing? This session will show how to manage changes using stories and how to use branches to represent your workflow.

When we adopted agile we were not looking to reinvent our human resource policies, but our organization changed in fundamental ways that we did not predict. Peers routinely provide feedback to each other on performance. Team members schedule their own reviews. Everyone on the team has an opportunity to work with clients. Vacation schedules are submitted without regard to project delivery dates. We have programmers who job share, and mothers bring their infants to work.