At Signavio, we strive to continuously improve our products at the fastest possible pace while avoiding quality regression and keeping our program code and architecture clean and well-structured. That’s why we follow an agile, iterative software development approach, which has the following implications that are directly visible to our customers:
- We make improvements to our available products at a faster pace than traditional enterprise software is rolled out.
- New features are often released in several steps. The initial release of a new feature often includes minimally-viable functionality, which is extended later.
For some of our customers, who are used to working with traditional on-premises enterprise software, this approach can be confusing or even irritating. Such customers expect less frequent releases that are then major events and require comprehensive preparation from their side. Such releases are common for software that is developed with a waterfall-like development approach. Updates are shipped infrequently, i.e., ‘roughly twice a year’, and contain comprehensive changes, which typically are hard to keep track of and often rapidly change existing behavior. Because of their complexity, such updates are prone to contain breaking changes that impede operations.
Consequently, people who are used to “waterfall” software releases are concerned that any update could impede their business operations and thus request comprehensive release notes prior to the release and the possibility to conduct their own manual tests before a release goes live.
In this article, we briefly address these concerns and explain why we are confident our iterative development approach helps deliver the greatest possible value to our customers.
Why iterative software development is better for us and our customers
Iterative software development is more than just a buzzword; for us, it comes with far-reaching, practical benefits.
Better software quality
Shipping small sets of changes reduces the likelihood that critical bugs aren’t detected by the quality assurance process because it forces developers to divide their work into small, well-defined units instead of big, uncontrollable chunks. Moreover, bugs that make it to production are detected before additional program behavior is implemented on top of them. Of course, we can make mistakes and ship bugs from time to time. But our iterative development approach allows us to decrease the amount and - even more importantly, the severity - of bugs that make it into our releases while keeping the quality assurance costs under control. This also reduces the time needed to fix a bug if one occurs.
Faster delivery of implemented changes
Short release cycles allow us to release a feature as soon as it can solve a customer’s problem and implement further improvements, i.e., to optimize the user experience, later. This helps our customers - especially power users - to address the core challenge a feature solves as soon as possible and to provide feedback early on, which helps us to better tailor our products to the needs of our customers.
While some features might not be optimal after their initial release, they do provide value to at least some customers from day one. Shipping a minimaly-viable feature is typically better than shipping no feature at all. And if a feature is not minimally viable, we decide not to ship it. In contrast to traditional software releases, our releases contain breaking changes only in exceptional cases that we announce prominently prior to the release. All other release notes are published at the time of the release.
Increased development efficiency
Dividing development work into small deliverables that are shipped as soon as possible decreases the risk of miscommunication and misspecification. A real-world feature is always different from the initial sketch on the drawing board. A traditional development process starts with a long specification phase that is expected to produce a reality-proof result. In practice, the more complex the initial specification, the less likely that it is accurate. In contrast, frequent releases force the development team to expose their work to reality much sooner, helping sort out misspecifications early on and making it easier to respond to change requests.
Continuous improvement
We aren’t the only company that observes these benefits. It’s established consensus that iterative software development is the best possible approach the software industry developed. Of course, we are continuously working on improvements of our release and quality assurance processes to further facilitate product quality and customer experience. If you have any questions about our release and development approach, contact the Signavio Support Team at support@signavio.com.
Release frequency and further information
At Signavio, we release product updates on our software-as-a-service systems with a relatively high frequency:
- SAP Signavio Process Manager and SAP Signavio Collaboration Hub receive updates every three weeks.
- We typically update Signavio Process Governance every Monday.
- We deploy changes to SAP Signavio Process Intelligence continuously, with a rolling release approach on a daily to weekly basis.
- We provide quarterly releases of the on-premises versions of our software.
- Important bug fixes are released ad hoc, as soon as possible.
In the future, we plan to continuously increase the release frequency for our software-as-a-service products, so that we can deliver features and bug fixes even sooner and further increase the efficiency of our software development teams.
You can find our release notes at https://www.signavio.com/release-notes/.
Follow @Signavio on Twitter to receive notifications about all Signavio product releases.