“Speed Enablers” of Agile

February 24, 2014

My previous posts that comprise Chapter Three were all about the business end of agile. I outlined how work is initially defined and progressively refined throughout the delivery process. I also covered how work should flow to teams along with how those teams manage that work and emergent change. And while this is a great start, there’s more to being agile.

As we look at how software teams deliver a solution, we need to examine the technical practices that are used in conjunction with an approach that supports lean and agile values and principles and the characteristics of learning organizations (these are covered in more detail in my post, What is Agile Development?). Technical practices are the second of three pillars in the House of Agile:


Figure 4-1


Plan to Adapt – Part Two

February 18, 2014

In my last post I put forth a simple idea management approach that involved an Investigating step as a means of assessing and refining ideas and concepts. What does this look like from an agile standpoint?

One of the primary needs is to obtain customer feedback as rapidly as possible, for the least amount of cost and effort. We need a tool that enables us to engage with and iterate with potential customers quickly and easily while assessing whether an opportunity is worth pursuing. One such tool is Ash Maurya’s Lean Canvas shown in Figure 3-13, which is an adaptation of Alex Osterwalder’s Business Model Canvas:


Figure 3-13 The Lean Canvas

The Lean Canvas is divided into two sections: Product and Market, with Product on the left–hand side and Market on the right-hand side. You fill in the canvas by moving between the two sections:
  1. Problem: Identify and briefly describe your top three problems that your product is addressing.
  2. Customer Segments: List who the customers are, and determine if they can be further segmented. If they can, it is recommended that you create a new canvas for each segment because other elements of the canvas will likely be different for each segment.
  3. Unfair Advantage: What do you have to offer that can’t be readily copied or bought?
  4. Solution: What is the minimal feature set that will satisfy your customers in ways that they will pay for?
  5. Key Metrics: What actions will users need to take that maps to acquisition, retention and revenue?
  6. Channels: How will you reach your customers?
  7. Cost Structure: What are fixed and variable costs?
  8. Revenue Streams: How will you generate revenue?
  9. Unique Value Proposition: Based on this information, what is the product’s primary differentiator and reason that it is worth buying?

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.

Happy Holidays!

December 24, 2013

It's that time of year, and I'm taking a couple of weeks off from regular blogging. I wish everyone all the best, and I look forward to an exciting 2014!

More Communication, Less Documentation

December 15, 2013

Document-centric processes have taken hold in many organizations, and they are now drowning in that documentation. As companies want to understand how to get faster and be more innovative, one key is to document just enough and have conversations that drive towards more innovative, productive results. As we’ll see, agile development provides a framework for making this happen.

The Product Backlog as Communications Hub
With agile development using Scrum (the most popular agile framework in use today), we overlap product definition and delivery activities by incorporating a coordinating mechanism known as a Product Backlog. Conceptually, the Product Backlog fills that previously blank overlap area between product definition and delivery that I included in my Cone of Uncertainty diagram in my last post. Figure 3.5 shows the Product Backlog occupying this area:
Figure 3.5
As you may thinking based on the previous material, this model doesn’t fit agile development because the Cone of Uncertainty is created by plotting two points that represent the variability present at a given point in time, which are based on traditional project phases of project inception, requirements elicitation, design, develop and test (plotted from left to right on the diagram). And you are quite correct.

This model is useful to illustrate that with agile development, we are striving to keep the costs down in comparison to traditional approaches. The left-hand side of the cone – the Define area – where the cone is the widest and where we have the greatest variability and uncertainty, so we want to avoid overinvesting this area by creating large batches of detailed requirements along with plans and schedules that are cast in concrete based on those requirements. This area is where a great deal of waste originates, as any planning that we are doing is relying on information that most likely will change when we get to the brass tacks of actual implementation.