The magic of fast software delivery
Unpredictable events, such as the pandemic, can require rapid market launches and short-term adjustments to a company's product to meet new market conditions and customer needs. Those companies that lack the ability to react to changes in their markets quickly fall behind: Projects take twice as long and become three times as expensive as initially expected, despite thorough planning and agile methodologies in place. Software only reaches market readiness after months of development - while still riddled with bugs. The market - and with it the competition - seems to be twice as fast as your own organisation. The market pressure is enormous. Does that sound familiar? Frustrating isn’t it?
Why do some companies manage to develop and deploy software faster than others - with significantly better software quality? A closer look at the historical development in software engineering practices delivers some valuable insights: repeatedly, there have been some breakthroughs, with drastic reductions in average software development. Thanks to the agile software development movement in the early 2000s for instance, things suddenly took only months rather than years until market deployment. With the widespread adoption of cloud technologies starting in the 2010s, we're seeing deployment cycle times drop from 6 months to just a few weeks.
However, when it comes to software deployment frequency, for quite a few organisations, there is still a significant gap between wishful thinking and the hard reality. Why isn't your own company able to speedboat ahead despite the availability of cloud technologies and agile practices? And why does your competition manage to fly at warp speed, adapting to market changes, customer feedback, whilst developing and deploying features in super short cycles - without bugs?
Is it because your own developers are not good enough? You don’t have 10x rock star ninja developers on your team? Are there too few people working on the project? Is the legacy system that bad?
Rest assured: It's not the developers, nor is it the legacy systems. In the vast majority of cases, it simply comes down to the wrong approach to development processes, or oftentimes the literal application of agile methods.
Almost every company today uses agile methods in software development. However, these methods are not always truly understood. We observe time and again that Scrum is applied rigidly - almost biblically - adhering to the rule set, without appreciating the underlying mindset. This leads to ceremony becoming more important than results. In other cases Scrum methods like stand-ups are combined with traditional waterfall models: Large projects are planned and executed in phases, with each individual phase building on each other and proceeding in a fixed sequence. Particularly larger, traditional companies with strong hierarchies tend to follow the waterfall model.
The method is not the goal; it is a resource to achieve the goal. Sprints and stand-ups alone do not magically turn organisations agile. Companies must evolve their team and communication structures in ways that enable agile processes in the first place. Conway's law states: the communication structure of an organisation is always structurally reflected in the systems it develops. This relationship between the characteristics of an organisation and the architecture of the product they create has been proven in numerous studies. In order to achieve true agility and develop and deploy products as quickly and bug-free as possible, companies must design their team and organisational structures in a way that allows the development team fast feedback loops and the greatest possible scope for action.
This can only be achieved with the DevOps mindset and the "Team First" approach: The engineering team must be empowered to organise itself - and it needs to include all skills and roles required to develop (dev) and run (ops) the product - the mantra “you build it, you run it” applies.
Naturally, depending on the industry, there are fixed points that the team must take into account during the development process, such as compliance and security aspects. Apart from that, however, the team must be able to independently decide, according to the best-practice approach, which elements of a product are built in which way and in which order. This helps avoid situations when teams work around rigid architecture, organisational constraints and baked-in specifications rather than finding practical solutions for a desired feature.
The second pillar of modern agile software development is rapid feedback as well as continuous, test-driven deployment, and frequent and constant delivery of code in incrementally small steps. Unlike traditional methods, in which code is only deployed after months of development , deployments to production are now performed every hour or even every minute. The prerequisite for this is a stable and automated development and testing infrastructure that allows the team to continuously test the product and directly implement the feedback gained into the development process. This method not only increases the speed at which software can be delivered, but also has a significant impact on its quality. Through test-driven development, the smallest errors in the code can be immediately detected and corrected by the team. Software products and features developed in this way not only reach market readiness much faster, they are also significantly more stable, reliable and safe.
If you want to keep pace with rapid market changes and stay one step ahead of the competition, there's no getting around the DevOps mindset. No surprise that this approach has gained enormous popularity in recent years. Stand-ups and sprints alone are not enough to enable fast flow delivery from development to deployment. It also requires the right organisational structure that enables the development team to self-organise, respond quickly to feedback, and deliver software updates in frequent and small increments.
The good news is that any company and any team can be organised and trained to leverage the full potential of the DevOps approach and cloud technologies. But as challenging as this may sound, it also means rethinking and saying goodbye to old familiar methods.