Design By Walking Around

Richard A. Zahniser

CASELab, Inc.

Design By Walking Around (DBWA) is a collaborative software analysis and design approach developed by CASELab over the past four years^[1]. After some preliminary success with System Storyboarding Techniques^[2], we began a series of research projects that developed and proved a group-oriented, multi-dimensional approach to building a high-quality design in an extremely short time. It enables a team to produce a software design in a quarter of the time required by more sequential approaches.

The approach requires that participants make three paradigm shifts:

1. From independent knowledge workers to a cross-functional team.

2. From two-dimensional to N-dimensional system modeling.

3. From linear to concurrent development.

Changing The Nature Of Software Teamwork

Traditionally, people think of programmers as being cut from the 'hacker pattern', brilliant but idiosyncratic loners who drink a six-pack of Jolt and turn out thousands of lines of code a night, or techies buried in the basement with listings, like accountants of old. Certainly these computing icons exist, but most software today is built by loosely organized groups of workers who have had little if any training in software teamwork. We need to make a conscious shift from expert knowledge workers, working fairly independently to produce modular system components, to cross-functional teams, consisting of a variety of system experts, working jointly to ensure quality and a consensus system solution to a jointly defined user problem set.

Group Success Factors

Teams are a hot topic today; there are three well-established trends which the software team should exploit to ensure success.

A cross-functional team. Experience in concurrent engineering of manufactured products has demonstrated that joint participation by a broad cross-section of users and development experts will solve many of the "us vs. them" problems associated with traditional software development. For example, including a test and integration specialist on the team from its inception improves the odds that the team will demonstrate and deliver a working system. Including users makes them collaborators as well as stakeholders in the outcome. This trend is well documented by a brace of articles in the June 1993 Communications ACM. (Special issue on Participatory Design)

Empowerment. This overworked buzzword describes the fact that everyone on the design team is both qualified and empowered to make decisions on the spot, thus eliminating the whipsaw "I'll find out and get back to you" routine which turns days into weeks during analysis. The empowered team has the total responsibility to define both the problem set and the solution, with management reviews to demonstrate (and celebrate) the team's progress.

Group Memory. Since the mid-70's, it has been well understood that a shared group memory can change the dynamics of a group[3]. We expand this concept by using numerous storyboards (as many as six at a time) that allow us to build multiple models of the system quickly. These feed an online system development notebook which contains all of the design and project status information. This online group memory is one of the keys to the remarkable success of the Alpha AXP project, which coordinated 32 teams -- over 2000 people in ten countries -- and delivered its final product on schedule^[4].

Sidebar

Sequential vs. Concurrent Activities

If I talk and then you talk and then I talk, etc., this is a sequential activity. Q & A, single-media presentations, authoring, and structured walkthroughs are all sequential. Debates are sequential. Traditional brainstorming, where participants tender one idea at a time, is sequential.

Storyboarding, where everyone is writing and submitting ideas at the same time, is concurrent. Our experience is that storyboarding is at least three times faster than traditional brainstorming. In addition, it is easier to sustain creative momentum.

Multimedia presentations, especially with electronic feedback devices in the hands of the audience, are heavily concurrent. Clearly, one team imperative should be to keep people working concurrently whenever possible.

If you break a larger group into several dyads, you get concurrent activity from the sub-teams; the penalty is that the entire group must subsequently review each dyad's work to regain synchrony. That penalty is offset if you use this sequential review as an opportunity to add quality to the product.

Time-Shifting. In order to meet together, group members must arrange and rearrange their schedules. In contract, members of the networked team can access the group memory whenever that use fits into their own personal schedule.

Multiple Work Modes

In the successful self-directed team, all of the members are constantly looking for better ways to use themselves as a resource. There are seven modes for working on software; each is more appropriate to a particular system building activities. Here are those modes:

Solo. One person, typically working with one machine and its memory. The memory is not actively being shared with other collaborators. A multi-tasking machine enables concurrency but most work is sequential.

Dyad^[5]. Two or three persons, working on one machine together, or involved in an active face-to-face interchange of information. Work is usually sequential, but may be concurrent if the right low-tech groupware is used (e.g. desk-pads and small Post-its.)

Small Group Meeting Together. The classic small group environment. Classic team building terminology and techniques apply, and the shared group memory dramatically improves the performance of this group by stimulating some concurrent creative activities.

Small Group Networked. Two to twelve people networked electronically. Increasingly, they share a forum, called a conference board (IBM), a notes conference (DEC) or simply NOTES (Lotus). The forum is a group memory which links and enables the group. On the forum, team activities are sequential and time-shifted (see sidebar) rather than concurrent. (On a telephone or video conference, activities need to be sequential to avoid confusion.)

Large Group Meeting Together. Celebrations, kickoff meetings, awards presentations. All of these go better in a large group meeting face-to-face, with refreshments and (sometimes) a jazz band! A periodic retreat for the whole team (called a checkpoint) breaks a long project up into workable increments. Concurrent activities in this environment can produce volumes of input, but typically, activities are sequential and half-duplex. These meetings are very useful to synchronize sub-team activities and milestones.

Large Group Networked. This can be a forum as described above, or simply the BBS environment familiar to most PC owners. Activities are usually less structured than on the small group network, but the resources are broader, and a diverse set of viewpoints can be sampled. Activities are generally sequential. Study groups provide educational services; consulting forums allow a person to get answers and opinions from a remarkably large group of experts. Surveys, signed or anonymous, can be posted and returned in record time. Material which was gathered or created by the large group meeting together can be reviewed sequentially by putting it on the forum and asking everyone to concur or disagree in writing.

Team Of Teams. The structure for the team of teams is shown in Figure 1. The peripheral boxes represent teams, the ring is the group memory which ties them all together, and the box in the center is the executive committee consisting of the project manager, his/her staff, and delegates from each of the teams. Within each box, a team can work in all of the modes listed above; the structure itself is recursive. Clearly, the group memory is the key to making the team of teams work.

A Work Scenario Which Uses Multiple Work Modes

A judicious choice of modes minimizes "dead air time" -- where most of the members of the team are simply listening to two members argue or watching one person create -- and maximizes the use of the team as a creative or evaluative resource. Here is a scenario which shows the team applying these modes to maximum effect as it produces the formal definition of a user problem set:

1. Two or three of the team members meet together, determine a time, and invitation list for a large problem storyboarding session (dyad).

2. One of these puts the invitation out via groupware to all of the parties (solo).

3. The parties, now beginning to function as a networked large group, negotiate among themselves to arrive at the best meeting time. Someone schedules a meeting room.

3. The large group of 20, which is mostly users, meets, and, after a warm-up session, storyboards 500 problem elements in less than an hour (large group meeting).

4. The large group adjourns, and, after a break, ten of them rejoin and work on the storyboard to cluster similar elements to build an "affinity diagram"^[6] (small group meeting).

5. Each cluster is moved onto a smaller storyboard. Sub-teams of three work on each of these to build a "fishbone" diagram which shows the interrelated causes and effects of each problem set (dyad).

6. The dyads rejoin and the group reviews each fishbone diagram, revising and adding elements as required (small group meeting).

7. Individuals (solo) capture each diagram in outline form, and put it on the team forum. After some networked discussion, someone (solo) consolidates the group product, and makes it available to the large group forum.

8. Via E-mail, participants of the original session are notified that the group product is available for review on their forum, and their comments and suggestions are solicited.

This partial scenario should be enough to illustrate the intent -- to use the team members as a high impact resource while keeping the analysis and design process pressing ahead rapidly.

Expanding Our Views Of Software

The second paradigm shift is a gradual move from single two-dimensional system models (such as the functional decomposition diagram) to a richer set of (typically three) diagrams, which James Martin has dubbed the "hyperview"^[7]. However, a modern skyscraper requires many more than three views to portray its complexity. We have found that jointly creating as many as twelve views of the system vastly improves our understanding of its nature and complexity. Several of these views are orthogonal to each other which leads us to describe the system as "N-dimensional". This N-dimensional modeling approach is one significant difference between DBWA and earlier approaches such as Joint Application Design (JAD) and Participatory Design (PD)^[8].

Views of the N-Dimensional System

Decomposition views. One traditional hyperview consists of three diagram sets.

1. The activity decomposition, frequently called a functional decomposition or hierarchy chart. This view is the rear elevation in Figure 2.

2. Leveled Data Flow Diagrams (DFDs), which begin with a one-bubble context diagram as a parent, and proceed to sets of successively more detailed child diagrams. This leveled set, if it appeared in Figure 2, would appear as horizontal planes below the context diagram.

3. A module chart which shows the set of modules derived from the DFDs. This is the front elevation in Figure 2.

Another hyperview, consisting of data flows, an information model, and a set of state transition diagrams, is described by DeMarco^[9]. Traditionally, these views have been derived using top-down design; i.e. a top-level abstraction is created which encapsulates the entire application and it is iteratively decomposed. The top down approach can deliver workable system designs, but the very first decomposition may be "wrong", which severely flaws the rest of the design. For example, the first decomposition may be based on an underlying (perhaps even unspoken) assumption that the database will be centralized. The subsequent design will make it difficult to choose a different physical implementation option. Despite this disadvantage, all of these views are valuable, andd historically they have been sufficient to successfully model and build many software applications. DBWA uses an event-driven approach to derive these same views from the middle out, ensuring that they are free of the "old physical system" bias to which the top-down approach falls prey.

Views of Flow. The parallel horizontal planes in Figure 2 are all views which show a network of flows. The context diagram shows the system as a single bubble, with flows of data between the system and the external entities which relate to it. This view of the system is extremely important because:

Building this view creates the first consensus abstraction for the design team.

The team can use this abstraction as an ongoing reference for establishing both the overall system boundary, and the eventual automation boundary.

The data flow diagram (DFD) shown as level three in Figure 2 is a composite diagram which shows all the event-partitioned data flows sown together. Its external entities have a one-to-one relationship with those in the context diagram.

The control flow diagram (CFD) in Figure 2 may be optional. Most data based systems are queue-driven, and control is handled entirely by the transaction processing system. However, in a real-time system where control is critical and should be explicit, this view is necessary.

The materiel flowchart (the bottom plane) is necessary to show physical flows in an existing system, and will handily show work flow in the proposed system.

These diagrams give the team a view of flow; something which cannot be seen with any other diagrams in the hyperview. Both the sequence of processes and the continuity of stimulus data flowing until it creates a response, are shown in these views and only in these views.

Views of Static Data. The side elevations in Figure 2 are views of static data which come into the system and remains there. The object/class model shows the common characteristics which are shared among objects in the problem space. This is an essential model, but our research project teams have frequently tried to "model the world", i.e. build a universe of classes and objects far greater than that involved in this system. DBWA cuts this potentially endless discussion short and "walks around" to the other side of the system, to build a model which shows only the data which comprise the "relevant reality". We combine event-partitioned data models to create a composite Entity-Relationship (E-R) diagram of the required database. Many extant CASE tools can then transform this model directly into database description language (DDL).

Detail Views. The views in Figure 2 are abstract "right-brain" views. To ensure that it has more than a superficial understanding of the system, the team must describe each object in each view in detail, using text and mathematical notation. Using existing legacy system documentation, dyads and individual performers can reverse engineer much of this detail. Some can be elicited from the members of the team through the use of group detail gathering techniques such as brainwriting^[10].

Views of Behavior. All of the views in Figure 2 are 'timeless', i.e. time is not a dimension in any of them. This is one of the characteristics that makes them useful as design abstractions. However, to accurately describe the behavior of the system, we need diagrams and symbolic notation which explicitly show the behavior of a component through time. There is a wide variety of these, including program flow charts, pseudo-code, Jackson diagrams, action diagrams, Warnier-Orr diagrams, Petri nets, state transition diagrams and tables, and state charts^[11]. Object life-cycles[12], and detailed package designs or prototypes are recent additions to these behavioral views of components within the system. End-users, however, need to describe the external stimulus-response behavior of the system. Our teams accomplish this with event sets, described in detail in the next section.

Interface Views. Each of these views shows the system from one narrow perspective. Examples include the Computer-Human Interface (CHI), the instrument bus (such as HPIB or IEEE-488), SCSI, and various communications interfaces. Many of these are predefined and standardized. If these views exist, the team should certainly use them; if there is a new, or non-standard interface, it should be modeled by the team, using the same techniques and work modes used to build other new views.

Physical Views. These include cable layouts, wiring diagrams, memory and data device maps, and the actual screen layouts, report formats, and graphic design for the CHI. Some of these may be developed by individuals or dyads after the conclusion of any group design which might have been done. However, the team can contribute significantly to this design and its review; the more of this work that the team can do before it disbands, the better.

A Repository for Views. Clearly, all of the aforementioned views are richly interrelated. They should be captured using CASE tools in a repository which has analysis and reporting functions that ensure the consistency of these interrelationships. We would anticipate that much of this functionality will appear in CASE tools before the end of the decade. Currently, sequential walkthroughs of the material by the team, and subsequent use of the design during construction are the only sure methods to ensure consistency.

Events As Drivers

As suggested earlier, users are more interested in the external behavior of the system. To exploit this interest fully, DBWA uses a variation of the Essential Systems Analysis approach first developed by McMenamin and Palmer^[13]. This approach elicits a set of "business events" -- events from the user problem space --and uses these events to drive the rest of the team analysis and design activities. We normalize all events to the form: Subject -- Verb -- Object. Both the subject and the object are system objects, so extracting these from our storyboard is fast and efficient. In a pure object-oriented approach, we would proceed with these, deriving states and methods which define object packages. In our more evolutionary approach, the form of each event strongly implies an entity relationship, as well as a set of data flows. After we have developed a candidate set of states for each object, we can use the events as a consistency check. There should be an event to drive each object into each state, and each event, if it is relevant, should participate in at least one of those changes.

Objects as Reference Marks

Some methodologists complain about the redundancy inherent in multiple views. We see this as an advantage. In every view we develop, objects serve as reference marks, reassuring us that we have simply shifted our perspective on the system. Seeing the same objects in every view is reassuring; ensuring that they have consistent labels and characteristics is a positive step towards a coherent design.

How DBWA Works

I have just described a large set of views. Traditionally, a team would develop each view to completion before starting on the next. Each time the team drives towards 100%, it encounters the 90-90 rule:

"The first 90% of a system takes 90% of the time; the last 10% takes 90% of the time."

Figure 3 illustrates that completion of this last 10% approaches the 100% line asymptotically. This is true of any system component which involves learning. Although I was already familiar with the conflict associated with this phase of teamwork, Mike Tanous^[14] helped me to understand that the conflict was due to high uncertainty, and corresponding high risk in this part of the ongoing decision-making process. This high-risk area is shown in Figure 4, and is signaled during teamwork by a slowdown in group performance and the onset of conflict. The coach and the members of the team can readily sense this slowdown -- and attribute it to fatigue -- but it is actually caused by stress. Both the well-being of the team and the quality of the design are best served by moving around the system to work on another view. We do this again and again, hence "Design By Walking Around". By the time we have "circled the system" and get back to our earliest views, we have a much better knowledge of all of the dimensions of system complexity. Our learning curve on these views has changed, and we can now work more efficiently on the remaining details.

Table 1 is a catalog of all the deliverables which can be produced by the cross-functional team. These views show all of the dimensions in a complex system. Many of these are normally postponed until later in the SDLC, but our research shows that they can be built by the cross-functional team very early in the development process, if:

They are built in the right order.

Each view is not "beaten to death" before the next view is developed.

The right work mode is applied at the right time to capture details and ensure quality.

Applying the Principles

Our most effective research projects have produced a sequence of deliverables as shown in Figure 5. Here's an explanation of that roadmap, and the way we produce it.

1. Organization Chart. Storyboarding the organization chart is a consensus activity which helps to build the team.

2. Problem Analysis. A storyboarding session elicits all of the problem elements; clustering them into problem sets creates a shared vision of the entire problem space. Ranking creates a consensus of what areas the new system should attack.

3. System Context. Building this diagram is consensual activity which establishes the system's relationships with other entities, and begins to create a shared understanding of the system boundary.

4. Events. These capture the behavior of the system in user-oriented terms. They are generated in a 40-60 minute blitz which does not attempt to categorize them. Then, they are categorized as external or internal, and normalized into the form Subject-Verb-Object.

5. Object/Class Analysis. The group blitzes potential objects onto a separate storyboard, and then organizes them into classes and subclasses.

6. Attributes. The potential objects are entered on brainwriting sheets, and the team, working silently in roundtable, assigns descriptions, samples, attributes, and (optionally) methods to each object. As part of an immediate review, the brainwriting sheets are clustered into classes, and the object/class model is revised to reflect the team's learnings.

7. Event Sets. The team breaks into two sub-teams, probably along organizational or functional lines. Each sub-team works on events with which it is most familiar. It organizes events into stimulus-response chains, or removes them from further consideration because they are out-of-scope. During this ordering, each event is "purified", i.e. subjects and objects are amended to reflect the team's better understanding of the object/class model. Event chains are clustered into related sequences (scenarios) and each chain is given a reference number, used for later traceability. The assembled group reviews each sub-team's work.

8. Event-Partitioned Data Models. The team breaks into dyads, and, using desk pads as small storyboards, builds a data model for each event set. These are all posted to the wall, and reviewed by the assembled group.

9. Composite Data Model. A capture team, using a CASE tool, builds a composite E-R model which incorporates all of the entities and relationships in the smaller models. This model is populated with data from the earlier attribute brainwriting session. Eventually, this model is reviewed formally by the group.

10. Event-Partitioned Process Models. The entire group brainwrites potential data flows and reference data stores for each event set. Dyads, again using desk pads, build one-page DFDs which show how each event set is processed. These are posted, reviewed by the entire group, then clustered to form logical computer-human scenarios.

11. Computer-Human Interface. Dyads prototype each scenario, using either storyboard prototyping or a computer-based prototyping tool. The assembled group reviews the scenarios for completeness and smooth flow.

12. System Development Notebook. Captured design materials are cleaned up, organized, formally inspected by the group, and presented to higher management for concurrence and go-ahead.

Jump Starting A Project.

Our research shows that a team can produce breakthrough results under the right conditions. We create these conditions with JMPSSTART^[15], a highly structured package of learning materials which introduces the team to DBWA, and then guides them through a tight schedule which produces the first eight products in our roadmap in less than three days.

DBWA achieves breakthrough results by expecting the team to produce a lot of design in a short time. This time imperative could potentially create massive conflict within the team, but our research has proven a variety of techniques to minimize this.

Frequent Rotation Of Team Roles. This is well described by Larry Constantine in his articles on structured open teams^[16].

A Design Process and Agenda. DBWA moves the team smoothly through the production of the deliverables described above.

Just-In-Time Training. Short tutorials and directed reference materials prepare the team to build each specific view[17].

An Aggressive Initial Schedule. This presses the team to dispense with rathole discussions and to become very product-oriented.

Conclusions

We began with the hypothesis that cross-functional teams, using concurrent group techniques and N-dimensional system models could produce a significantly better design in a short time. We have proven this in practice. We see this design and a team-built plan as the best way to "jump-start" a project. These components, on a shared, network group memory, are exactly what is needed to fuel a shared vision for the software team-of-teams, its top management, and other stakeholders. In turn, the shared vision fuels commitment, and commitment empowers the breakthrough team!

Figures

Figure 1. The team of teams

Figure 2. All the timeless orthogonal views of the N-dimensional System

Figure 3. The map.

Figure 4. The 90-90 rule.

Figure 5. Performance and risk in the learning process.

Table 1. DBWA deliverables, media, and modes of working.