{"id":789,"date":"2014-07-01T20:02:02","date_gmt":"2014-07-01T20:02:02","guid":{"rendered":"https:\/\/caroli.org\/en\/?p=789"},"modified":"2020-09-19T12:24:14","modified_gmt":"2020-09-19T11:24:14","slug":"the-card-wall","status":"publish","type":"post","link":"https:\/\/caroli.org\/en\/the-card-wall\/","title":{"rendered":"The Card Wall"},"content":{"rendered":"

Card walls help to level the flow and maximize the throughput for software delivery. <\/span>Many books have covered Agile, and several of its principles, practices, and tools, but none have taken a deep look at card walls and the principles behind them.<\/span><\/p>\n

In Stand Back and Deliver<\/a>, the authors– Pollyanna Pixton, Niel Nickolaisen, Todd Little, and Kent McDonald (senior leaders experienced in several industries and organizations)\u2014make the following statement: <\/span><\/div>\n
<\/div>\n
\n
\u201cThrough our experiences and sharing stories, we<\/span> found that a collection of tools apply to how organizations approach their work, especially work that involves change and innovation; when used in moderation and in conjunction with each other, these tools can have a dramatic impact on the success of the organization\u201d<\/span><\/div>\n<\/blockquote>\n
<\/div>\n
\n

Software development is all about change and innovation. And organizations that successfully apply Agile to software development shortly find themselves using a collection of tools that support Agile. To name a few: Continuous Integration server, automated tests, automated scripts, IDEs with refactoring capabilities, and the card wall (physical and\/or virtual).<\/span>Below are a few photos of physical card wall:<\/span><\/p>\n

<\/div>\n
\"\"<\/a><\/div>\n
\"\"<\/a><\/div>\n
\"\"<\/a><\/div>\n
<\/div>\n
<\/div>\n
<\/div>\n

 <\/p>\n

Why use a card wall?<\/h2>\n

 <\/p>\n

<\/div>\n
<\/div>\n
<\/div>\n
Why use a card wall? Teams that don\u2019t know exactly why they are using a card wall will not benefit from it. If your team is not clear on the value that a card wall provides, either (1) Agile is not suitable for them, (2) they must read this post, or (3) the team has less than three members. The biggest single reason for using the card wall is that it brings the Agile team together. The card wall improves team communication, information sharing, impediment removal and decision-making.I have interviewed many Agile teams about the card wall with the following question: What does the card wall provide you with? Below are the answers given by: developers, testers, analysts, product owners, managers, directors, project sponsors, and scrum masters.<\/div>\n
<\/div>\n

 <\/p>\n

Question: What does the card wall provide you with?<\/em><\/div>\n
<\/div>\n

 <\/p>\n

\n

Answers:<\/p>\n

\u2022 The goal for the team in that iteration, or at that moment.<\/em>
\n\u2022 It tells me what the team is working on.<\/em>
\n\u2022 It tells me who is working on what.<\/em>
\n\u2022 It shows the bottlenecks.<\/em>
\n\u2022 It depicts the Scrum swim lanes.<\/em>
\n\u2022 It makes visible any team decision.<\/em>
\n\u2022 It helps to run the daily scrum.<\/em>
\n\u2022 It makes clear when we are not pairing.<\/em>
\n\u2022 If you look at it every day you know how fast the team is moving the work.<\/em>
\n\u2022 It tells me what everyone is working on.<\/em>
\n\u2022 It shows me what kind of Agile flavor the team is using.<\/em>
\n\u2022 I can see the tasks for a story.<\/em>
\n\u2022 A snapshot of the team work.<\/em>
\n\u2022 It tells me the kind of work that the team is doing.<\/em>
\n\u2022 It makes the workflow visible.<\/em>
\n\u2022 It depicts WIP (Work In Progress) limits used by the team.<\/em><\/p>\n

In 2009, Mike Cohn wrote an interesting blog saying that Agile is all about micromanagement.He explains that almost every principle and practice of Agile is there to support micromanagement. From his blog:<\/p>\n

\u201cThe daily scrum is about micro-managing the team\u2019s daily work plans and making sure that everyone is doing what they say they\u2019ll do.
\n– Continuous integration is put in place so that the minute some developer screws up and breaks a build, it becomes known.
\n– Pair programming is about making sure that programmers don\u2019t lose focus, don\u2019t goldplate, don\u2019t work only on the fun requirements, and that they clean things up.
\nAh, but who is it that is doing this micromanagement?
\nIt\u2019s the team.
\nYes, agile is about micromanagement, but it\u2019s about the team micromanaging themselves and for their own benefit.\u201c (from https:\/\/www.mountaingoatsoftware.com\/blog\/)<\/p><\/blockquote>\n

I agree with him. Agile is all about team collaboration, responsibility sharing, clear communications, and self-management. And yes, it feels like micromanaging. In other words the team structure and work activities are visible at the wall; therefore, everyone can easily collaborate and know what everyone else is doing. The card wall is, perhaps, essential for successfully implementing \u201cmicro-management\u201d\u2014Agile style.<\/p>\n

 <\/p>\n

The workflow on the wall<\/h2>\n

In software development, typically a small requirement will take from hours to days to complete. Also, you cannot see how many requirements are currently in analysis; or how many requirements are currently being coded or tested. As a matter of fact, it is not easy to \u201csee\u201d the work as it is moving along the work stages. Here is where the magic happens: the card wall makes things more visible!<\/p>\n

The basic idea of the card wall is to have the workflow on the wall itself. Below is a photo taken of an Agile team card wall.<\/p>\n

\"an<\/a>

the workflow on the wall<\/p><\/div>\n

Cards attached to the wall. This is the card wall. A quick description of the card wall snapshot in this figure would be: one card is at the In Analysis stage, five cards are at the Ready for Dev stage, three cards card are at the In Dev stage, another card is at the Ready for BA acceptance stage, three cards are at the Ready for QA stage, five cards are at the In QA stage, and eight cards are at the Ready for SAT stage. Also it looks like the team uses photos to represent people working on the cards. The cards have color coding (there are three different card colors in this photo); the cards also have various notes on them, a numeric identifier, and stickies attached to them.<\/p>\n

As the wall is a two dimensional surface, the card wall is presented in a tabular format, where the work stages are the columns, and the work cards, people cards, and other work related marks fill up the space in the wall. These cards might be organized in a row or not. It all depends on the team and how they represent and organize their work in the wall.<\/p>\n

The card wall can be viewed as a communication tool for rapidly acquiring and disseminating knowledge among members of a workflow team. The main goal is to give all team members a shared view of the current workflow process status. To this end, the card wall has visual representations for work stages, people, work, and work related attributes such as size, complexity, order, groups, priority, limit, and feedback.<\/p>\n

The card wall helps scheduling and planning readjustment. By looking at the wall you know which stage a card is in. This simple visual inspection enables you to identify early enough any cards deviating from plan, and do something about it.<\/p>\n

Like this topic? You should read more about Kanban<\/a> and the Cumulative Flow Diagram<\/a>.<\/b><\/p>\n

 <\/p>\n<\/div>\n<\/div>\n\n\n\n
<\/td>\n<\/td>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n","protected":false},"excerpt":{"rendered":"

Card walls help to level the flow and maximize the throughput for software delivery. Many books have covered Agile, and several of its principles, practices, and tools, but none have taken a deep look at card walls and the principles behind them. In Stand Back and Deliver, the authors– Pollyanna Pixton, Niel Nickolaisen, Todd Little, […]<\/p>\n","protected":false},"author":1,"featured_media":782,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[1919,2114],"tags":[714,704,682,718],"inception_activities":[],"colaboradores":[],"class_list":["post-789","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-agile-culture","category-kanban-en","tag-article-en","tag-card-wall-en","tag-definition-en","tag-workflow-en"],"_links":{"self":[{"href":"https:\/\/caroli.org\/en\/wp-json\/wp\/v2\/posts\/789","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/caroli.org\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/caroli.org\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/caroli.org\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/caroli.org\/en\/wp-json\/wp\/v2\/comments?post=789"}],"version-history":[{"count":0,"href":"https:\/\/caroli.org\/en\/wp-json\/wp\/v2\/posts\/789\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/caroli.org\/en\/wp-json\/wp\/v2\/media\/782"}],"wp:attachment":[{"href":"https:\/\/caroli.org\/en\/wp-json\/wp\/v2\/media?parent=789"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/caroli.org\/en\/wp-json\/wp\/v2\/categories?post=789"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/caroli.org\/en\/wp-json\/wp\/v2\/tags?post=789"},{"taxonomy":"inception_activities","embeddable":true,"href":"https:\/\/caroli.org\/en\/wp-json\/wp\/v2\/inception_activities?post=789"},{"taxonomy":"colaboradores","embeddable":true,"href":"https:\/\/caroli.org\/en\/wp-json\/wp\/v2\/colaboradores?post=789"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}