Lightweight Application Lifecycle Management Using State-Cards


The states for the feature dimension apply a test driven perspective and so you see the acceptance criteria being agreed early in state 2. The final state has an objective of accepting the feature, and not merely testing it. We want feature completion to be feature completion based on having meet acceptance criteria and not just a half-baked work.

The states for the architecture decision apply an architecture trade-off analysis perspective. The scenarios that exercise the decision are first explored before choosing a candidate solution amongst several identified solutions. The chosen architectural solution is then designed into the system and validated.

The state-cards are very useful to discuss and explain lean concepts. The complete flow from the first state to the final state is known as a “Value Stream” in lean terminology. If two consecutive states are worked upon simultaneously, then it makes sense to combine them. You can do so by stacking one state on top of another. Thus, using the state-cards, you can quickly understand and adjust the value stream. You can do other lean stuff like setting work-in-progress limits for each state, measuring the cycle time for each state and so on which I will not go into in this paper. Other work targets and their states can easily be added to manage various other value streams, but this is also beyond the scope of this paper.

Instead I will focus on how to manage different kinds of features. At any point in time, the development team is working on features and decisions at different states of completion. A lean feature Kanban can be defined using the state-cards as shown in Figure 7. The coloured circles represent different kinds of features. The blue ones represent simple features. The red ones represent difficult and challenging features.



Figure 7: Feature Kanban with Different Kind of Features

The Figure 7 illustrates the case when difficult features are blocking the work in feature state 3. The team members here are being overwhelmed and distracted by these features. There are various possible solutions to this problem. One solution is to add more people and have some people focusing on these tough features. But what you will find is that the work being done is of another nature. So, a better solution would be to open up another value stream to solve the challenges. This is depicted in Figure 8. The two arrows represent the flow of simple features and difficult features. The blue arrow represents the flow of fast moving and simple features. The dark red arrow represents the flow of difficult or challenging features. (Note: the cards at the bottom are entitled “Architecture Issue” rather than “Architecture Decision”, but they mean the same thing when applied.)



Figure 8: Feature and Architecture Decision Value Stream

By separating “feature” and “architecture decision” value streams, you ensure a smooth flow in the feature value stream. There would be some coordination work between both streams and this coordination is conducted during iteration planning, or whatever forum a team might have.

5. Organizing Design of Lean and Agile Teams

If the team is small, highly competent (in many areas) and highly motivated, they would organize themselves naturally. However, in most cases, the team is not small and members are only competent in certain areas. Not everyone can do anyone else’s job. In this case, some kind of team organization and role definition would be needed. But at the same time, having pre-defined roles is not good; it has to suit the project. Here the state-cards become handy again.

I group states and associate them with some team members as a way to define responsibilities, as depicted in Figure 9.



Figure 9: Organizing Work across Feature Value Stream

The responsibilities of the team members are described as follows:

  • Product Ownership and Requirement Analysis. I assign the first two feature states as the responsibilities for two persons to play the role of a product owner and requirement analyst.
  • Feature Teams. The next two states are allocated to two feature teams. The two teams are indicated by two groups of avatars at the top and the bottom.
  • Acceptance Team. The final state is allocated to an acceptance team. They are responsible for evaluating the work on a different target environment and so on which is not feasible for the feature team.

About the author

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!