Rethinking Modeling Sessions: Applying Agile Ways of Thinking (WoT)

• Duration
• Types of modeling sessions
• Participants in modeling sessions
• How Formal Should a Modeling Session Be?

Duration

The duration of effective modeling sessions often range from several minutes to several days, with the majority of sessions lasting between ten and thirty minutes. Why such a wide range? To answer this question you need to first consider when modeling sessions occur – modeling occurs throughout your entire development efforts. It is important to understand that your focus changes throughout the lifecycle, at the beginning of the lifecycle you are typically more concerned with understanding “the big picture”, in the middle of your lifecycle you are more concerned with building specific parts of your system, and at the end of the lifecycle your focus is on transitioning your system into production. This change in focus will motivate different styles of modeling sessions, including different durations, throughout your effort.

You are likely to hold longer, initial modeling sessions at the beginning of the lifecycle. During this phase of your initiative which there is a great need to define the scope and to set the initial requirements, as well as to envision a candidate architecture based on those requirements. To reach these goals you often find that you need to hold initial modeling sessions that may take several hours or even several days because you have a lot of ground to cover at the start. My experience is that modeling sessions of greater length than two or three days puts your effort at risk – the longer you go without feedback the greater the chance that what you are modeling does not reflect what actually needs to occur in the case of requirements or what will actually work in practice in the case of architecture. AM’s principle of Rapid Feedback implores that you to reduce the time between modeling something and verifying your model, either by reviewing it with someone else or by following the practice Prove It With Code. Another issue with long modeling sessions is that fatigue begins to set in among participants, modeling can be a mentally draining activity, reducing the quality of their work. Furthermore, the need of participants to return to their regular jobs makes it difficult for many participants to invest more than a couple of days at a time.

Sometimes there is significant pressure to have longer modeling sessions. Many people will argue that you want to get requirements identification over with as soon as possible. However, AM’s principle Embrace Change tells you that this is a naive goal at best because your stakeholder’s understanding of what they need will evolve as the system does. Another common argument for longer sessions is that key personnel are only going to be available once, so you’d better take advantage of them while you can. Common justifications for this include the fact that some people must travel great distances to attend your modeling sessions or they are too busy to take time away from their regular jobs to attend a series of sessions. The travel issue can be dealt with by applying alternative means of communication, such as videoconferencing and email. The argument that someone is too busy to participate is a red herring – it’s far easier to schedule time for several small sessions than one large one. People will also argue that it’s a lot of work to organize modeling sessions so therefore it’s better to have a few large ones than a lot of smaller ones. My advice is to loosen up a bit, make them less formal and therefore easier to organize.

You are likely to hold short modeling sessions, typically ten to twenty minutes in length, during construction. I called these “model storming” sessions because they are impromptu and quick. At this point in time your focus is implementing specific requirements, ideally “small requirement chunks” (for more on this concept see Agile Requirements Modeling). What are examples of small requirement chunks? On an eXtreme Programming (XP) team you would be implementing a user story and on a Feature-Driven Development (FDD) team you’d be implementing a feature. You’ll be working very iteratively at this point, working with your stakeholder to explore the pertinent requirements, perhaps creating an essential UI model or discussing the logic of a business rule, then moving forward to discuss a potential solution for that requirement, often creating a whiteboard sketch to facilitate the discussion, and then moving on to code and test the solution. Agile developers iterate quickly between these steps, modeling requirements with their stakeholder(s) for a few minutes and then modeling the potential solution for a few minutes (ideally in a small group of two or three developers following the practice Model With Others). When you work on small requirement chunks and proceed iteratively you quickly discover that short modeling sessions are sufficient.

How do you keep a modeling session short?

1. Prefer stand-up modeling sessions around a plain old whiteboard (POW) or table because most people are only willing to stand up for short periods of time.
2. Make it a habit to hold short modeling sessions, therefore when they go longer people will start to feel uneasy about it.
3. Keep the modeling session focused on a single topic, one of the advantages of working on a single small requirement chunk at a time.
4. Stop modeling once you’ve fulfilled your goal as the principle Model With a Purpose advises.

Types of Modeling Sessions

A common problem that I see again and again is something that I call “single artifact modeling sessions”, so common in fact that I’ve been tempted to write it up as a process anti-pattern. Common examples of single artifact modeling sessions, when you take them at face value, include use-case modeling sessions, data modeling sessions, and even class modeling sessions. The problem is that the modeling effort is too narrowly focused, although each one of those artifacts are important in their own right they simply aren’t robust enough to be effective. I’ve seen use case modeling sessions that produced bloated use cases because the team started to record business rules, technical requirements, and even information about domain entities in their use cases because they didn’t consider working on other artifacts. I’ve seen data modeling sessions that resulted in what appeared to be a great data model, at least at first, but that eventually proved to need significant refactoring – the data modelers focused only on data-related issues and didn’t consider critical behaviors because “that was something the application programmers would worry about.” Similarly I’ve seen class modeling sessions produce models that resulted in horrendous performance because the object modelers chose to ignore database issues. Their object-oriented analysis and design (OOA&D) methodology was based strictly on the UML, the industry standard, and because it still doesn’t include a data model they ignored these critical design issues. Besides, they felt that was something that the data administrators would deal with.

Why do single artifact modeling sessions occur? Many times they are driven by people who exhibit the “single artifact developer” anti-pattern, developers who focus on a single artifact such as use cases, data models, or class models. When this is your focus, naturally it makes sense to you that you should have modeling sessions whose focus is the creation of that single artifact. This clearly goes against the tenets of AM, which tells that you need Multiple Models in your intellectual toolbox, that you should Create Several Models In Parallel.

A better approach is to hold what I call phase modeling sessions, a modeling session where your focus is on creating models pertinent to the major phases of traditional development such as requirements, analysis, architecture, and design. In requirements modeling sessions your focus would be on defining what your stakeholders want your system to do, analysis modeling sessions focus on fleshing out the requirements, architecture modeling sessions focus on identifying a high-level strategy for how your system will be built, and design modeling sessions focus on identifying a detailed strategy for building a portion of your system. In each of these modeling sessions your team works on several models at once, as appropriate to the phase.For example, in a design modeling session you may work on UML class diagrams, UML state charts, and physical data models. Note that teams following the RUP may want to consider these workflow modeling sessions to stay consistent with RUP terminology.

The best approach is simply to hold agile modeling sessions. Agile software development is highly iterative, particularly on a day-to-day basis, where it is quite common to identify a requirement, analyze it, and propose a potential design strategy within minutes if not seconds. My experience is that this is the way that people actually work, including both developers and stakeholders. For example, when a stakeholder tells me that they need to maintain the surface address for their customers I quickly start thinking about changing the design of the customer editing screen, adding a new class called SurfaceAddress that the Customer class will interact with, and then making changes to my database on the back end to support this new requirement.Within seconds I go from thinking about requirements through analysis and then to design. From the stakeholder side of things I have often run across stakeholders who not only had a requirement but also had a strategy for fulfilling that requirement, it’s common for power users that work with both the system and who create ad-hoc reports from the database to have ideas about how things should be built. In this case the power user is jumping from requirements straight to design. Yes, it’s not the role of your stakeholders to determine how a system should be built, that’s a responsibility of developers (see Active Stakeholder Participation ), so you’ve got an issue to deal with in this situation. If this is the way that people actually work, they quickly iterate between phases, then doesn’t it make sense that your software process reflect this fact?This is where agile modeling sessions come in. In an agile modeling session you apply the practices of AM, and in particular you Create Several Models In Parallel , you Apply The Right Artifact(s) as needed, and you Iterate to Another Artifact as needed. An agile modeling session is one where you model requirements when you need to, where you model your design when you need to, and so on.Yes, you still want to consider requirements issues, analysis issues, and so on when you are modeling, it is just that you will be iterating back and forth between them.

My advice is to never have single artifact modeling sessions, even if your intention is in fact to work on several artifacts at once. This can be hard in some organizations, particularly those that have been following traditional approaches in the past and therefore may be predisposed to highly-specialized efforts such as data modeling session or organizations that have bought into the “use-case driven” marketing rhetoric that dominates object-oriented development methods right now. Phase modeling sessions are often advisable at the beginning of an initiative when fundamental issues such as the scope of the effort and what should your architecture be are yet to be determined. They are also appropriate when you are first adopting agile software development practices and your organization is still struggling with the inherent cultural changes required to do so – phase modeling sessions may be a palatable baby step away from single artifact modeling sessions. Agile modeling sessions are common for short modeling sessions during construction as well as for teams experienced in agile software development when they hold longer modeling sessions that are common at the beginning.

Participants

There are two categories of roles in modeling sessions: active participants and supporting participants.The active participant category contains three basic roles: stakeholders who are there to provide information about the business and to help prioritize requirements; analysts who specialize in working directly with stakeholders to potentially gather/elicit information from them, document that information, and/or validate that information; and developers who are there to work on the models. Active participants are first-class modeling citizens, they are the ones doing the “real work” of modeling, they are the ones who are critical to the success of your initiative.

You need to be careful with how you involve analysts, sometimes known as business analysts or requirements analysts. Although they specialize in working with stakeholders, clearly a very good thing, and can often prove adept acting as a bridge between stakeholders and hard-core developers whose communication skills may be lacking, the can also act as a barrier to productivity. The problem is that when a business analyst is involved on a team many developers will choose to use them as a crutch, to let the analyst focus on working with stakeholders and thereby freeing themselves up to focus on the technology. This isn’t very good, what you really want is developers interacting closely with stakeholders and applying their technical skills to build the appropriate software. In AM there are two primary ways that analysts can be effective. First, in situations where the developers are co-located with stakeholders the analysts can help to build initial rapport between stakeholders and developers and mentor the developers in communication and modeling skills. At the same time the developers should mentor the analysts in the technology, remember the principle Everyone Can Learn from Everyone Else, to make them more effective. Second, when your team does not have ready access to stakeholders, clearly a serious problem that threatens your likelihood of success, they can gather information from stakeholders for the developers and present that information in a format that the developers need. The problem with this is that you are introducing an opportunity for information to be distorted and misinterpreted by not having direct communication. Think back to the “telephone game” that you used to play as a child where one child whispered a message to another, who then whispered that message to another, and so on until it got back to the original child. The more people in between the greater the distortion.

The supporting participant category encapsulates three roles: facilitator, scribe, and observer. Many modeling sessions work perfectly well without anyone in these roles, particularly model storming sessions when people are modeling to understand a portion of the system that they are working on. However, larger modeling sessions, particularly ones early on, will often have people fulfilling these roles. Let’s explore them in detail:

1. Facilitator. A facilitator is someone who is responsible for planning, running, and managing modeling sessions. As a result facilitators have good meeting skills, they understand the modeling process, and they ask valid, intelligent questions to elicit information from the active participants.The role of facilitator is often taken up by the coach or team-lead – this is a senior person that the developers and stakeholders should trust and respect and who should have good communication and modeling skills. Large organizations may have professional meeting facilitators on staff that are typically used for more formal modeling sessions, as discussed below. The advantage of professional meeting facilitators are that they are very thorough and good at their jobs, the major disadvantage is that they are often better suited for prescriptive processes and may need some coaching in agility. Although smaller and/or informal modeling sessions may not have a designated person whose only role is to facilitate there still needs to be someone(s) responsible for ensuring that the modeling session is run effectively.
2. Scribe. A scribe is a person responsible for recording information during a modeling session. As a result scribes need good listening skills, good oral communication skills (they will often need to ask questions to determine exactly what the active participants mean), and they have an ear for business logic and technical details. There are two schools of thought regarding who to put in the scribe role: a professional scribe, often a technical writer, or a developer.I prefer putting a developer in that role, both to help grow them as communicators as well as to ensure that they are actually picking up what is being discussed. It can be a good lesson in humility to hear a user tell you what they actually want and how they actually work with your software, as opposed to the really neat features that you mistakenly believe they can’t wait to receive.To be fair, and to ensure that everyone on your team has the opportunity to improve their skillset, you should make this role a rotating one that an individual fills occasionally. Finally, if you’re going to have scribes in your modeling sessions, you may decide to simply record all information in the models that you are creating, then you are best to have two or even three people scribing – you can’t write as fast as several people can talk, and because each person has their own unique background they will pick up (as well as miss) different types of information.
3. Observer. Traditionally an observer is someone who is not there to participate in a modeling session but instead is supposed to sit back and watch what occurs so that they can learn the process. Perhaps they are a facilitator in training or they are involved with an upcoming initiative that wants to take the same approach that your team is following. Someone who sits there and does nothing?That doesn’t sound right. A more agile approach is to put “observers” to work, as active participants if they have domain knowledge or modeling skills or worst case as scribes. The goal of an observer is to learn the process, and the best way to learn things is through hands-on experience, therefore by having them involved with the modeling session not only do you increase the number of people actually adding value in your modeling session you also improve their learning experience. Two birds, one stone.

How many people should be involved with a modeling session? Just barely enough. Every single person should have a valid reason for being there, not just a political reason such as “Sally Jones insists that someone from her group attends”. If Sally Jones provides someone then they should come to the modeling session prepared to work, and be willing to follow through on any action items that they are assigned during the modeling session such as obtaining more information or being involved in a follow up effort.There is often significant political pressure for too many people to be involved in a modeling session, particularly at the start of an initiative, pressure that is hard to counteract. I will very often hold a large requirements gathering session at the beginning that has way too many people, twenty or thirty people in these meetings are common although sometimes you can have several hundred people in some situations, just to let everyone know that their voices are being heard as well as to help identify the handful of stakeholders that can actually contribute something of value. I’ll also do the same thing when it comes to architecture, involving a wide range of technical people throughout the organization. The problem is that there are diminishing rates of return once you’ve reached groups of seven or eight people – there is less of a chance that a new person will bring new information to the group, assuming you’re picking participants in an intelligent manner, and there is less opportunity for an individual to actively participate because you are dividing the amount of “air time” between a greater number of people.

How Formal Should a Modeling Session Be?

First and foremost, just because a modeling session is formal it doesn’t mean that it is necessarily less agile. Yes, formality has a bad reputation among many developers but that doesn’t mean that a formal session cannot be an effective one. At one end of the spectrum you have very formal modeling sessions such as Joint Application Development (JAD) sessions. A JAD is a facilitated and highly structured meeting that has specific roles (facilitator, participant, scribe, and observer), defined rules of behavior including when to speak, and suggestions for room organization (typically a U-shaped table). Before a JAD it is common practice to distribute a well-defined agenda and an information package which everyone is expected to read. Official meeting minutes are written and distributed after a JAD, including a list of action items assigned during the JAD that the facilitator is responsible for ensuring are actually performed. At the other end of the spectrum are ad-hoc modeling sessions where the impetus for having them is often the realization that you need some help. People are quickly gathered, hopefully the “right” people are readily available, you work together, and once you’re done you quickly disband.

The formality of modeling sessions can be anywhere in between these two extremes. Table 1 < >a>suggests when each style may be applicable. Because your immediate needs often include applicability factors from each type of formality you need to decide how formal to make your session. For example, how formal would you want to make a ten-person, half-day modeling session where all ten people work at the same physical location and can be scheduled within a two-day notice? How about a five-person, two-day modeling session where two people need to fly in from another location? The answer is the same for both situations: just formal enough. The greater the formality the more work you need to do to hold the modeling session, and according to the principle maximize stakeholder ROI any work that you do should have positive value. Distribute an agenda if it will help people to prepare properly for the session, don’t forget that your agenda could be as simple as an email. Distribute meeting minutes if appropriate, it could be as simple as an email listing point-form action items assigned to individuals and an URL pointing to a web page of digital pictures of the diagrams that you created during the modeling sessions. AM’s practice Create Simple Content applies to management artifacts as well as models.

Table 1. When Each Formality Style is Applicable.