In replacement projects one of the biggest questions is what strategy to use in replacing the old system. The simplest strategy is to wait until the new system is “at least as good as the old one” before switching. Although this strategy sounds compelling it has many serious drawbacks. An alternative strategy is based on what I call a “Minimal deployable entity”. Switch systems when you have just enough to be able to survive with the new system. The concept is similar to “Minimal Marketable Feature” but more focused on deployment strategy.

By now, your company has made the transition to Agile. “Sprints”, “backlogs”, and “retrospectives” are everyday words, but you’re also discovering the serious challenges that software agility brings to product management. The Product Owners, who have been scattered across multiple teams, are not cohesively aligned around the same prioritized set of corporate initiatives and strategies. In addition, there are cross-product dependencies that are not being effectively recognized and addressed. My company’s solution was to build a single, enterprise level, Unified Backlog.

Many agile methodologies assume a customer (or product owner) walks into the room with a swack of money and a pile of story cards and tells the development team to start building the functionality described on the top few cards. This tutorial provides an overview of what needs to go on “behind the scenes” between when a project is conceived and when development can start in earnest. It identifies the artifacts that may need to be produced, whether and when they should be produced, which activities can be used to produce them and who should be involved in those activities.

Experienced product managers working with agile product teams for the first time are stuck between old methods and new ones. Developers are requesting new artifacts, advocating new meetings, and defining new roles. Old processes and artifacts that seemed to be working are not valued by agile teams. While developers are learning how to deliver working code faster, without agile product management the team might be building the wrong things. Agile product managers and product owners face issues focusing on the business, technical, marketing, and sales roles required for effective agile teams.

The software development industry has a poor track record with metrics. Many metrics are tangential to development’s goal of delivering business value, and are thus ill-regarded by agile developers. However, good metrics are important to management, in order to understand the status and progress of their teams, and to make projections into the future.

In this class we discuss velocity, burndown graphs, EVM metrics (CPI and SPI), and earned business value, including methods for calculation, why they’re important, and how they enforce (or fight against) agile values.

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.

Traditional product managers have broad inbound and outbound responsibilities including segmentation, requirements, positioning and pricing - often shortchanging their teams. Product owners are always available and own backlogs/stories - but often lack real market experience. Both roles have challenges. PO/PM discussions are short on context and clarity. How can agile address the broader product mgmt challenge? How to agilize waterfall PMs? Do technical POs need marketing/sales/pricing skills? We’ll look at roles and organizational models that work for commercial software companies.

This talk will look at the product owner role on an Agile team from a Pragmatic product management perspective. Many software development companies rely on their product management organizations to represent the needs of customers and the market. Concentration on problems, the people who have them, and the circumstances under which they experience those problems is what makes the marriage of Pragmatic product management and Agile so valuable. This presentation will describe how the Pragmatic approach to the MRD gives the Agile product owner a headstart and the entire Agile team an edge.