I have come across recently a way of developing software in an “agile” way. Stories are written, encapsulating some functionality and subsequent stories enhance or build on those areas. They are tested and deployed for review during and at the end of the sprint. Everything is working as you would expect. You work on a process till it is “finished”.
Is it really finished though?
However, what if there are dependant processes down stream? Can we say that the 1st process is done? It is like wiring a house without ever checking that switch A turns on light A. You wait till the whole house is built and decorated before finding out a) it isn’t finished and b) you need to make a hole in that wall to get into the wiring again. (I don’t know if this is strictly how you would fix that issue, i am not an electrician! Hopefully the analogy holds though).
An alternative process would be to develop part of the 1st process, then implement it’s usage in process B to verify a) it works and b) assumptions on it’s structure/format/workflow are correct. For instance we have a process to define some business rules, set parameters, data to be used in another process. We then implement a basic usage of those business rules to show them being applied and verify that amending them gives us the desired results. This is kind of like Unit Testing (or even Test Driven Development) for the application from a end to end point of view. We write enough code to add or edit some of these business rules, then enough code to test that their usage is correct. We can keep iterating over this adding more features and testing their usages.
This approach can catch unexpected behaviour and quickly highlight where additional refinement or changes need to be made. We also have a fully working system (basic at first, gaining more business value over time).