How do we manage challenges on long-running products?
Over the years, we had a few ongoing partnerships that lasted three years or more: sonnen, Takamol, PRISMA, and TeamAlert just to name a few. The thing about partnerships like these is that they tend to come with specific challenges due to their length. At Boldare, we’ve learned how to manage those challenges, or even better, how to prevent them. In this article, you will find exactly how we do that.
Table of contents
Keeping up with the newest technologies
In order to deliver digital products that are truly innovative, our team needs to know and use every new technology out there. And to keep up with all the updates, our developers are constantly improving themselves. We, as Boldare, took it upon ourselves to provide regular training sessions which allow them to learn all about the newest frameworks and libraries. So in the end, every new technology becomes something that our developers already know.
Minimizing technical debt
Technical debt is a “result of prioritizing speed of delivery over quality and functionality”. Such code could work fine at first but would need to be updated, refactored (or even replaced) sooner rather than later. At Boldare, in order to keep technical debt to a minimum, we follow a number of good practices:
- frequent refactoring,
- frequent testing,
- maintaining high quality of code,
- keeping up with architecture standards.
With these in place, we build digital products free of an increasing number of bugs, unstable environments, or data inconsistencies - common symptoms of technical debt.
Deviation from the original project scope
Sometimes, over the course of multiple sprints, the project’s scope (its objectives and requirements) can change. If that’s the case, a new task is added to the current sprint. In the simplest words, the percentage of tasks added during the sprints is what we call deviation from scope.
If it’s a change dictated by the business need or customer feedback then it’s a good thing - after all, flexibility is one of the benefits of developing in Scrum. But, what if the project’s scope changes when it was supposed to stay the same?
The team could end up building something different from what the client was asking for. To prevent that we monitor our sprints and product release plans. Deviation from scope is another process metric that we track and include in our reports - just like product owner’s satisfaction, predictability, and others.
Team members change
Over the course of long partnerships, it’s natural to see people come and go. Some decide to move on to different projects, take a longer break from work, or take some time off to take care of their children. Whatever their reasons might be, we make sure that the change won’t affect the development of the client’s digital product. How do we do that?
We provide our client with new team members immediately. The entire process is transparent to the client, so they know our plan for getting a new person on board. Similarly, a team member that leaves the team goes through an offboarding process that allows us to collect all of their knowledge about the project. Whenever team members change, domain knowledge transfer is essential.
Managing the challenges of the long-running products - a summary
These are only some of the best practices that we implement for our clients. In most cases, responding to challenges was a matter of staying true to our values: transparency in communication and high standards in digital product development. But, as we live in a VUCA world, we can be sure that the future will throw some new challenges in our direction. When that happens, we’ll deal with them together - and learn new lessons along the way.
Share this article:
