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,