One of the questions we often get from companies/projects trying to move to Agile methodology is how does an Agile team deal with interlocks, especially when those interlocks are on the Waterfall methodology and want their requirements and commitment a year to a year and a half in advance?
To be clear and upfront, I don’t have any magic answers that will make the Agile team seamlessly interlock with its Waterfall counterparts. But, with that caveat out of the way, I have been working on an Agile project that has roughly 50 interlocks, almost all of them following the Waterfall methodology.
So, how do we do it? By not being 100% agile, to be truthful. My colleague and myself are what we call “requirements scouts.” Our Agile Product Owners (POs) focus on the current sprint and perhaps a few sprints out. However, we are sent much farther out in terms of requirement development to engage with the business and the interlock teams.
There are times when we are documenting requirements a year and a half in advance of when they would likely be delivered! “Well, that’s not Agile” you may say. And you’re right. It’s a blend of methodologies.
We gather Epics and some User Stories far in advance with the help of the interlock teams and the business. We usually put them in a document we call an ARD (Agile Requirements Document), which is like a slimmed down version of the BRD and has some language about how Agile works. We also try to be very clear that what is in the ARD is not a contract, there are no official approvals and project plans made.
Rather, the ARD signifies the requests of either the business team or the interlock team. We work with each team to define these ARDs with their user stories. Once those are complete, we put them in TFS (the requirements management tool on this particular project) and go over those requirements with the appropriate PO (this project has 7 POs each owning their own area of the project) at high level.
This gives the PO enough information about what is coming to plan sprints and see if anything new needs to be brought up in the backlog, but doesn’t take him away from his day-to-day PO activities.
Finally, as the requirements move up in the backlog and get close to being delivered, the PO reaches out to the business/interlock team to groom the requirements for development.
Is this method perfect? By no means. Things change (as they always do) between the time we write the ARDs and the time the requirements are developed. But it has helped to ease the minds of both our team and the interlock teams we engage with to find a balance between being Agile and only knowing about the next few sprints and looking too far forward.
How does your company/project deal with interlocks?
