Practice6.Frequent Rapid Design Meetings

Practice 6. Frequent Rapid Design Meetings

The rapid design meeting is an important mechanism for a team to ensure it is having frequent design discussions. The output of these meetings is a shared understanding of the design issues and a lightweight artifact such as a picture of a whiteboard diagram. This is a departure from more formal design meeting where the output is a document. The desired output of a rapid design meeting is shared understanding, learning, and collaboration. This is a recognition that the source code and automated tests should be where the design is ultimately documented, supported by the most recent design illustrations, and the emphasis should be on the finished product not the design documentation.

There are two types of design meetings that teams can use: the design discussion and the design review. A design discussion is when a number of team members get together to discuss design decisions of any kind. A design review is an opportunity for a team to analyze its current architecture and discuss short and long-term changes that need to be made.

Design discussions should happen more frequently than design reviews. Most design discussions are going to be purely ad-hoc, when an issue comes up, a number of people get together to discuss it. If ad-hoc discussions aren't taking place on your project, then you have a serious collaboration problem. You may find it useful to introduce a regularly scheduled (e.g., every Friday from 35) design discussion so the team can do a deeper review of one particular area of the design, either what has been completed or what needs to be added. These discussions are rarely a waste of time, because they give the entire team a chance to learn and collaborate.

Design review meetings might be held after every Nth iteration, or they might be added to the agenda in a retrospective. As with a retrospective, the goal of the design review is not to assign blame but to learn and provide a positive future direction for the design. Typically, the design review would consist of answering some basic questions about the product's design as it currently stands, such as:

• What areas of the current design are working well?

• What areas of the current design are not working well and should be refactored or rewritten?

• Are there areas of the code that are too tightly coupled?

• Are there areas of the code that are going to be changed a great deal with upcoming features, but are difficult to understand or are fragile?

The result of answering these questions should be a list of problem areas. The team should prioritize these, record the main benefits to the work, incorporate the important work into upcoming iterations, and ensure the rest are recorded (e.g., in the bug-tracking system) to be completed in an upcoming release. As part of incorporating some of this work in upcoming iterations, a recommended approach is to write up a feature card for the work. Even though the work is not a user feature per se, users need to understand why they are not getting a feature and ideally should understand the work (at a high level) so appropriate tradeoffs can be made. People are always skeptical when they hear this suggestion, but in my experience, users care about the stability of the applications they use and are willing to make these tradeoffs when the benefits can be explained to them.

Note that as part of answering these questions, there are excellent opportunities to learn about good design and bad design. This is team professional development, and it helps everyone on the team improve his or her craft and become better software professionals. It is also an excellent opportunity for more experienced developers to pass on the knowledge they have acquired through their careers.

Tip: Design sessions and reviews are valuable for more than just software

Many possible areas of design are vital to a typical software project (e.g., database, web site, user interface, customer support, etc.). Think about all the areas of design for your project and ensure you spend adequate time on them, too.