Make no mistake, most organizations and government agencies are—at least in part—software companies. The backbone of the services and products they sell, the internal business processes they use, and the customer feedback mechanisms they rely on are all built on software. Even in the age of software as a service (SaaS) – a modern organization’s portfolio of applications and the specifics of how these apps are used influence its most important decisions.
So while it’s easy to understand that software is a foundational component to modern business, often the decision to invest in building or offering software to users must also be accompanied by a more specific, anticipated return on that investment. That process can go like this:
1) The organization plans a new feature (or product) that will earn revenue directly or make their business more efficient.
2) The organization quantifies the investment that will be needed, and the expected return on that investment.
3) The organization commits time and money to building a new feature (or new software product).
4) Customers pay for the use of this software directly, or in the case of internal applications, through their time spent using the software.
5) Organizations then start to realize the anticipated return on the investment.
But here’s the rub: This investment can only deliver on that anticipated return once it is in the hands of users. The total time from the beginning of step 1 through step 5 above is known is the “cycle time” – essentially the time between the organization’s decision to offer a feature until that feature is actually being used. Cycle time delays should be seen as an opportunity cost – an organization is giving up that return for the period that it takes to actually deliver the feature. Businesses that can minimize cycle time while still keeping quality high can claim a competitive advantage in their respective market.
Frankly, to compete today, applications need far faster development, test, and release cycles than ever before. In addition, growing customer expectations demand a high level of quality to compete in virtually every modern market. This is where the idea of adopting “lean” delivery processes can help. The lean methodology combines the principles of agile development and DevOps for rapid, reliable results.
Source: Gartner (September 2016)
Agile software development is fairly mainstream at this point. The evolution from waterfall-based processes to Scrum, Kanban, and hybrid agile development processes continues to progress. When implemented with discipline and given the appropriate amount of commitment, the move to incremental agile development processes has proven valuable. A lot has been written on agile development (including right here on the AIS blog), and on specific approaches for adopting agile in software development projects.
As for DevOps, again much has been written on the subject, and it seems like “everyone” is talking about it. But a universal understanding of what DevOps should look like and how it should be implemented has been fairly elusive. Sure, shifting the culture to improve collaboration between developers, operations, and business folks would be great, but this alone can’t be the end goal. Where’s the return?
There is one thing we know for sure; it is no longer acceptable to develop software in rapid, agile sprints only to use traditional release processes that force new features or bug fixes to sit on the shelf. Given ever-increasing market competition, the opportunity cost is just too high – and agile development is only a part of the solution. DevOps must contribute to the effort to reduce cycle time, improve the quality of the software, or both in order to justify the investment.[pullquote]There is one thing we know for sure; it is no longer acceptable to develop software in rapid, agile sprints only to use traditional release processes that force new features or bug fixes to sit on the shelf.[/pullquote]
One approach to optimizing DevOps processes is to organize around the goal of continuous delivery. The continuous delivery model aims to automate all processes involved in delivering software to production so that releases are incremental, frequent, routine, and can be performed on demand. Continuous delivery can help to minimize the cycle time opportunity cost by delivering valuable software as quickly as possible.
Lastly, software releases can be tense, dicey events. In cases where software is deployed manually, production conditions have not been accurately simulated, or production environments are manually configured, too often errors and problems creep in from unexpected places. A highly functioning continuous delivery model minimizes the risk of introducing crippling bugs while allowing for frequent updates to the users’ set of features.
Top Image Copyright: paunovic / 123RF Stock Photo
