Architecture Walls

Visual Planning, or putting things on walls (per my previous post) is to me one of the most important aspects of becoming a high performing team. However the information that you put on the walls does not have to be a “plan”. Most teams on their agility journeys start with putting their Kanban board or planning wall up. To me walls are an amazing source of information and a way to externalise thinking. Other types of walls are powerful for teams to develop.

Architecture Walls

Architecture walls are very different yet strangely similar to planning walls. They cover different material and focus on different information, but they can be used in the “macro” to discuss and document the end to end architecture of the solution and the “micro” to drill down into some specifics for the current stories or work units being delivered.

To start an architecture wall is very simple. It generally starts on a whiteboard during a conversation when people start to map out how the system or application, or any topic under discussion, fits together. Architecture walls tend to start with very simple diagrams that consist of basic boxes and arrows that share information about entities and relationships.

As the information shared gets more complex, more mature, or needs to be more persistent, then the diagrams can get richer in content, and they may become more highly detailed and more formally drawn.

My favourite approach is to have the overall project architecture wall updated with details during the iteration as the questions are asked and answered, and then have an allocated section of the architecture wall for standards, and then another section for questions and discussion sessions.

As the information is populated to the wall there can be full group discussions on relationships, dependencies, testability and environments for the development and management of all of the artefacts required for the development and delivery of the solution. Any changes to something on the wall can be quickly done, and then published (because it is done in public everyone can see!) and the whole team gets to see, question and understand any changes and the ramifications of any changes. Team can also overlay their work cards on the architecture or screen or context diagrams to see if they have any gaps or are over delivering.

Ideally the architecture walls are very closely located to the team doing the work. It should become the wiki or “go-to” reference for the team and there should be (ideally) a whiteboard very close by so details can be discussed and thrashed out but the team with reference to the entire solution. To keep regular records of the changes to the architecture wall, taking photos with a digital camera or smart phone allows changes to be made and version control to be managed.