In the last post, I described the context and objectives for a kanban system for identifying, analyzing and implementing architectural epics in the agile enterprise. This work is being developed in collaboration with Santeri Kangas and others of F-Secure Corp., who are contributing to the model and applying it in their agile development shop. In this post, we’ll introduce the proposed model.
For additional context for this work in process, architectural epics are first class citizens of the agile enterprise in the Big Picture Series (see below)
And the epics themselves are described in the Lean and Scalable Requirements Model:
In the last post, we described the role of system architects and “intentionally emergent architecture” in enterprise class agile development. We also described four primary business factors that drive new, cross cutting, architectural epics:
- New product or service opportunities.
- Changes in technologies that affect multiple products and services.
- Some architecturally-centric problem within the existing solution set.
- Common infrastructure and avoidance of over-investment.
In order to assure that we address the development of architectural runway in a lean and agile manner, we proposed using a kanban system. We also described the three primary objectives for such a kanban system:
- To make architectural work in process (AWIP) visible
- To establish AWIP limits to help assure product development flow
- To drive an effective collaboration with the development teams
Introducing the Architectural Epic Kanban System
Of course, we probably wouldn’t have invested this time if we didn’t have any idea how such a system might work, and indeed, we have been developing it for the last few months. And, as readers of this blog already know, I like to express concepts visually first, so the reader doesn’t have to pour through a ton of text just to build their own mental model for what it is, and how it works.
So, here is another big picture graphic that highlights the relevant elements of the proposed system.
Architectural Epic State Descriptions
The underlying assumption for the kanban system is that epics go through a series of four states, each characterized by different activities on the part of the architecture and development teams and correspondingly increasing levels of investment. They are as follows:
Problem/Solution Needs Identification: The Funnel
The Funnel state is the “capture” state. In this state all new “big ideas” are welcome. They can come from any source. They need no business case or estimates. Tooling is trivial – a document , spreadsheet or simple list on the wall will typically suffice. Since investment is minor, this state is not WIP limited; all ideas are captured for consideration. Funnel epics are discussed periodically. Based on decision criteria, epics in this state can be a) promoted to the next state, b) left in this state, or c) deleted.
The Analysis:Backlog state is more meaningful; epics that reach this state warrant further investment of time. These epics are roughly sized (we’ve indicated t-shirt sizes to avoid overinvesting in estimates). Investment is controlled to discussion level, and perhaps some very preliminary and lightweight investigation. The epic may be elaborated to a paragraph or two.
Since the investment is increasing, this state is WIP limited, primarily by the capacity of the architecture team.
Analysis:Backlog epics are discussed periodically. Based on decision criteria, epics in this state can be a) promoted to the next state b) demoted back to Funnel state, or c) deleted.
Epics which are promoted to this next state deserve a more rigorous analysis, and require further investment. An 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, including 3rd party solutions acquisition, are considered. The affected development teams may estimate the epic. A lightweight business case, with a go or no-go recommendation, is developed. If 3rd party solutions are evaluated, the recommendation is given in priority order.
This state uses scarce resources, so it is WIP limited based on capacity of the architecture and development teams.
Epics that meet the go criteria are promoted to Implementation; otherwise, they are deleted from the queue.
In this state, the epic is moved to implementation and the primary responsibility for the epic is passed to the development teams. This hand-off is effected when the epic appears in release planning. Architect resources remain available on a “pull” basis. (i.e. the responsibility for implementation rests with the development teams, but the architect assists the teams and shares responsibility until the team has developed an understanding of the work required.
This state is WIP limited by the capacity of the development teams and architect’s.
Promotion from State 3 to state 4 is an important economic decision for the enterprise that can be made only by the appropriate authority, based on the developed business case.
In this and the prior post, we’ve introduced the motivation and the model for an architectural epic kanban system. In follow on posts, we’ll develop the model further.