Shorter times for delivering new software products and updated versions are more and more common. Higher speed can provide substantial business value, but only if adequate quality can be delivered. In this article, we explain how the need for speed impacts your software’s quality requirements and why development time and operation quality requirements need strong improvement. Guidelines outline the areas where investment is needed to make high quality happen at short time-to-market. Finally, we will discuss applicable factors for significantly reducing release times.
Some years ago, it was quite normal to deliver a new release once or twice a year, or in even longer intervals. Today, updates are often released many times a week, sometimes even every few seconds. Internet companies are clearly the leaders of fast releases (e.g., Amazon made changes to production on average every 11.6 seconds in 2011, and many Google services are released several times a week, but more traditional companies like car manufacturers delivering safety-relevant products are following suit (e.g., Volvo cars).
When we say short time-to-market, we actually mean two things, but the focus is on the second one (because it is more challenging):
- Delivering the first release within a short time between project start and first release
- Delivering frequent subsequent updated releases within short times between start of increment and release
The key reason for short time-to-market is getting value earlier:
- Customers can use your new features earlier – you can earn money earlier
- You are on the market faster than your competitors – you can earn more money
- You get faster feedback – you can further improve the software product or implement new feature requests from customers
- You provide small updates instead of large ones – you can reduce the risk of providing the wrong software and you can reduce friction in development
This motivation to achieve shorter time-to-market is clearly business-driven (as it aims at providing business value), it is no end in itself, and you have to clearly identify the objectives to be achieved. Jan Bosch states this in drastic terms:
“No efficiency improvement will outperform cycle time reduction.”
On the other hand, short time-to-market should normally not cannibalize the quality of the software system. High quality is important to convince customers of the value of the software product. Throwing a new product or release onto the market without proper quality assurance, documentation, etc. can speed up time-to-market, but it is not sustainable at all and thus not in the focus of this article (although it might be the right thing to do in exceptional cases).
Optimizing either delivery time or quality is challenging in itself. High quality at short time-to-market (HQ@STTM) is even more challenging, and not every company benefits equally from high-frequency releases, or would have to change too many things so that the investment would not be worth the benefit. So you should start asking the following questions, describing your goals:
- What are the key reasons in your market and for your product to release it with short time-to-market?
- What is a reasonable time-to-market that you want to achieve?
- What is the level of quality that should not be affected?
These business-related questions have to be answered roughly first, followed by technical and organizational questions aimed at realizing the identified goals and checking the feasibility of achieving these goals. Many new questions emerge when striving towards shorter time-to-market, e.g.:
- What does an efficient release process look like for you?
- What architecture do you need?
- What is the necessary infrastructure you have to provide?
- What is a reasonable team structure you have to create?
- What tools support your fast delivery?
In this blog article, we will give answers to the following questions about HQ@STTM:
- Why is HQ@STTM of any value at all? (see above)
- What exactly does high quality mean in this context?
- Where and how to invest for HQ@STTM?
- What is the applicability of HQ@STTM?
The following figure illustrates the answers and the transition towards HQ@STTM.
What exactly does high quality mean in this context?
The key reason why we build software is the functionality it realizes. However, only if this functionality comes with an adequate level of quality in the software is it actually useful. When we talk about HQ@STTM, we need a more precise understanding of high quality and thus distinguish four categories of quality characteristics of a software product (see Figure 1):
- Absence of bugs
- Runtime quality (e.g., performance, security)
- Devtime (development time) quality (e.g., maintainability, testability)
- Operation quality (e.g., updateability, recoverability).
The focus in development organizations is often on functionality, absence of bugs, and runtime qualities. This is quite natural because these quality characteristics are directly visible to the customer, while devtime quality and operation quality rather serve the development organization (in particular if it also operates the software). This is also backed by the ISTQB Worldwide Testing Practice Report from 2015 ), which revealed a focus on runtime qualities, such as performance, usability, or security.
If we talk about HQ@STTM, high quality thus also means absence of bugs and runtime quality. However, in order to be able to deliver these quality characteristics with high speed, it becomes inevitable to also increase devtime quality and operation quality!
- Devtime quality is necessary to allow making additions and changes quickly (maintainability, extensibility, flexibility, …) and testing the changes with a high level of confidence within a reasonable period of time (which necessarily implies a large degree of automated testing).
- Operation quality is necessary to enable reliable and fast releases with a high degree of automation and to quickly react to potential failures of the newly released software.
That is, the goal is to deliver absence of bugs and runtime quality to the customer, and the means for realizing this is to invest in devtime quality and operation quality. As functionality is available earlier, a slightly reduced amount of functionality might even be acceptable. Due to the ability to correct problems much faster than before, a bit more tolerance for bugs might exist. Figure 1 depicts this relationship. It is very important that all the people in a development organization have a clear picture of these different characteristics of quality and how they will change when they strive for more speed.
Where and how to invest regarding HQ@STTM?
HQ@STTM does not come for free. It is clearly a business value and a competitive advantage, and thus it is obvious that investments are needed. The previous section already pointed out two areas of quality that need strong improvement in order to realize HQ@STTM: devtime quality attributes and operation quality attributes.
In this section, we will broaden the view on areas of investment. We have identified four high-level areas that require investments in order to make HQ@STTM happen:
- Culture / Organization: The people in the development organization have to be fully aware that fast releases have value and that everyone has to contribute. Changes to the organizational structure might be necessary to empower people to develop and release fast.
- Architecture: The architecture of the software has to strongly support fast releases, that is, in particular the realization of development time and operation quality attributes (e.g., updateability, recoverability, testability, …) while maintaining the runtime quality attributes (e.g., performance, user experience, security, availability, …) at the same time.
- Tools / Automation: Automation is key for fast releases with high quality: Only if quality assurance, build, and release are highly automated and reliable can releases be made with high confidence at high frequency.
- Processes: Processes have to focus on full end-to-end coverage, from ideation of new features to putting them into production with low friction and delay.
The four areas that require investment are connected and overlap. In the following, we will provide more concrete topics and guidelines, which mostly touch several of these areas. (Take continuous delivery, for example: For continuous delivery, the software architecture has to cope with fast integration and deployment, and a full process needs to be defined with a high degree of automation.)
Concrete topics and guidelines supporting HQ@STTM:
- Focus on customer and business value:
- Focus on building the right software system that serves your customers and provides the highest value for your business.
- Build as little as necessary; building less takes less time.
- Consistently prioritize in requirements engineering.
- Incorporate early feedback and data to enable continuous adjustment.
- Focus on innovation and differentiation, use common features where possible:
- Do not reinvent the wheel; do not invest your time into things that are already there.
- Focus on the things that make your product and your business unique.
- Use cloud-based technologies where possible.
- Continuously renew: What is innovation today may be a common feature tomorrow.
- Optimize release capability
- Introduce continuous delivery, integration, and deployment for (partially) automated, and thus faster, releases.
- Adopt DevOps practices; they aim at assuring smooth interplay between development and operation throughout the release step.
- Design for updateability: provide the ability to run different software product versions; use effective API version management; migrate data; etc.
- Modularize software to enable independent releases of features and software parts: Microservices are an architectural style that proposes many decisions supporting decoupled development and releases.
- Make teams responsible for the development, release, and operation of their modules and create the ability to release independently (respect Conway’s law concerning the organizational structure).
- Invest into high quality:
- Do quality assurance early to avoid going in the wrong direction (prototyping, architecture evaluation, …).
- Try out concepts and features early with a strong customer focus.
- Design for high testability and, in particular, for a high degree of automated testing.
- Design for robustness: provide the ability to keep failures local and to recover quickly in the case of failures.
- Establish a culture of making even good things better over time.
- Make the overall development organization agile
- Establish a culture of speed and fast decisions.
- Follow agile development principles and be responsive.
- Utilize data to improve business and software
- Establish a culture of experimentation and learning, based on data and data expertise.
- Perform A/B tests, for example, to get early feedback about alternative features and about the quality by gradually delivering the software to the customers.
- Ask your users for (anonymous) feedback, respectively collect data from usage profiles and logging.
What is the applicability of HQ@STTM?
We believe that HQ@STTM will become more relevant for many industries and companies, as it offers a strong ability to create business value. HQ@STTM is nothing that can be bought out of the box. Rather, it is a deliberate business decision that comes with many consequences, changes, and investments. To make it happen, the company developing the software has to strongly adapt and invest into the areas of Culture/Organization, Architecture, Tools/Automation, and Processes.
The concrete manifestation differs from company to company, starting with different releases cycles and ending with the specific technologies being used. Such particular environmental factors have to be considered during the definition of a concrete migration and improvement strategy.
The following aspects have an impact on the applicability and the concrete definitions of HQ@STTM:
- Adherence to quality standards and certifications: Whether high release cycles are possible can be determined by regulations concerning quality assurance and certification.
- Customer expectations and ability to create value: Only if regular and fast updates are perceived to be accepted by customers and can result in business value are the investments into HQ@STTM justified.
- Status of existing software: The age and overall quality of your software (in particular devtime quality and operation quality) have an impact on whether it is advisable to invest in HQ@STTM for the current software (or rather do it for a successor).
- Control over execution environment: Companies offering software-as-a-service (SaaS) have the advantage that they have good control over the execution environment, while companies offering physical goods like cars might have to update their software in millions of hardware instances. However, even there, things might change as network capabilities are greatly improving, allowing more and more functions to be moved to a cloud-based environment.
If you want to move towards HQ@STTM, you should ask the following questions when you start your journey:
- What does “high quality” mean for you? How do you interpret “short” in terms of time-to-market?
- What is the respective improvement in value that you expect to gain?
- What does this direction mean for your organization, your processes, your architecture, and your tools?
- Which topics make the most sense to you to start with?
You should keep in mind that this is all about the balance between high quality and fast delivery, and you have to consider both and find the right balance. This means that it is about acceptable quality and acceptable release frequency. The guidelines presented in this article point out aspects to reason about, to prioritize, and to start introducing. They are deliberately not presented as a migration roadmap because your transition to HQ@STTM will be individual and thus requires your own individual migration roadmap.
If you feel the need for speed and want to speed up migration, don’t hesitate to contact us: We will be happy to discuss your challenges and potential solution strategies.
Recommended literature for further reading:
- Jan Bosch, „Speed, Data, and Ecosystems: Excelling in a Software-Driven World“
- Len Bass, Ingo Weber, Liming Zhu „DevOps: A Software Architect’s Perspective“