The Daily Design Workshop

If prompted right now, could you explain the design of the software that you’re working on, and the change that you’re making to it? What about the other members of your team? For our team, the answer was no, and a debate over the cause of that failure ultimately led us to implementing daily design workshops which have not only solved the problem, but produced several other unintended benefits.

“What is the cause?” we immediately debated as it became clear that the team couldn’t explain what they were actively doing, even what they had been doing over the course of a week. I argued that there was a failure of commination skills rather than a failure in understanding. The code changes themselves were generally correct, and consistent with the design agreed upon during sprint planning. Others argued that truly understand an idea is synonymous with being able to communicate that idea, a belief I find troublesome after years of studying language. Code itself is a form of communication, but in a collaborative environment it can be difficult to parse out who understands what from the software alone.  Each team member must be able to articulate their understanding.

And so, with one party concerned that the team did not understand the software that they were building, and myself concerned that the team lacked the communication skills to adequately convey their knowledge, we decided upon a strategy to address both concerns.

Each morning, after our daily standup, one team member is tasks with explaining the design for the story at a whiteboard, or for the test automation for that story. The rest of the team is responsible for asking questions until any ambiguities are resolved, and a mutual understanding is achieved. The exercise usually takes about fifteen minutes.

In this way, each team member gains practice discussing and diagraming software design. They’re improving their communication skills through practice, and by observing the techniques of other team members.

We are also ensuring a mutual understanding of the software design with daily discussion and reinforcement of that design. Discoveries made during coding, and modifications to the original plan are raised daily and shared with the entire team within the context of the overall design.

When we discover a challenging problem or an unknown behavior in the software that needs to be discussed with the entire team, this topic is raised during the design workshop instead of the standard review of the story. We gain a mutual awareness of issues, and collective problem solving.

We have also been surprised to see that the side effect of this is faster, more efficient stand-ups. Team members no longer use the stand-up as  an opportunity to share difficulties or discoveries because the design workshop is a better forum for those topics.

Ultimately, we’ve learned that we had both problems of communication and understanding specific to certain individuals and areas of the software. Fortunately, we have a working plan for addressing both issues, and we’ve observed steady progress toward resolving these difficulties.