In practice, I have found that there are various interpretations on the scale between agile and waterfall, with varying levels of definition up front. If an agile project is going to succeed, I believe there needs to be a very clear agreed scope and some solid high-level definition up front regarding what is being developed, its structure and architecture. In practice, it is often helpful to outline the major business requirements up front and the over-arching approaches to solving them, as without this it can be very difficult to brief in specific development tickets that add up to a meaningful solution that hangs together as a whole. In practice, this can mean writing a sort of outline BRD that does not go into too much detail.
One client I work with in a Lead BA capacity is running a large project that has a number of different development streams. These streams are being developed by two internal (but geographically separated) teams and one external development company. The streams are all related and there are plenty of inter-dependencies, but one of the internal teams is using a cyclical waterfall type approach, whilst the other two are using stricter agile approaches. From a BA perspective, this has been a real challenge, because it has been necessary to define just enough detail up front across the entire project to be confident that the waterfall stream BRD/FSD provides for any needs the two agile streams will have later in their iterative process. As a way of managing this, I created a sort of ‘iterative BRD’, each one covering a specific cross-stream function such as ‘Travel Agencies’, ‘Clients’, ‘Pricing’ etc. The documents contain requirements for all three teams and I work down from a set of user stories into the specifics in an iterative consultation with the teams so that the dependencies are pulled out and specified. Then with the agile teams I pause, but with the waterfall team I continue defining down to the detail level. The agile team sections then become the skeleton of the detail development tickets later on when they are prioritised to enter the backlog.
I would be interested to hear from anyone else who has worked on a project that involves multiple teams using different development approaches. What worked or didn’t work for you? What strategies did you use for getting that detail level correct?