Inclusive Modeling: User Centered Approaches for Agile Software Development

One of the core practices of Agile Modeling (AM) is Active Stakeholder Participation, which insists that stakeholders be available to provide information, make decisions, and even be involved in modeling. Although many traditionalists will tell you that it's preposterous to expect stakeholders to be actively involved in modeling, agilists know otherwise, as do user centered design (UCD) practitioners.

Unfortunately most stakeholders don't understand the complex diagrams preferred by many traditional modelers, nor do they want to take the time to learn them (the same thing can be said of many developers, but that's a different discussion). The implication is that the models typically supported by software-based modeling tools will hinder communication with stakeholders rather than foster it. The secret is to adopt inclusive models which use simple tools and simple techniques that stakeholders can easily learn and therefore use to help capture and analyze requirements for your system. Yes, some stakeholders have the ability to understand some of the more sophisticated modeling techniques, and can learn to use complex modeling tools, but it's rare to find such people in practice (when you do, act accordingly). The point is that "inclusive" is situational, although my experience is that the simpler the tool or technique the more inclusive it becomes.

Inclusive models can be used to improve the communication which you have with your project stakeholders. Stakeholders can be active participants in modeling if developers are willing to work with inclusive models. Yes, you will very likely find that you need to use other types of models in order to design your software, and that's ok. Inclusive models and inclusive tools are an important aspect of model storming. If you truly value interactions and individuals over processes and tools as the Agile Alliance suggests then you'll consider adopting inclusive modeling techniques.

Simple Tools

There are many simple tools available to you, including:

Whiteboards
Index cards
Post-its
Flip chart paper
String
Word processor (ok, not so simple but most people know how to use them)

The DDJ 2008 Modeling and Documentation survey explored how people approach modeling and documentation. Figure 1 summarizes the results of the question that looked into the primary approach to modeling, and regardless of development paradigm sketching was the most common approach to modeling. The point is that inclusive modeling is a common strategy.

Figure 1. Primary approaches to modeling.

Simple Techniques

The following table summarizes common inclusive modeling techniques, and Agile Models Distilled summarizes a larger number of models (many of which are technical in nature). The examples are from a university system case study or from an online e-commerce system.

Technique	Suggested Tool	Usage	Example
Change Cases	Index Cards Word Processor	Explore potential, architectural level requirements to identify potential changes which could occur in the future.	Change case: Registration will occur completely via the Internet. Likelihood: Medium likelihood within two to three years, very likely within ten years. Impact: Unknown. Although registration will be available online starting in September, we currently expect less than one quarter of registrations to be made via the Internet this year. Response time will be an issue during the peak use periods, which are the two weeks prior to the beginning of classes each term, as well as the first week of classes.
Class Responsibility Collaborator (CRC) cards	Index Cards	Explore business entities, such as Student and Seminar, and the relationships between them via domain modeling. Developers can use CRC cards to do detailed structural modeling of their object designs.
Essential Use Cases	Flip Chart Word Processor	Explore how people will use a system.	Name: Enroll in Seminar Identifier: UC 17 Basic Course of Action: Student provides her name and student number Registrar verifies the student is eligible to enroll in seminars. If not eligible then student informed and use case ends. Registrar asks student which seminar they'd like to enroll in. If they don't know registrar provides student with course catalog if required. Student chooses a seminar or decides not to enroll at all. Registrar checks student record to see if student has previously passed prerequisite courses. If not eligible student is asked to choose another. Registrar validates the seminar fits into student's schedule. Registrar calculates fees Student verifies the cost and either indicates she wants to enroll or not. Registrar enrolls the student in the seminar and bills them for it. The registrar writes enrollment receipt.
Essential User Interface Prototypes	Flip Chart Post It	Identify user interface requirements without committing to a design too early in the project.
Features	Index Cards Word Processor	Identify what people would like from the system	Add a student to a seminar waiting list. Calculate the average mark on a transcript. Drop a student from a seminar.
Free Form Diagrams	Whiteboard Paper	Pretty much everything.
User Interface Sketch	Whiteboard Paper	Define rough design of a screen or page.
User Stories	Index Cards	Explore how people will use a system.