Light Weight Application Lifecycle Management Using State-Cards

Mingle, EssWork, JIRA, Visual Studio Team System, and so on.

The use of cards is common with agile methods. Project teams often write down stories in a card and track the development of the story by tracking the state of the story. What is lacking is some form of guidance, or some indication of completion criteria for each state, which is normally not captured in cards. My cards fill this gap by putting check points for each state within a work target card. This interestingly opens up new ways of using the cards.

The form and substance/contents of the cards are inspired by my participation in the design and development of the Essential Unified Process and EssWork [1]. The cards in EssWork are A6 in size (i.e. they are bigger). EssWork places more emphasis on the work target itself (which they call alpha) than on the states as their primary usage is practice composition. Moreover, EssWork still has many cards and text. So, there is still an issue of information overload even though it has been reduced drastically from traditional methods of describing processes.

I was watching a team playing Planning Poker and was concerned that the cards in EssWork could not be played in a similar way. True, the cards in EssWork help the team members understand practices, but I want to go a step further to focus on process execution. In fact, what a coach does is to help teams execute, execute better, execute faster, and execution is more about progressing things through their states. Hence my cards emphasizes work target states and their completion criteria and so they are called state-cards. You can use the state-cards for all three time scale levels I described at the beginning of this paper. You can use the cards to design your development value stream which I will also describe in this paper.

3. Dynamic Application Lifecycle Management with State-Cards

Most organizations have what is known as a lifecycle model, a designation of certain sets of criteria to meet some milestone objectives. It is useful to break down the milestone objectives into various aspects of development since they require different skill sets. As an example, the Rational Unified Process (RUP) decomposes an application lifecycle into requirements, analysis and design, implementation, test, configuration management, project management and environment. EssWork (and same with my cards) goes a step further by associating states with lifecycle objective milestones.

The problem with milestones is once a date is set for the milestone, activities beyond the milestone need to wait for the milestone to be achieved. This poses considerable waste, especially when the milestones are defined a priori before the project starts. Every project is different and need an adjustment to the lifecycle objective milestone definitions. This is best done dynamically and I will describe how this is achieved using state-cards.

I normally do this during my first contact with project teams as a way to understand their state of development. I evaluate the development state by considering 4 different aspects or dimensions of development, namely: Vision, System, Project and Team.

• Vision. This is the business and value aspect. The vision communicates the value, the rationale and the benefits derived by developing the product (system-software). All systems are developed to achieve some vision. It answers the questions “why” and “where.”
• System. This is the technical aspect. The system embodies the things to be delivered to fulfil the vision. They including software, hardware, documentation, etc. It answers the questions “what” and “how much.”
• Project. This is the work management aspect. It embodies the work to