Add to Google
Agile Architectural Epic Kanban System: Part 3 – State Machine View
Posted on March 23, 2010 by Dean Leffingwell in Agile Architecture, Agile RequirementsIn the last few posts, we’ve been describing an architectural epic kanban system which addresses the objectives we described in this post. Last week, I met with system architects (and agilists) Santeri Kangas, James Cooper, Kuan Eeik Tan and Gabor Gunyho of F-secure Corporation to discuss the model further. We decided that while we liked the big kanban system graphic, it left many ambiguities as to how an epic transitions from state to state, including (for example) how one can be deleted.
To this end, we put together a state machine model to further elaborate the activities and decision properties of the system. It appears in the graphic below.
The state machine table follows:
In turn, this causes a few minor modifications to the kanban system graphic, which appears here:
By the way, for an interesting perspective on architecture in agile in general, you might want to check out this Architecture in an Agile World presentation by James Cooper.
The state transition diagram definitely adds clarity to the overall intent of what you guys are putting together. In principle, I agree with everything outline but I do so being relatively experienced in agile and knowing what to watch out for to avoid a non agile execution strategy for an agile concept.
In the spirit of lean, it would be good to be able to measure the length of time required for a request to come in and get implemented. In particular, we need to make sure that the analysis phase doesn’t turn into a an elongated design effort prior to implementation (i.e. waterfall). To the extent possible, folks executing in the analysis phase should be executing in as similar a fashion as any other agilist. There should be particular constraints in place like
* A design spike should not exceed more than x iterations
* The business case / approval process should require minimal/no sign-off/approval. Ideally it’s something inherent in the execution itself
* Ideally architects remain grounded and “develop” architecture constructs vs. just “designing”
Knowing Dean well, I know what you guys are outlining is well intended to remain truly agile. That said, if I didn’t know Dean well, I would be a bit unclear on how above can remain agile in spirit.
Keep up the good work!
Dean,
I like this. I think there is an important analysis and feedback loop missing. I believe an Epic may move through the Kanban more than once over time. Not all features in an Epic will be of equal value at a point in time. You might pass an Epic through and perform that small subset of the Epic that is needed to fulfill the value goal. Then the Epic could end up back on the backlog for version 2. You could show this refining process and the return queue on your State Maching Table. I think this is important to explicitly call out since our understanding of the Epic is refined as we move it along the Kanban.
Dennis Stevens