It is a well known fact that all applications are different; all application development teams are different. So, why should we expect application lifecycle management to be fixed? There is no such thing as “one size fits all.” Yet, it is also common sense that there must be something in common, as otherwise there is absolutely no way to learn from experience and mistakes. The challenge is then to find a middle ground that is easy to communicate to the development team and stakeholders. In this paper, I present a pragmatic and novel approach using a deck of A8 (5 1/4" x 7 7/8") sized state-cards that is small enough to fit into your pocket. I will demonstrate how you can use the state-cards to understand the state of application development, how to define your lifecycle model; you can use it to define your value streams. It is important to get your team to define and own their application development process and state-cards provide the building blocks to do so.
1. The Application Lifecycle Management Challenge
Before I describe the deck of cards, I’d like to set the stage for using the cards. We can view application development from three time-scales (see Figure 1). Successful application lifecycle management is in essence being able to coordinate the three time-scales effectively.
- The broadest time scale covers from the beginning to the end of an application development lifecycle which is marked by several key business decision making milestones. This is of great interest to stakeholders and decision makers on whether development can proceed or whether the application is suitable for release.
- The next time scale breaks the lifecycle into time-periods – months, or weeks, or what is known as an iteration. It is a fixed time-box where a number of target objectives are to be met by a development team. If there are multiple teams, then each team would be assigned their specific set of objectives. This is where team leaders operate.
- At the lowest time scale is what a team member does. The work done here can be in terms of hours or days depending on the complexity of the work.
Figure 1: The Three Perspectives to Application Development.
A major problem I see in many development organizations is serious disconnect between the three levels. The objectives set at the higher level do not easily translate to work at lower levels. Lower levels are unable to see their contribution to higher level objectives. There are miscommunications between the levels, and poor coordination within the same level, which leads to blockages which rightfully should not even happen. We need to solve this.
2. A Solution through a Deck of Cards
What is the solution? I can describe a solution. But I want to do more. I want to devise a way by which a plausible solution can be quickly and readily configured to your specific application development context. I achieve this with a deck of A8 cards. Just for your info, A8 is A4 paper folded four times – i.e. 16 cards on an A4 sheet of paper. So, what you can have is the entire application lifecycle management process described and printed on something smaller than your mouse, or mobile phone (see Figure 2).
Figure 2: Deck of Cards for Adaptive Application Lifecycle Management
This is a really powerful visual queue, as I usually dangle and shake the cards in front of application development teams and say, “This is the process.” Many are amazed because they are often used to having processes described in thick books, manuals and web-pages, which nobody reads, and here I am with something so small.
Each card has the same structure as shown in Figure 3. At the top is the name of a work target. A work target is something to be achieved. It could be building a feature or a system, an improved process, and so on. The achievement of a work target goes through a certain number of states. The cards I have here have 5 states per work target to provide some kind of regularity. Each card has a name for the work target together with some criteria for achieving the work target state. At the bottom of the card is the state number over the total number of states, i.e. 5. The state number helps users to remember the order of the states.
Figure 3: Anatomy of a Card
The idea of using cards is not really new. Applying states to work targets is not new either. Cards have been implemented in many task tracking tools, such as ClearQuest,
About the author
The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.
