Time-to-market is the current credo of all marketing departments and investors. In the past, in the last century, the more complex, the better, the more sophisticated the functionalities. Then, the credo turned towards the millennium’s usability, design and device compatibility. And now, it’s time to market, which doesn’t mean that the previous challenges no longer play a role.
However, when organizations decide what guides them in developing a product, it is increasingly less about pleasing the customer and more about the competition breathing down their necks.
Here you’ll get the WSJF Calculator Excel Template and an easy step-by-step Guide.
Of course, it is no surprise that this impacts product development organizations. For example, look at the insane race of companies involved in developing a vaccine for Covid-19, for instance, in the non-IT sector.
Some countries like to shorten the testing and certification procedures for this as if human lives were not at stake.
Time-to-market isn’t just a nice-to-have, it often decisive for a company’s survival.
And when you see the unearthly investment costs for developing vaccines or for developing electromobility, it’s pretty understandable. Innovations are becoming more and more expensive, needing more and more technology and resources.
These are also reasons why time-to-market is becoming more and more critical. Disruptive technologies are lurking around every corner and threaten our cherished market players, i.e. competition is becoming more confusing. Another driver of time-to-market challenges.
It is, therefore, not surprising that agile methods come into play in many organizations in project and product development. What is more surprising is that many do not recognize the connection between time-to-market requirements and the use of agile methods, although it is very evident when looking at it more closely.
Time-to-market requirements were not the only trigger for this “agile revolution”.
Along with the rapidly increasing complexity of products and the interconnectedness of products. Alternatively, production methods are one of three essential factors, without claiming to be exhaustive.
Agile project management must rise to this challenge. The expectation to occupy the market quickly is expressed to the development departments in demand for a so-called MVP – minimum viable product and is often formulated like this:
If we can’t bring something to market within six months, we don’t even need to start. A competitor will then do it for us.
If we look again at the development of the Covid19 vaccine, this becomes very clear. Around April 2020 – when it was foreseeable that Covid19 would be a pandemic, that it would claim many victims and that there would be a multi-billion market for it – various laboratories and companies began development. Then, almost six months later, the first one threw its hat into the ring.
Russia announced the approval of a vaccine bypassing the usual 3rd test phase. Donald Trump had also announced a vaccine for November 2020, purely by coincidence; it was the US elections. Do we need better proof of the above, namely that time-to-market overrules everything else? We see this everywhere today.
However, let’s get back to agile project management because this article is not just about describing and lamenting the problem but offering a concrete and practical solution.
How does agile project management help organizations shorten time-to-market cycles?
As we have already indicated, by bringing an MVP into play, agile project management will not – and this is a common misconception – speed up the development of software in the sense that development teams can now programme faster.
This may well be the case compared to the past, but it is more due to frameworks, CI pipelines, and other technical achievements. As a result, the approach of agile project management is different – and that’s what the MVP example is for – because only, e.g. 20% faster development would not get us there.
Agile project management and the agile development method aim for vertical, i.e. feature-oriented development – which is the essential difference between classic project management and the classic development method (waterfall).
This makes the definition of an MVP and the subsequent step-by-step development into a full version possible in the first place. But developing such an MVP is not that easy.
Let’s imagine we have a brainstorming session with all the technical, legal, strategy, marketing and “you name it” departments and collect all the use cases and feature ideas. And now, we are supposed to select a handful of these great ideas that we can turn into a marketable product in three to six months.
Each department sees its features as vital: “without this, we can’t go live…”. And that’s a good thing because the departments are supposed to “burn” for their product features as stakeholders. Nevertheless, a compromise is needed. And agile project management would not be agile project management if it did not have a solution in the form of a simple but effective process.
A product that the user may not yet love but that at least arouses curiosity and does not completely blow our minds. How do we decide which features to choose and how to implement them concretely into the product?
In our product Scagile – an all-in-one tool for scaled agile project management – we have incorporated this method and tested it in various projects.
The process is not new and is even much older than agile project management.
It is also recommended by the SAFe authors and plays a significant role in the SAFe method.
The method is WSJF – weighted shortest job first and will not be described in detail here.
We focus on how it can help shorten time-to-market in agile project management by helping to prioritize features and thus plan an MVP and all subsequent phases.
In short, the method is based on the idea that it would be beneficial to develop first the features that are very valuable and, at the same time, require little effort. But, of course, both attributes rarely coincide in one part. Otherwise, it would be easy.
WSJF calculates an index from the so-called “Cost of Delay” – what does it cost me not to get this feature or to get it late and the so-called “Job size,” i.e. the effort. In turn, the “cost of delay” comprises three factors: the business value, the time criticality and the risk reduction or opportunity enablement.
The advantage of this method lies, on the one hand, in its simple application, but above all, in the fact that a feature is evaluated from at least four perspectives. For the final prioritization, a fifth dimension, namely dependencies between the attributes, will have to be added, but we do not need to describe this separately for obvious reasons.
The business departments mainly represent the business value, time criticality often by legal or compliance departments (e.g. implementation of DSGVO), risk reduction/opportunity enablement often by marketing or strategic management (e.g. keyword disruptive technologies) and finally, the job size by the IT departments.
The latter now actually enjoy the benefit of being involved in the prioritization of features at an early stage through their input instead of being – as is very often seen – only the executive body or, as someone just told me, the programming menials.
This promotes the intensive communication and mutual appreciation important in agile project management, a Dev-Ops culture or the much-vaunted agile mindset.
Prioritization can now take place along the calculated WSJF index. For example, all features with an index greater than x can be included in the MVP, or all features in the order until six months have passed, but at least the first 7. Of course, we must still take any dependencies into account.
We use a Kanban board with the statuses Funnel, Analyzing, Backlog, in Progress and Done for the process. That’s all it takes to cover the entire demand process to implementation.
The WSJF method represents the Analyzing step. After the decision for the MVP epics has been made, they go into the Product Backlog and are prepared for implementation. This means that they are now under the control of the product owners or Scrum teams.
Agile project management thus begins long before product owners and Scrum teams come into play or assess the job size. They are already involved in the early phase of demand management. In many organizations, “agile” only starts in the implementation phase.
However, agile is not a project but an organization.
The advantage of proper agile project management lies in that, and firstly, IT is also seen as a stakeholder; thus, the value creation process is thought of end-to-end.
And secondly, it brings all the stakeholders together in such a way that they accompany the entire value-creation process through all phases. As a result, feedback can be generated quickly and responded to quickly. This is what accelerates the time-to-market.
Here you’ll get the WSJF Calculator Excel Template and an easy step-by-step Guide.
Why we should not mix agile and classical project management – or why traffic lights are not helpful at roundabouts.
Badly written, but above all incomplete User Stories are one of the most frequent reasons for the failure of Scrum projects. Read here how to write a good User Story.
Scrum vs. Waterfall – For all Scrum fans, let’s get the bad news out of the way: Scrum is just a compromise. The good news is that this is the only piece of bad news.
For scaled agile organizations it is frustrating when their project management tools don’t support their processes.
That’s why we developed scagile as an app which actively supports agile best-practices with features you haven’t even thought about and with which you’ll be able to create value flow across your entire organization.
