a sense of ownership and empowerment. This is a departure from a process engineer telling them to meet a set of objectives without their buy-in. The best process for the team is what the team defines, not what others define. However, teams usually do not have the background or experience to do so. The state-cards bridge this gap by providing the basic building blocks.
4. Lean Iterative Management with State-Cards
I always tell my clients that development produces two things, features and decisions, based on compromise and negotiations. Ultimately, features are what customers and end-users want. But not all features are the same. Some are very difficult and challenging and need some kind of investigation and consensus before actual development can take place. For these features, some important decisions need to be made. These decisions are usually architectural in nature – they affect the technical architecture and might even affect the business architecture. I have in my deck state-cards for both features and decisions (see Table 2).
Table 2: Feature and Decision States
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.