We're all familiar with the concept of minimum viable product.
In fintech, those minimum requirements include a lot of regulatory compliance, legal and other complex concerns that can have significant ramifications on how every product feature is supposed to work. Throw in requirements from key partners and customers, and one can easily end up with an MVP with a large scope, and a lot of uncertainty and interdependencies among requirements/stories.
It's very easy then to start spending a lot of time reconciling it all together in attempt to arrive at a coherent picture all teams can align on in detail.
Finally, large investments are typically in the opposite of a skunk works/'fly under the radar until you've got something good to show' situation. Large investments imply commitments - in time as well as revenue. As in - in which quarter can it be delivered/ramped/booked. So for very good business reasons one ends up with a defined budget & timeline on one hand and a quivering mass of stories on the other. What to do?
The common mistake is to attempt to mitigate uncertainty by figuring it all out upfront in sufficient detail. Then everyone is spending most of their effort drawing and redrawing the complete picture and overall progress is very slow.
And, of course, every requirement/story has a product owner behind it, and no PO worth their salt will say 'uh, you know - the thing I'm responsible for - don't worry about it for now'.
Factoring:
In my experience, key has been to factor the entire whole into subgroups of mutually influencing requirements but with fewer fine-grained dependencies between these subgroups. Architecture can serve in leading or analytical capacity for this factoring.
Then decide by fiat which subgroup goes first and start cranking away at it. Yes, without other subgroups the 'MVP' won't see the light of day, and attacking other subgroups later doesn't mean they're less important (as their POs will be worrying about). But one has to start somewhere.
Pipelining:
And then, guess what - while subgroup 1 is being delivered, [C]POs, architects, dev leads and others with responsibilities beyond a single agile team or sprint can free up time to focus on subgroup 2, 3, n, n+1... creating a pipeline.
Seemingly simple, but requires persuading passionate people that being in n-th place in delivery pipeline doesn't imply being in the same place in terms of importance.
In fintech, those minimum requirements include a lot of regulatory compliance, legal and other complex concerns that can have significant ramifications on how every product feature is supposed to work. Throw in requirements from key partners and customers, and one can easily end up with an MVP with a large scope, and a lot of uncertainty and interdependencies among requirements/stories.
It's very easy then to start spending a lot of time reconciling it all together in attempt to arrive at a coherent picture all teams can align on in detail.
Finally, large investments are typically in the opposite of a skunk works/'fly under the radar until you've got something good to show' situation. Large investments imply commitments - in time as well as revenue. As in - in which quarter can it be delivered/ramped/booked. So for very good business reasons one ends up with a defined budget & timeline on one hand and a quivering mass of stories on the other. What to do?
The common mistake is to attempt to mitigate uncertainty by figuring it all out upfront in sufficient detail. Then everyone is spending most of their effort drawing and redrawing the complete picture and overall progress is very slow.
And, of course, every requirement/story has a product owner behind it, and no PO worth their salt will say 'uh, you know - the thing I'm responsible for - don't worry about it for now'.
Factoring:
In my experience, key has been to factor the entire whole into subgroups of mutually influencing requirements but with fewer fine-grained dependencies between these subgroups. Architecture can serve in leading or analytical capacity for this factoring.
Then decide by fiat which subgroup goes first and start cranking away at it. Yes, without other subgroups the 'MVP' won't see the light of day, and attacking other subgroups later doesn't mean they're less important (as their POs will be worrying about). But one has to start somewhere.
Pipelining:
And then, guess what - while subgroup 1 is being delivered, [C]POs, architects, dev leads and others with responsibilities beyond a single agile team or sprint can free up time to focus on subgroup 2, 3, n, n+1... creating a pipeline.
Seemingly simple, but requires persuading passionate people that being in n-th place in delivery pipeline doesn't imply being in the same place in terms of importance.
