There should be little difficulty in understanding the requirements of a software product when there are less then six people involved in a project; team members know who to talk to about what issue. However, as teams grow in number and projects become more complex requirements tend to become more dynamic, increasing the likelihood that changes will be needed. Similarly, complex products have greater risk because they are more expensive, employ larger teams and typically have more urgent time-to-market demands. At the same time, products developed under the Agile development methods (XP, SCRUM, etc) are demonstrating significant advantage to traditional methods in responding to dynamic requirements. However, Agile methods have typically been applied to small projects. Is it possible to gain the same advantages on a large complex project? This article will provide some practical examples of how to tailor the Use Case creation process around the type of iterative lifecycle defined in the Agile methods.

However, there are some valuable concepts within the Agile methods that can be applied to large complex projects which can further success on these large complex projects by using use cases to formalize communication and an iterative development lifecycle to amortize and prioritize requirements across the release cycle.

Creating the test harness first (before function related code – not before acceptance criteria) forces both the domain expert and the developer to understand what s/he is supposed to create before they actually create the code, to a very low level of detail. And Test First essentially creates an evolving regression tests harness that is truly usable, fully automated, and readily available. The engineering teams that I am associated with have documented statistics that show a 1,500% improvement in code quality resulting from the consistent use of an automated regression tests harness. Test First, alone, can therefore improve the productivity of a development effort by this astounding 1,500% improvement level. What is really amazing is how few engineering teams developing multiple release software products also create automate tests harnesses. In the traditional waterfall development lifecycle, automated test harnesses are an after thought that almost never get built. And then the project teams are surprised at the number of defects found during the QA cycle (after development is supposed to be completed). This 1,500% improvement exemplifies the great value of the Test First tenet.

To bring this concept back to writing effective use cases in an iterative lifecycle, before one can employ Test First, one must write the acceptance test plan, which in a large complex project with geographically dispersed team members is derived from well written use cases.

In a typical Agile project, with domain experts and developers in very small teams and physically co-located, there are no worries about loosing requirements. For those of us developing products with larger geographically dispersed teams, the clue should be obvious, save the acceptance test plans; these represent a more complete and up-to-date set of the detailed user requirements then the originating use cases which the tests were derived from. And because more units are continuously integrated into the build, the acceptance tests are more likely then the use cases to be reused and updated.

In the Agile methods, integration happens as soon as the developer attempts to check a developed object into the system repository. If upon check-in, any of the automated tests for previously checked-in objects fail, then the new object is in some way the identifier of the problem, and a fix must be completed before the object can be checked-in. The developer has the choice to either fix the object or reschedule the development effort (for that object) for another day – with all of the inherent schedule delay issues that would cause. With continuous integration, the complexity of a very large project can be held under control, even as the product grows and evolves, because no new objects are added to the system (aka, integrated) until all of the automated test of previously integrated objects pass successfully (regressively).

The rate of completion within an iteration is the velocity, which provides the basis for planning the next iteration. It is important to re-plan the entire release along with each iteration plan. This focuses the team’s attention on what features to add next to the evolving product, rather then what administrative tasks are next (I’ve seen too many project plans where the critical path was comprised entirely of administrative tasks). The confusion of what deliverables or tasks which need to be combined to create the critical path is resolved.

In Agile methods, the practice is to re-prioritize the list of features to be developed at the start of each iteration. In this way, if the schedule goes long, the features that may be cut from the release plan in order to meet the schedule commitment are the lowest priority features. Some may say that this is a plan that assumes failure. It is easy to forget that engineering estimating is often a rough science and that pre-calculating unforeseen problems is sometimes impossible – no matter the experience level of the engineering team or the depth of the historical database used in estimating. When those unforeseen events happen it is an advantage to be able to make the decision on whether or not to release the product on schedule, pushing some of the low priority features into the next release.

A General Manager once told me that he worried about getting all of the features into the next release. The iterative method, where features were left undefined until a future scheduled iteration, scared him into believing that some features would surely be left out of the release.

“We need all of these features!” he cried.
“Are the features being developed in priority order?” I asked.
“Yes, but low priority does not mean no priority,” he lamented.

Consider that 70% of large software projects across the software industry fail to meet their schedule, cost or business objectives. There are many reasons for this, and they should be address. However, software estimating is not an exact science. It is only prudent planning to work on the high priority items first.

Continuously re-prioritizing the features list and re-estimating based on that new priority, and then developing according to the new priority, preserves options when trying to meet schedule commitments. This is far better then grinding onward with a project, usually well beyond the planned delivery date, because some high priority features are not working yet (because they were not tackled until too late in the schedule). When this happens, and it happens too often, there are no options.

Ed has been building software products for more than 20 years, with particular expertise in automating economic analyses, decision support and supply-chain management processes. He is currently a sales executive with Agilis Solutions and has provided strategic technology leadership in roles such as the vice president of engineering for Egghead.com, director of technology at Nike and director of software engineering at Boeing.

Contact the author.