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.
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, 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 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 [2] 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 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. 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.
Figure 10 shows another team organization with architecture decision value stream factored in. Here we have one fulltime person exploring solutions and the other designing the solution into the system. Since they are one person jobs, it makes sense to combine the states. This is shown by having the states stacked on top of one another.
Figure 10: Organizing Work with Feature and Architecture Value Stream
Again, it is important that team members themselves define the process and work allocation. It is very difficult to have an organization defined a priori. The team knows best their skills and competencies. In addition, defining the work allocation themselves gives them a sense of ownership. Ultimately, it is their process. The state-cards provide building blocks to do so.
I have applied this approach to an organization that conducts offshore development. Both the organization and their offshore partner had some introduction to the state-cards and they jointly separated their responsibilities using the state-cards as above. They were also aware that as the offshore partner gained better understanding of the system to be developed, they could be granted more responsibilities. So, it was agreed that they design their work allocation at every contract period of about two to three months. The entire project was much longer.
6. Applying State-cards in Application Lifecycle Management
The idea of state-cards is really quite simple. It does not attempt to solve analysis or design problems. It does not change the system architecture. It is just a way to understand how work is done and how work can be tracked and improved. It is really a low hanging fruit to improve your way of working quickly.
Applying the cards is also easy. For teams that are new to lean and iterative development, the cards are used out-of-the-box. The cards are applied at all three time scales discussed at the beginning of this paper:
- You can define lifecycle milestone objectives using the Vision, System, Project and Team cards. Vision and System can normally be refined into Feature and Architecture Decisions work targets.
- You manage iteration execution with the state-cards as a value stream. State-cards provide building blocks to design your value stream.
- You allocate and manage work by each state-card.
Note that all these are conducted using the same building blocks of state-cards. This encourages a common understanding between persons whose interests are directed at different levels and timescales. The state-cards provide a common language.
Teaching teams to use the cards is also very easy. First I hand out the cards to the team and then I walk through the way to use the cards as described in this paper. Really, that’s it. Of course, if the team is new to iterative and lean development, I would need more time to explain the concepts like time-boxing, continuous flow, reducing wastes, etc. but the basic idea of state-cards is simple. I also supplement with some simulation exercises to reinforce the ideas.
Creating the cards is simple. I use MS-Power-Point and set the page to portrait A4 and craft the state-cards. Then I print them at 16 cards per page at a local printer who cuts them nicely for me. No special software is required.
I encourage you and your team to try the idea of state-cards for yourselves.
7. References
[1] Ivar Jacobson, Pan Wei Ng and Ian Spence, Enough of Processes - Lets do Practices in JOURNAL OF OBJECT TECHNOLOGY, Online at http://www.jot.fm. Published by ETH Zurich, Chair of Software Engineering ©JOT, 2007. Vol. 6, No. 6, July-August 2007
http://www.jot.fm/issues/issue_2007_07/column5/
[2] SEMAT: Software Engineering Method and Theory
About the Authors
Pan-Wei Ng, Ph.D. is a firm believer in a lean and agile development. He strives to improve quality and reduce waste. Dr Ng helps companies in Asia adopt and scale lean and iterative development and other practices. He believes in practicality and leadership by example. In fact, he has recently lost 20 kg in 3 months as a result of applying a lean lifestyle. As the Asia Pacific CTO of Ivar Jacobson International, he contributes to the innovation of software engineering practices. He co-authored of Aspect Oriented Software Development with Use Cases with Dr Ivar Jacobson and believes that aspects and effective separation of concerns are important enablers to rapid lead and agile development.
Mark Magee has been tinkering with various software development methods for over 20 years in a variety of organizations in Japan and the US. Having been born and raised as a foreigner living in Japan, he has a natural tendency to take an objective view of everything, including himself, standing on the outside looking in. This "out-of-the-box" mentality combined with an insatiable appetite for solving puzzles has lead to many unconventional suggestions that continue to surprise and dismay his colleagues at Sony. Current interests include a combination of risk management, lean and agile methods, agile inspection, organizational improvement, effective training delivery, and doughnuts.
