Why we need to model ahead?
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 client 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 are 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.
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.
ￃﾠ Anyone who can really care about the project.
ￃﾠ Project Manager