When delivering data & insights it is often tricky to combine predictable and robust development with innovation.
First off, for this article let’s just define Sustainable development vs Innovation. One can always argue that there is Innovation in predictable development as well, but in this case we will separate the two in the manner below:
Sustainable development is development done to be used in production, it comes from a prioritized backlog and is planned in a normal sprint manner. Typically it is a new or changed product feature.
Innovation can be many things, but in this context we will focus on two main types of projects. The first is a typical data science project where the business problem is known but the solution is not known so a very fast iterative process is necessary in order to try and validate different solutions. The second is support to a larger business innovation project where the collaboration consists of both providing data but also predicting and analyzing outcome.
It is very tempting to put all of your organization into product teams and then assign the capacity of those teams to the product backlogs.
What you may miss out on in that case is the ability to handle the projects that are difficult to put into the backlog or that go across product areas.
Reversely there is a large risk for decelerating agility and speed if you put all your efforts into building projects as stand-alone use cases with no long-term vision.
There are several solutions to this problem, here I will propose two alternate solutions:
- Capacity planning: Safeguard a percentage of each teams capacity and spend that on innovation projects. This will require that the product team has two separate areas of responsibility: A well-defined product scope and a business domain responsibility. The drawback of this method is the risk of context switching when team members needs to work on both product features and an innovation project at the same time, there may also emerge a risk of prioritization issues.
- Different teams: Set up specific team(s) to handle the innovation projects, these can be virtual teams set up for this particular project. This will require that the team works well together with all other teams in building and refactoring the long-term solution once the project is drawing to a close. The drawback of this method is that once the project is over the solution needs to be refactored into the long-term solution and adhere to all standards and frameworks, with the proper frameworks this should be a minor issue.
As mentioned above, there is not one perfect solution. I personally like to combine the solution #2 above with people rotation between product teams and Ad-hoc/Innovation teams.
The most important part is to think both Innovation and Sustainable development and never allow an innovation project to hand-over technical debt to a product team.