Agile Wall Overview

In the agile World, Bvcs, tows and POWs are all very important tools. So what are they? Bvcs (Big Visible charts) refers to a large visualization chart, tows represents a wall display (displaying items on the wall, things on Walls), while POWs (Plain old whiteboards) means a simple and ancient whiteboard- They all belong to different types of information emitters. Further, why do these tools have a very valuable value? Because in an ideal situation, everyone can see, study and understand them. By magnifying and visualizing all sorts of things, we will enable the entire team to reach this information, and not confine it to some specific team members.

The display of this information on the wall means that we will make it public in order to get feedback from the entire team. To be as "wasteful" as possible in your work, we need to make this information lightweight, accessible, and less technical, so that everyone can see and change indefinitely. In this context, POW is an ideal tool, and everyone on the team should be able to use it or update it as needed.

When we talk about it-putting the things the team needs into open, accessible areas-it doesn't sound complicated. We'll be prepared enough to help people understand the information and eliminate the Visio diagrams that don't really look good, to avoid waste. At the same time, we need to keep the information open so that we can focus on comments, updates and key indicators to provide good and open transparency. We should make sure that everyone in the team has access to all the information from start to finish, because it is very helpful in nurturing the understanding of communication, collaboration and sharing throughout the team. In addition, we can convey a lot of information very quickly and efficiently by using flip charts, labels, cards, convenience stickers and hand-drawn graphics. We are also able to capture and record history, trends, past decisions, and work progress or changes within the team.

What type of information is displayed? What type of wall do you choose? Who is responsible for managing them? Who's going to update them? In practical work, there are many different ways and information to deal with these problems, so the author's answer is "as appropriate". But this article will introduce some of the very good ideas, some standard walls, and some wonderful, creative walls that the author has seen, heard or thought about.

Planning Wall

The planning wall is responsible for presenting planning information about work, teams, and products. This information may be something like a release plan, a product roadmap or an iteration plan, or even a story wall. Ideally, the planning wall should be placed where each member of the team is able to see and update it.

Figure 1-Initial release plan

Release plan--This kind of wall contains a to-do list on the job, and the right side is the iteration that breaks down the planned workflow based on speed or team structure. The to-do list contains the work that is planned from the initial stage of the project to complete the project. Speed refers to the estimated ability to work in a team. Based on risk, dependency, size, and team capabilities, we distribute work units or stories to work fragments of each iteration and strictly control time. In this way, the planning wall is able to present a holistic view of the overall work, an understanding of dependencies and team work capabilities, and a clear description of the duration of the project. The team should be responsible for building the planning wall and updating it based on the progress of work during each iteration, as well as the backlog of to-do lists or ongoing work.

Figure 2-Dynamic (updated) Release schedule

When an iteration is finished, additional work can be captured and added to the plan, such as a defect (red) or a change (green). After all the bugs and changes have been added, the list of agents will show the work that cannot be done within the planned time, or the additional work that has been identified. This will help the team to see clearly what needs to be done next and when they will be completed. If you have more than one team in your project, you can split the release plan by team and by the level of work assigned by each team to match the team resources, skill configuration, and ability to work.

Figure 3-Multi-team release plan