Approaches to problem solving
The following three acronyms are all different approaches to problem solving and finding a solution:
- Proof of Concepts (PoCs) are great for discovery and risk mitigation within a narrow problem set.
-
Minimal Viable Products (MVPs) are great for iterating through a number of build-measure-learn cycles when the solution is not known.
- Shortest Path to Value (SPV) is great for the partial replacement of a legacy system.
While each of these are great under some circumstances, when undergoing a large scale modernisation project, there are some significant
drawbacks:
-
PoCs are ultimately thrown away as their functional and non-functional requirements are too narrow to fit in a large scale modernisation.
- MVPs are searching for a solution but in large scale modernisations the target is known making the search less important.
-
SPVs are designed to work in large scale modernisation projects but are used in conjunction with the strangler fig pattern that takes way
too long.
How will Jidoka learn from these?
-
PoCs will be used for tech spikes to remove risk from a project as early as practical in the project. The code from the PoC will be used as a
reference for upgrading a bots capabilities.
-
MVPs will not be used as we will replace the legacy system as close to like-for-like (L4L) as practical. We will lean towards deferring
improvements to the legacy system until after the replacement system is on the new technology stack and in a far better position to consider
changes.
-
SPVs will not be used as the integration complexity of a project increases as functionality is replaced (strangled) from the legacy system.
We will consider larger, most times the whole, legacy system to be replaced.
As crazy as that last point sounds, we are advocating a big bang approach. If a big bang approach can be objectively analysed, there are
some significant benefits that could result. Here are some points to consider in favour of a big bang:
-
Each time a legacy system is divided (or strangled) many integrations are created between the old and the new systems. This boundary is slow
to form and adds more risk. By minimising the number of integrations, overall time in the project can be saved.
-
Traditional software teams (without a codebot) had to fulfil requirements by manually writing code. For these teams, a big bang would take
far too long before they shipped something due to the manual work, making the project infeasible. A codebot circumvents this problem as many
requirements can be fulfilled at scale.
-
Under circumstances where the solution is not known, a big bang approach is not recommended because dividing the work into smaller parts
gives more opportunities to explore and test assumptions (like for an MVP). In a modernisation project, the solution is known so the need to
divide the work and explore, test assumptions, etc is far less.
-
Taking longer by unnecessarily dividing a legacy system will expose an organisation to getting caught part way through the modernisation if
the project is halted for external reasons (like budget reprioritisation). In other words, shorten the length of time so you don't get
caught part way.
Will a big bang be possible on every project? Most likely not, you may need to do a few smaller fire crackers but do as few as you can. Play
to your strengths.
