A Highly Evolved Card Wall
I’ve been promising Mark Levison since forever to describe the highly effective card wall that evolved at one of my past clients. The team started with a simple beginning, and modified it as they saw fit to suit the needs of their situation. This is not a universal model for others to blindly copy, but there is much to learn from it.
No doubt that it continued to evolve beyond my knowledge, as this team spectacularly took control of their own development process. I’ll never forget the Monday morning that I walked into the team room, direct from the airport, and saw them pulling cards and tape off the corkboard wall. “What the heck are they doing?” I thought. I stood and watched from across the room as the scurried around excitedly with much conversation. Tape and cards started to go back on the wall in a different configuration. I knew then that this team was going to excel, as they were paying attention to how things were working for them and adjusting accordingly. Excel they did, and their wall was in frequent flux as long as I knew them. It’s amazing what a team can do when they have the desire and freedom to improve.
New ideas on the horizon
This was an IT team, and the functionality they were to build was handed down to them from executives of various departments of the business. The team included a sub-team of analysts to receive and make sense of these requests. As they came in, the names of these requests were recorded on index cards, and pinned up in the left-hand side of the wall. This area came to be known as the Nursery. These represented work that was desired by someone, but hadn’t yet been started. Seeing them on the wall kept them visible during conversations, though. Sometimes those conversations resulted in something else happening, and a card being removed.
To the right of the Nursery was a section called Pre-School. It was here that the analysts kept track of their work as they interviewed various people in the business to turn vague requests into distinct understanding of specific needs. In a typical organization beyond a certain size, this can be a lot of work that takes considerable time, especially with the usual communication delays.
This part of the wall was frequently reorganized according to their current needs and the way they thought about the work. It had started out as a timeline, with items organized by the specific iteration in which it was envisioned to be developed by the programmers. It was this version that I had seen being dismantled. They had found it too difficult to maintain this as new information was discovered, uncertainties were unearthed, and business sponsors juggled priorities. Sometimes there was a sense of progress in the analysis proceeding from left to right. Sometimes there were just groupings, when it was hard to discern how far things had progressed. Often there were swimlanes to separate different features requested by different parts of the business.
Sometimes there was a feature for which a clumps of cards had been generated representing the analysis work, but had run into a snag of some sort. Perhaps the business was unable to make a decision on what precisely they wanted. Perhaps priorities had shifted further up the chain from where the request had been generated. Perhaps the business had just changed their mind about the idea. When this happened, the cards might sit there for awhile, but if the space was needed or reviving that idea seemed remote, the analysis cards were often stacked up and binder-clipped behind the title card and pinned up under the Nursery section. This got them out of the way, be easily accessible if the business desire came back.
What’s described here is for IT work for in-organization “customers.” I’ve seen similar representations for product focused research on what external customers actually want and what will give the company a competitive advantage. The questions asked and the details of representation are different, of course. The important part is that, whether business analysis or product research, the people doing that work can organize tracking what they learn in the best way they can according to what makes sense to them.
Final Prep for Development
As high priority user stories were identified and nearly complete with analysis, they were moved to the right into the Elementary School column. This gave everyone a view of what might soon be implemented. And to the right of that were two columns, Junior High, and High School, representing what was expected to be included in the next couple development iterations.
In all three of these columns, if there was something blocking progress on a story, then a “Bridge Out” icon was paper-clipped to the story card. This gave a very visible indication that there was something pretty urgent to straighten out. This might be something like a dependency on another project that had signaled their delivery date was likely to slip. As there were many services being developed waterfall fashion within the company, this was not an uncommon occurrence. If the holdup was due to insufficient information from the business, then the story, and other stories associated with it, were at risk of being postponed.
For the stories sitting in High School, there was one more step before they were ready for development. That step was a meeting of the Three Amigos—an analyst, a programmer, and a tester—who looked at the story and made sure they had a complete, and consistent understanding of what the story involved. The analyst presented what they had learned from the business. The programmer looked at it with an eye of what was feasible given the state of the system. The tester brought up edge cases and potential errors to make sure they would be handled appropriately. Sometimes there was a fourth Amigo—the UX expert—to make sure that the chosen solution would be clear and easy for users.
When they were satisfied that the story was understood and ready for development, they marked the story card with a colored dot. Only stories with that colored dot were eligible to be brought into the next iteration.
Current Iteration Kanban Board
Finally we reach the kanban board that Scrum teams every know and love—the current iteration. This had perhaps more columns than strictly necessary—ready for development, in development, ready for testing, in testing, ready for approval, approved—but the buffer columns didn’t hurt anything and sometimes made handoffs a little easier. The approval process was a review by the Product Owner, the highest proxy on the team for the Business. This board was called College, because when a story was finished going through College, it was Working.
Tell me about your favorite tool to visualize and enable the progress of work.