Three Ways to Eat the Elephant of Technical Debt
This article explores the challenges of trying to overcome technical debt that we have accrued after a period of being stuck in a SaaS MVP Black Hole. This article is intended for small SaaS companies who are not necessarily startups from a time-in-business perspective, and are in a mature market space where the optimal operating size is 150-300 employees. This means that 1) we are not a tech giant, 2) our company and market space have both been around a while, and 3) our small size prevents us from building an entire dev program that focuses solely on overcoming our functional and technical debt.
The Spectrum of Approaches on How to Eat the Elephant
One obvious end of this spectrum is the old cliché: one bite at a time. When I show up on scene as a SaaS consultant, this is the approach that I most often observe, already in progress. It entails an ongoing competition for prioritization between net-new features/stories and technology refresh/refactoring/re-architecting. The pros of this approach are that this is the status quo on how this is done, and so it is low-risk to simply continue that way. The cons are that it slows the functional innovation for product management to offer more to customers, and causes atrophy in keeping our technical infrastructure and engineering frameworks up to date.
The other side of the spectrum is: big bang. This is often attempted after an organization and/or its customers have become fed up with having been stuck in the SaaS MVP Black Hole, and have been hamstrung by stagnating SaaS functionality. This entails dedicating most or all dev capacity to one fatal swoop to get over the hump. The pros of this approach are that it can provide the energy to overcome and escape the black hole, getting us back to a continuous value stream of SaaS innovations. The con is that it has a high risk of being a total failure, often due to the insufficient planning offered by incremental agile methods along with decisions being made under duress.
Attempts to use incremental agile methods to attack major SaaS initiatives to refresh/refactor/re-architect often end in total failure, due to insufficient planning.
D’Mention systems, LLC
3 Ways to Eat the Elephant
| 1) One Bite at a Time | Status quo – using agile processes in place to juggle innovation and refactoring until we reach a better place |
| 2) Microapp Partitioning | Partition your SaaS app into smaller apps, such that as they come online they are refreshed with the latest technology as well as fresh functionality |
| 3) Big Bang Project | Create a mid-to-long term plan employing whole-product thinking, using phases and critical path analysis to find creative ways to flex capacity throughout |
Why Not Option 1 – One Bite at a Time?
The way to determine if we should just go on this way is to ask ourselves: Can we see the end? By that I mean, does our SDLC/agile process in place currently have a grasp on all of the issues hampering us, such that we have story points against stories and enabler tasks in place to mitigate?
If not, then we can either let the atrophy continue indefinitely, or try something else like the two options below.
Option 2 – Microapp Partitioning in Program Increments
Take a moment to envision our whole product/application. Can you divide it up into pieces logically? These thoughts are where to begin our approach toward microapp partitioning, and they need to replace thoughts of old, like: What is the easiest thing for us to fix next? These kinds of questions bog down engineering managers and lead to knee-jerk estimations. We need to change how we think because this kind of incremental thinking is what got is into the SaaS black hole in the first place.
If we can get into the right mindset, we can begin to strategically plan a set of initiatives to redevelop portions of our product/application into smaller applications called micro applications, or microapps. These can be built from the ground-up using the latest technology. One great feature of this methodology is that mitigation for capacity strain on our next inevitable technology refresh is baked in. With that, if we can involve product managers and product owners in the planning, our new microapps can also offer fresh capabilities upon release that were long-awaited while stuck in the black hole.
If our shop only has incremental agile methods in place, such as loose implementations of Scrum or Lean Kanban, we will need to up our game in order to ensure a successful outcome with microapp partitioning. This is because success on something like this requires strategy and planning beyond the next sprint. We do not need to go to the level of a waterfall project, however, we need to start thinking in terms of a chronology of sprints across teams, using a framework like SAFe Scaled Agile. If we can do this, we can set ourselves up for eating the elephant of technical/functional debt with microapp partitioning.
Big Bang Transformation Projects
Depending on our product space, it may not be feasible to partition our application(s) into microapps. In other cases, re-architecture might still be required even after a successful initiative to partition into microapps. In these instances, we may need to plan a comprehensive project.
As stated in the opening of this article, many organizations lack the staff size and resources to undertake this, so we need to find alternatives. One such alternative is staff augmentation for such a project. A common way to do this would be to bring on an enterprise architect and/or project manager in a contract situation to plan and design, and then outsource the initial phases of dev work, such that your in-house teams could take on the iterative phases of rigorous QA and iterative work to perfect the product for production use. This approach offers a way to control capacity and budget as well as set a predictable timeline for release.
This type of effort could benefit from structuring the project as a waterfall effort. This is because at our size, we need the effort to have hard start and end dates in order to control the budget. We do this to limit risk, because firstly, we might be financing this through a loan, revenues from another business unit or an injection of capital, which is a finite sum. Agile approaches welcome change, which in this budget space cannot be afforded. Secondly, if we are outsourcing development to third parties, they usually need to work off of something that resembles requirements rather than collaboration spurred by high-level ideas. Leaning toward the latter leans more agilely, and with that, imposes a detriment of the timeline and budget.
Finally, there is an unavoidable risk that the transformation project does not reach fruition during the budgeted timeline. To avoid losing the value developed over this effort, the project plan needs to deliver things like comprehensive documentation and design decks. This can help us deal with the widely-known industry statistic that ~70% of all tech projects are a total failure, by planning for the most-likely scenario that it will be incomplete when the end-date arrives. This ensures that you can still allot capacity to iterating on this investment when your shop downshifts back into business-as-usual mode, continuing the work of the initiative instead of just deeming it a failure.
Closing
Is your shop in a perpetual state where you have to allot a majority of capacity toward fixing problems in lieu of innovating? This is a very common problem. Although I rattled off a few approaches to solve this above, none of them are simple. Rest assured, many competitors are likely to be in a similar situation, and if you are able to overcome – you could be standing alone, uninhibited to out-innovate the rest.
At D’Mention Systems, we do staff augmentation engagements in which we can help manage transformations, oversee total product re-writes or head up enterprise architecture and strategic planning. We would love an opportunity to help, please do not hesitate to call on us.
Mike Liskow is a business development consultant, writer, artist, entrepreneur and thought leader in the business development space for tech startups.
D'Mention Systems was established in 2003 and provides business development consulting engagements for tech startups.
