Arguably, a software development team should not have a value stream (VS). This is because VS is a manufacturing tool and tends to be suitable for liner deterministic process which is not the case for Edge-of-Chaos nature of software development.
In my view, a software development team is in need for VS which is visualized and preferably as manual board. Part of this because of my methodological mind-set, I admit. However, if I abstract myself little bit and recall what happens in product development organizations, there is still many benefits for the VS approach. These benefits are summarized below.
Appreciate and acknowledge various skills
Agile methods suggest that the team is self-organized and collaborate to complete the commitments. This is true, but does not consider some human aspects of skills ability. Let’s assume we have a team of 5 members and the typical tasks originated from the backlog can be grouped into 10 different skills. For example, Java, advanced middle-ware, Java script, utility builder, server integration, functional testing, code review, and so on. The following table describes skills of every member.
The previous table suggests that whatever collaboration and self-organization the team might do, there are always tasks which only certain members can do. Of course team members can learn new skills, however, in the continuous flow of demand members can improve their current specific skills rather learn new technology.
When the VS is drawn, each stage would require certain skills which we can associate specific team members with it. This insight is visualized and provides a common understanding of why some tasks can be waiting. By adding the WIP limit to every stage based on understanding of skills; this can regulate the incoming work from up-stream to the capacity of the stage.
In all projects I worked on, including new product development, dependencies were at best cause of pain. The VS provides a visual understanding of the end-to-end delivery cycle which includes stakeholders outside of the team. This approach serves to align the team with the organization. The team changes the organization and the organization can impact the team. This interaction creates more meaningful products.
Visualize, Visualize and Visualize
In process management, we cannot tell the team what process to use. Also, if the team is already producing software then, it means that the team has already a process. The process is something we uncover instead of pre-determining. For me, it’s like self-discovery of the person to see where she fits. Using this analogy, it takes trials before the team can figure what works for it. Visualization of the VS allows continuous self-reflection by the team and therefore helps its members to collaborate.
Add intentional over-head on other groups
A product manager complained to me that in-addition to electronic ticketing system, she has to create cards, prioritize, and follow-up with the developers. She also should follow certain policies while moving the cards. This overhead takes about 20 minutes daily from her time and she had to walk long way from her desk to where the team is located. All of these added actions on here for me are required aspects of the product owner role to improve hand-offs and to better interact with the team. In other words, this over-head is in-fact was a missing valued activities that the visualized VS served to introduce.
1. I don’t think that the process definition as used in other service industries is compatible with software.
2. The team should uncover their own process, which is best done through visualizing its VS.
3. Having a manual board for the VS represents the essence of collaboration needed for agile teams.
4. Overheads added by the visualization board are in fact desired value-add activities.
5. VS visualization is compatible with software development teams.