“Open the pod bay doors, HAL.”

– 2001: A Space Odyssey (movie)

Architectural Epic Kanban Abstract

The Framework suggests the development and implementation of kanban systems for business and architectural portfolio epics. While these kanban systems operate in a nearly identical manner, they are described as separate systems:

Business epics are typically under the auspices of business unit managers, portfolio, product line, product managers and business analysts
Architectural epics are typically under the auspices of the CTO/technology office, which includes enterprise and system architects

This Framework page summarizes the implementation and use of the kanban system for architectural epics. The business epic portfolio kanban system is described elsewhere.

Implementing an effective architectural epic kanban system is not a trivial undertaking. It requires a reasonable understanding of lean and Agile, and the productive capacity (velocity available for new development) of all the release trains. But it’s not a particularly complex undertaking either, as the mechanisms behind kanban are themselves very straightforward. In addition, such a system can initially be simply superimposed on the existing process and evolved fairly quickly thereafter.

Effective implementation of such a system can be a key factor in achieving enterprise agility and optimizing business outcomes.

Details

Motivation for a Kanban System for Architectural Epics

The kanban system is applied in this context for a number of reasons:

Make the Architectural Epic backlog and ongoing analysis visible to all
Provide WIP limits to ensure the architects and teams analyze responsibly, and do not create expectations for implementation or timeframes that far exceed capacity and reality
Help drive collaboration amongst the key stakeholders in the business and Development Teams
Provide a quantitative, transparent basis for economic decision-making for these most important technology decisions

A Prototypical Kanban System for Architectural Epics

In Agile Software Requirements [1, Chapter 21], we describe a kanban system like that depicted in Figure 1.

Figure 1 Architectural Epic Kanban system

This particular kanban system describes four queues that an epic passes through on the way to implementation (or rejection):

Funnel–the capture state, where all ideas are welcome
Backlog–where preliminary estimates of effort and cost of delay are established
Analysis–where the work is done to establish technical viability, impact, and availability of resources
Implementation– where epics are allocated to the release trains that are impacted or that are available with the resources and skills necessary for implementation of that particular epic

Description of the System

1. The Funnel – Problem/Solution Needs Identification:

The Funnel queue is the “capture” queue. In this queue all new “big ideas” are welcome. They can come from any source, but typical drivers for these larger initiatives include:

New product or service opportunities
Changes in technologies that affect multiple products or services
Problems with the existing solution set
Architectural governance, such as common standards, platforms, etc.
Common infrastructure and avoidance of duplication of effort
Driving innovation
Lowering solution cost

In this queue, epics need no business case or estimates. Epics can be stated in any format here, typically just a short keyword or phrase such as ”migrate all solutions to JBOSS”. Tooling is trivial – a document, spreadsheet or better, a visual kanban system on the wall will typically suffice.

Since the investment of effort of items in this queue is minor, this queue is not WIP limited; all ideas are captured for consideration. Funnel epics are discussed on a periodic cadence established by the architecture team. Epics that meet the decision criteria are promoted to the Backlog queue.

2. Backlog

Epics that reach the backlog queue warrant further investment of time. In this queue, epics are roughly sized, and some estimate of value is established. Time investment is limited to discussion level, and perhaps some very preliminary investigation. The epic may be elaborated in the form of the Epic Value Statement template, which captures a description, value, and and strategic differentiation that this initiative can provide.

Since the investment is increasing, this queue is WIP-limited to limit the number of active items in process. Backlog epics are discussed periodically. Epics are assigned a Cost of Delay (CoD). Epics that rise to the top of the queue are pulled into Analysis as soon as space is available.

3. Analysis

Epics that make it to this queue deserve a more rigorous analysis, and require further investment. A System Architect is typically assigned as the epic owner. An active collaboration with development is initiated. Design alternatives are explored. Options for internal development and/or outsourcing are considered. A lightweight business case, in the form described here, with a go or no-go recommendation, is developed.

Items in this queue use scarce resources, so it is WIP-limited based on capacity of the architecture and development teams and the desired throughput rates for items in this queue. Promotion from Analysis to Implementation is an important economic decision for the enterprise that can be made only by the appropriate authority, based on the developed business case. Epics that meet the go criteria are promoted to Implementation.

4. Implementation

In this queue, the primary responsibility for the epic is passed to the development teams. Architect resources remain available on a “pull” basis: the responsibility for implementation rests with the development teams, but the architect assists the teams and shares responsibility until the team has developed a sufficient understanding of the work required.

This queue is WIP limited, in this case primarily by the capacity of the development teams and the amount of investment in architecture that is required.

Learn More

A more detailed description of this particular system can be found here:

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

A thorough and contemporary view of kanban systems in general can be found here:

Anderson, David. KANBAN. Blue Hole Press. 2010.

Last update: 1 May, 2013