“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.
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.
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.
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.
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.
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.
A more detailed description of this particular system can be found here:
 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
© 2011-2013 Leffingwell, LLC and Pearson Education, Inc. All rights reserved.