Sometimes you find yourself in a situation where you can't easily model storm a requirement or design issue for a few minutes on a just-in-time (JIT) basis.  Perhaps your stakeholder(s) aren't available 100% of the time, perhaps they don't fully understand a difficult issue, or perhaps you are so tight for time that you don't mind potentially wasting money on over modeling for the sake of shaving a week or two off your schedule.  In these situations you may decide to have someone "model a bit ahead" of the developers on your team, gathering information, exploring requirements, and thinking through the detailed design before you actually implement the software.  This modeling is done in parallel to the development effort, often a few days or weeks before the information is actually needed.

Motivation

There are several reasons why you might want to model ahead:

1. Stakeholders are only available at certain times.  I once worked on a project where the business stakeholders were available for one-to-three days per month and specific individuals had to be scheduled two months in advance.  During these modeling sessions we would first address any domain questions which we had identified since the last modeling session, then we started exploring new concepts which we believed we would run into during the coming iteration.  Scheduling challenges forced us to model ahead.

2. Stakeholder time is valuable.  You may want to prepare for modeling sessions with these stakeholders so as not to waste their time by not understanding the fundamentals of what they're talking about.  Your goal would be to understand their area of expertise and therefore be able to ask more intelligent questions.  Unfortunately, you risk coming to the table with preconceived notions or having a firmer understanding of the issue because the stakeholder hasn't yet done the requisite thinking, so be careful.

3. Sometimes a requirement or technical solution is very difficult.  One of my clients implements very difficult financial business rules, and some of these rules are so complex that the expert(s) need to work through them first before trying to explain them to the developers.  The stakeholders know what they’re talking about, many of them have PhDs in the subject matter, and the developers have a solid understanding of the domain as well; even so, it is still more efficient for the stakeholders to first work through the logic of the business rule with a modeler before they discuss it to the developers.  The stakeholders are still available to work with the developers to answer their questions on a JIT basis, but they first work with the modeler for several hours to coalesce their ideas.  Another example is that in some large organizations it takes time to come to some sort of agreement regarding the nature of their source data (my advice: you need just good enough data for your situation, not a perfect "one truth").

4. You need to integrate with a poorly documented legacy asset.  Legacy analysis is often a difficult and time consuming effort.  If your architecture indicates that you need to interact with such an asset, and the requirement to do so is fast approaching, you should consider doing this analysis just before you need the information.

5. Usability issues need to be considered.  Many user-centered design techniques, such as doing user research, require up-front work, even on agile teams.  Sometimes you require specific resources such as usability labs, or access to specific people, both of which must be scheduled in advance.  In other words, you may need to do usability modeling a bit ahead of the actual development of the UI aspects of your system.

6. You can speed up development.  Some project teams like to quicken the pace of development cycles by getting a head start by modeling upcoming requirements.  During iteration N they model various aspects of iteration N+1, increasing their understanding of what needs to be built and thereby enabling them to more accurately identify the work to be done.  By parallelizing development activities like this they decrease their overall schedule.  Furthermore, when the customers/product owner come prepared to the iteration planning/modeling effort at the beginning of an iteration you can reduce the time required for this activity substantially, leaving more time in the iteration for development activities.

Figure 1. The AMDD lifecycle: Modeling activities throughout the lifecycle of a project.

Solution

As Figure 2 indicates, agilists work treat requirements (and other types of work item for that matter) as if they existed on a prioritized stack which changes to reflect the current needs of the stakeholders.  With “agile modeling a bit ahead” your team does just enough modeling to understand a requirement which has been assigned to some point in the near future, such as an upcoming iteration or even just later in the current iteration.  This modeling will potentially go down to the design level, although you will rarely need this level of detail (remember, you should still only model just barely enough to meet your exact needs).  Most commonly, you look ahead to the next iteration to explore upcoming requirements.  To remain agile you want to model just the complicated requirements of the coming iteration, not every single one.  In other words, apply this process pattern sparingly.  

Figure 2. Agile requirements change management process.

Some teams will choose to employ a business analyst (BA) who models a bit ahead of the rest of the team, gathering the domain information before the team needs it.  This person may even act as the primary customer to your team, representing your project stakeholders to your team while working with them behind the scenes to gather the requisite information.  The primary danger with this approach, of course, is that the BA will filter the information (often inadvertently) which is presented to the team.

Consequences

On the one hand, with model a bit ahead you clearly run the risk of modeling something you eventually don’t need to build: your stakeholders might decide to drop or radically change a requirement between the time you model it and the time you go to implement it.   In short, the further ahead that you model, the greater the chance of falling victim to the problems surrounding big modeling up front (BMUF).  Furthermore, you risk forgetting the information the greater the period between modeling it and implementing it, motivating you to write more documentation and thereby slow down your overall effort.

On the other hand, modeling a bit ahead provides the opportunity to streamline development efforts during the coming iteration by ensuring you have the detailed understanding that you need to build the software effectively.  In some ways this is the equivalent of recognizing that the road that you're traveling has a few potholes coming soon and sending someone ahead of your team to fill in the potholes so that the rest of the team doesn't get into trouble when they hit them.  The software development game is a series of trade-offs, and you need to make the right ones for your situation.

Some agile developers will tell you that modeling ahead is heresy, but frankly I’m more interested in strategies which work in practice than with conforming to religious dogma.  There is a big difference between agile modeling ahead and taking a BMUF approach.  With BMUF you attempt to do all of the modeling early in the project and then recording the results via comprehensive documentation.  Yes, you definitely want to avoid the disadvantages of BMUF, which include an inflexible approach to development that often results in significant wastage, over-investment in documentation, and lower productivity due to over-specialization of IT professionals (if you hire good modeling specialists, they’ll create a lot of good models whether you need them or not). 

Acknowledgements

I'd like to thank Paul Oldfield for his feedback regarding this article.

Recommended Resources

• Agile Model Driven Development (AMDD)
• Agile Requirements Change Management
• The Agile System Development Lifecycle (SDLC)
• Examining the Big Requirements Up Front (BRUF) Approach
• Experiences Integrating Sophisticated User Experience Design Practices into Agile Processes (Paul Hodgetts)
• The "Flexible Features Split" Pattern
• "Just Barely Good Enough" Models and Documents?
• The "One Truth Above All Else" Anti-Pattern
• Rethinking the Role of Business Analysts

		The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams.  Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development.  The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD).  The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
		Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation.  It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts.  Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.
		The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with.  These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler.  This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer).  The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.

Let Me Help

I actively work with clients around the world to improve their information technology (IT) practices as both a mentor/coach and trainer.  A full description of what I do, and how to contact me, can be found here.