Lightweight Application Lifecycle Management Using State-Cards


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 Published by ETH Zurich, Chair of Software Engineering ©JOT, 2007. Vol. 6, No. 6, July-August 2007

[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.

About the author

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!