- be conducted to build and deliver the system. This includes milestones, schedules, and so on. It answers the questions “when” and “how soon.”
- Team. This is the teamwork aspect. It is about how well the team is working together and how they collaborate with others outside the team. It answers the questions “who” and “how well.”
The state for each aspect is summarized in Table 1. For brevity in this paper, I will not go into the criteria for each state. Anyway, the criteria only serve as a guide. Most teams would adjust them anyway, but I have found that the states themselves are fairly generic. I made a deliberate attempt towards a very small number of dimensions for simplicity as I believe most teams can fill the missing bits themselves. I want to start light - as light weight as possible. Incidentally, there is ongoing work in the SEMAT initiative  to define these dimensions universally.
Table 1: Application Lifecycle Dimensions and States
As I explain here, for each state, I ask the team members in which state is their development.. If a particular state is completed, I will move the card to the left. For those states that have yet to be achieved, I will shift them to the right. So, completed states are on the left and pending states on the right.
Figure 4: Determining Development State
Then, I do something very important. I take the first pending state and put them in the middle and I push away the completed states and the other pending states. The result is shown below in Figure 5. I call this “Parting the Red Sea.”
Figure 5: Determining the Next Development Target – Parting the Red Sea
Even though each card is concise, it is important to reduce the number of cards in play. So, I take the 4 cards in the middle column and lay them out in front of the team and tell the team these cards represent their immediate goal in order to meet these targets. This is their next immediate milestone.
Figure 6: Formulating the Next Milestone Definition
Of course, it would be useful, even comfortable, to have some canned definitions of milestones. The Essential Unified Process has such a mapping of states to the Unified Process milestones, i.e. Inception, Elaboration, Construction and Transition. You can do likewise with the cards I have.
However, I prefer a more dynamic approach as I have previously described. Having the team coming up with their milestone definition is powerful. You give them 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