Plan to Adapt – Part One

January 26, 2014

As I covered in Chapter Two’s The Depth of Agile discussion (in the What is Agile Development? post), agile is built from a foundation of Lean and Learning Organizations. Focusing on the business is one way of categorizing the values, principles and characteristics that serve as our foundation. Conceptually, the Business category is one pillar of what will be a House of Agile that has a common foundation:

Figure 3-10

The House of Agile is a model to act as a guide for reflection and conversation. By focusing on one pillar (I’ll add more in upcoming posts) we can ask ourselves what it means to be agile from that perspective. If we consider what it means to be agile in a larger business context from that of a development team, a couple of questions come to mind:
  • How do we plan, budget and govern our strategic initiatives to maximize ROI from an agile perspective?
  • What fast, cost-effective, lightweight techniques can we use to improve our decision-making on what to pursue from a strategic perspective?
We want to avoid is building a product based on speculation because it is extremely wasteful to build the wrong thing the right way. This happens all too often already; roughly three-quarters of the money invested in product development work results in products that do not succeed. (Christensen & Raynor, 2003)

Forecasting without Details

January 13, 2014

A good Product Backlog is an enabler, allowing agile teams to:
  • Get to work quickly, deferring on elaborating all of the details up front.
  • Accommodate changes quickly and easily, maximizing value while keeping the cost of change low.
In order to accomplish this, the Product Backlog should have four qualities that make it DEEP (Pichler, 2010):

Figure 3-8

Agile teams pull work from the top of the Product Backlog, where items are more finely defined than they are towards the bottom. This is what is meant by being detailed appropriately. Each Product Backlog Item, or PBI, in Figure 3-8 is represented by different sized blocks. The larger physical sizes of PBIs further down in the list in Figure 3-8 visually represent the greater scope relative to the smaller, more narrowly-defined PBIs at the top of the backlog.