Let’s look at the simplest example of visual application in a team.
Although the scale of some projects is not large, there are many places for integration. I once experienced a project that often required other teams to collaborate on problem investigation and integration test. When another team was in the US, we were not sure who could help us that day. So sometimes e-mails and messages will not get a reply for a long time, because the person we are looking for took the day off. Such a simple little thing will haunt us from time to time.
How did we finally solve it? We started asking everyone to record their leave on Wiki in text, which did solve the problem of missing leave information between teams, avoiding the sudden discovery of someone’s absence one day. Although the information is there, it is in the form of text, which needs to be read carefully to understand it accurately, and it is very easy to misunderstand. Later, we felt that it was very unintuitive to record on Wiki as a list, and we implemented a visual leave form for the team, also known as the team calendar.
Compare the content shown in Figures 4.6 and 4.7.
From Figure 4.6, we cannot immediately know' how many man-days will be missing in the next iteration. First, iterations are calculated in w'eeks. We don’t know how much productivity will be reduced each w'eek. Secondly, we don’t know how' much weekend time is included in the leave period. When valuable information cannot be displayed visually, laziness will make us ignore this information, and Figure 4.7 is much clearer.
Ideally, the mail system we use can manage leave well. For example, when we set a vacation in Google Calendar, others can check the free time and busy time of participants when sending meeting invitation e-mails. This makes it easy to find a time period w'hen all stakeholders are free.
Showing Project Status: Kanban
Kanban, as a proper noun, refers to a bulletin board that can be seen by everyone on the production line and demonstrates the status of the production line. People use it to reduce the number of WIPs, shorten their production cycle on the assembly line, find bottlenecks on the production line, and then continuously improve the processes on the production line. If expanding into the field of software development, people can call Kanban an iterative state wall or task board. The purpose of using Kanban is also similar. Kanban is concerned with the delivery process of the team w'ithin an iterative range. In the Scrum mode, this process is an sprint. In this process. Kanban helps us track the status of each split story card, tells us that the team has a bottleneck in a certain period of time, gives a signal that the story card is ready to be pulled, and encourages the team to work towards a goal (the goal is in an iteration cycle, all the story cards planned to be delivered are moved to the online state).
In general, a simple Kanban is like the one shown in Figure 4.8. Its purpose is to clearly tell the user the status of each task.
FIGURE 4.6 Text leave record.
FIGURE 4.7 Calendar leave record.
FIGURE 4.8 The simplest Kanban.
In the field of software development, the Kanban we use is usually shown in Figure 4.9: There are more swim lanes on the wall. When a lot of story cards are piled up in the development swim lanes, QA is often in an idle state, and we can know where the current team’s bottleneck is. When a story card moves to the "To do...” state, it means that it can be pulled into the following process. So, Kanban is a visual workflow that records the “liquidity” of all tasks.
Let’s first create a typical Kanban wall.
According to the typical development activities of the team within an iteration, it is divided into several sw'imlanes, such as “to be developed,” “being developed,” “to be tested,” “being tested,” “test completed,” etc. At the beginning of the iteration, we will put the story cards planned to be completed in this iteration into the “to be developed” column. When the developer receives the task, he moves the story card he received from “to be developed” to “being developed,” and pastes a small
FIGURE 4.9 Common swimlane in Kanban.
note with his name. When he has finished the development, he moves the story card to the “to be tested” column. When testers see that there is a story card to be tested in this column, they will take one and move it to “being test” to start the test of this user story. After the test is completed, move the story card to the “test completed” column. If the tester discovers a dug. he can use a red card to write down the bug and put it in the “to be developed” column. On the status wall, in addition to user stories and bugs, there will be some tasks that do not directly generate business value, such as refactoring or setting up a test environment. These three types of tasks are recorded with a card different from the color of the story card and placed on the status wall for unified management.
In this way, our Kanban wall can be used. At the beginning, we can think of the above scenarios, so that we can take the first step as soon as possible. Only by using it as soon as possible, we can find problems in use, and then continuously improve the Kanban wall to make it better serve the team.
When the tester found a bug, we created a red bug card and put it in the “to be developed” column. But how can we deal with the story cards still being tested? We can continue to test the remaining scenarios, if there are other bugs, we will keep creating a red bug card. Finally, we will find that story cards with unrepaired bugs do not belong to any swimlane of the current Kanban wall. We can draw an area in the lower part of the “being tested” column to temporarily store this type of card. After all the bugs are fixed, the tester needs to test the story card again.
The Kanban will be used like this day after day, the team will continue to improve the Kanban wall to make it more adapt to the team’s usage habits. As long as we always follow its core philosophy, that is, let all team members know the plan and progress of this iteration in real time, under this premise, the team can freely develop its creativity.
Any team can build an iterative status wall, use it to reflect the progress of a certain iteration plan and tasks, and can design their own Kanban wall based on their own situation. Although I have seen many unique Kanban walls, the basic attributes are the same, and the adjustments are made according to the customers’ concerns or the characteristics of the cooperative offshore team. For example, some customers are concerned about the speed of delivery, we must simplify the process as much as possible (that is, the number of swimlanes is as small as possible), the minimum swimlanes are shown in Figure 4.8. If customers have strict quality requirements, we will add more stringent links to promote quality built-in, such as brainstorming before development, desk check after development, automated test acceptance, and performance index review. For teams that are simultaneously transiting to agile development in the delivery process, they shall add a link for agile practice verification, such as user story-level code review.
We can feel the simplicity and ease of use of Kanban Wall, but there are also many doubts that the team has experienced.
Doubt 1: Many Kanbans start with “to be developed,” and the state of the requirements before this stage does not seem to receive much attention. Usually, it is the stage of business analysis before development is ready, including “backlog” and "in analysis.” What is the value of these two states on the Kanban wall to the team? Is it the project manager who cares about such things as backlog? Do developers and testers need to pay attention? To answer these questions, we first need to declare that the requirements are not the analysts’ own business, but the participation of all the team. If there is interaction with a third party, the relevant personnel of the third-party team also need to review our requirements. Therefore, to improve requirements from the perspective of different people has a positive meaning for the correct delivery of requirements. For a self-managed team, we can’t wait for the required function to be handed over to us to consider it, but to review its impact on later stages when it is just ready.
Developers can help business analysts from a technical perspective. Choose a reasonable plan to reduce the cost of development or avoid the weakening of software stability. Testers can improve the requirements from the happy path and sad path to reduce the lack of requirements. But what is the value to another distributed team? Understand the plan of the cooperative team, could improve the level of collaboration, reduce waiting and mis- judgment in collaboration, and thus reduce waste.
Therefore, the deep problem reflected by the importance of each team on the requirements stage of the Kanban wall is when the team starts to pay attention to the requirements and how much attention is paid. The business analysts of each team will analyze the story card or more of the next iteration plan in advance to ensure that each team has enough work to do. Before the new iteration begins, these cards are prepared according to priority, and demanding developers and testers can go to the online electronic wall system to learn about these story cards in advance.
Doubt 2: Notice the status of block in Kanban. If our work is hindered by the work of another team, then we need to enable them to see the block in real time. Motivate this team to give us their status every day, that is, let them realize clearly that we have a job depending on them. Give them clear information so that this work has an accurate priority in their team. After all, they have priority settings that are considered for their own team.
Doubt 3: How can such a simple tool help us eliminate waste and solve problems in project management? With it, the team has a common goal and a common compliance process. Every time the flow of story cards is a signal of the completion of a job or the start of a new- job, it is like an invisible hand guiding the team forward. Statistics such as Cycle Time and the quantity of WIPs are available on Kanban, and these data can also improve our current work, such as reducing the “inventory” function.
Doubt 4: The help of the iterative status wall to the team is that it serves as a tool for visualizing the workflow, telling us all the WIP story cards intuitively. The iterative status wall does not guarantee that the story card to go online as soon as possible, it can only supervise, remind, and highlight problems. So w-hich practices have played a role in reducing WIP and WIP life cycle?
Doubt 5: Do distributed teams still need to maintain their own physical Kanban wall? Regarding intuitiveness, no tool is comparable to the physical wall. We build this physical wall in the simplest way, first of all, find a w-hite wall that the team members can see w'hen they look up or find a whiteboard, the tools needed are also simple, including plasticine, cards or sticky notes, and whiteboard pens.
This subsection shows the use process of the basic physical Kanban wall. If it is a distributed team, this process will be slightly different. In distributed teams, we must first maintain an electronic
Kanban wall, which needs to be synchronized with the physical Kanban wall of each team in real time. The work of synchronization seems small, but if we do not update the electronic Kanban wall in time, the remote team can only read our outdated status information every day, especially when standing at the meeting, they will feel confused and unhappy. Furthermore, the Kanban wall of distributed teams can add some integrated status bars or status bars that are mutually reviewed.