The Agile Modeling (AM) Method

Menu

Look-Ahead Modeling: An Agile Core Practice

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. Look-ahead modeling is often referred to as backlog refinement or backlog grooming on Scrum teams.

Why Look-Ahead Modeling?

There are several reasons why you might want to perform look-ahead modeling:

  1. Stakeholders are only available at certain times. I once worked on a team 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 an iteration or two ahead of the actual development of the UI aspects of your system.
  6. You can speed up development. Some 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.
  7. There are differing stakeholder opinions. Most initiatives have a wide range of stakeholders, and one result is that they often don’t agree. So, it is common to perform look-ahead modeling in these situations, at least an iteration ahead, so that the team doesn’t have to wait for the stakeholders to come to agreement.

Figure 1. The AMDD lifecycle: Modeling activities throughout the lifecycle (click to enlarge).

Agile Model Driven Development (AMDD) lifecycle

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 look-ahead modeling 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 proxy stakeholder such as a business analyst (BA) or product owner (PO)who models a bit ahead of the rest of the team, gathering the domain information before the team needs it. The primary danger with this approach, is that having an individual (regardless of their role) do this is that they will filter the information (often inadvertently) which is presented to the team.

A proxy stakeholder such as a Product Owner or Business Analyst is a poor substitute for developers who have both ready access to actual stakeholders and agile modeling skills.

Consequences

On the one hand, with look-ahead modeling 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, look-ahead modeling 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 look-ahead modeling 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 initiative 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 and MaryAnne Liddington for their feedback regarding this article.

Related Resources