Agile and waterfall projects both have their benefits and their drawbacks from a BA perspective. Using an iterative approach is less risky – it allows basic structure to be developed and approved by would-be users before specifying more complex functionality. Requirements-up-front approaches allow a BA to be more confident that the overall development is cohesive and meets the requirements of the business as a whole. On the other hand, researching and writing a complete spec up front can mean a long delay before development starts, and a lot more thoroughness is required when detailing requirements. Defining things iteratively can be difficult to manage on larger projects.#
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?
Comentários