Most groups attribute delays in launching new products or features to development. This is often a misguided  attribution. By the point at which a feature gets onto a sprint board, much damage has already occurred. The  damage only crops up when the deadline fails and someone then inquires why the engineering team needed so  long. 

Where the time actually gets lost is in the earliest phases of development: in the case of specifications that have  undergone the rewriting process two times before the writing team starts programming and design handoffs that  have been lying unattended in someone’s inbox for weeks, as well as quality control processes that kick off only  

after the development has been completed. All of this does have a negative impact on the launch date of a  project. 

The answer for all of this is dual-track agile development. This means that discovery and execution should  happen at the same time rather than subsequent to each other, but for many teams this solution remains far from  obvious. 

In croncode, a number of apps such as Numira, YourStyle, and Spylie are running simultaneously and  consequently, the situation calls for a certain level of organization. A product team can afford to have its work  done sequentially because the focus is on the same set of people and no other project needs to benefit from their  attention. However, this does not help teams that work on multiple products. If the design team spends a week  on completing the tasks for one particular product, the team responsible for the second product will not be able  to benefit from this attention during this week. This can be achieved only with the help of understanding who is  responsible for which product and being able to coordinate collaboratio in such a way that the responsibilities  are clear enough, but at the same time there is no need to create any complicated organizations of the processes  taking place. 

The trade-off that people often shy away from discussing is speed versus technical debt. Getting new products to  market quickly implies taking shortcuts, which will ultimately add up. However, companies that are able to  maintain that speed over the long term are not the ones who continually cut corners – they are the ones who  make paying off technical debt part of their business strategy, rather than something they are surprised by and  completes a massive rewrite in 18 months. 

A surprisingly simple way to determine what work should happen first is to actually ask the question – does this  work remove a blockage, or does it create a new decision further down the line? Use this simple guide, because  work that removes a blockage stops everything else from happening.