Why do we need agile?

Before we discuss the results and advantages of combining agile programming with a team operating within the DevOps methodology, it is advisable to shed some light on how software development has been conducted in the past. Even the remote ones, as primarily, the shortcomings and challenges of the former methodologies resulted in the growing interest in their successors.

For entire decades, the waterfall model has been the most popular software development model, popularised already in the 1970s. The model assumes that each of operations related to software development is executed separately, one after another – the ability to conduct works on different levels of software development simultaneously was out of the question.

The project would begin with project planning based on requirements specifications, followed by the analysis of requirements and a feasibility study. The following stage in waterfall was focused on software design, which then passed on to code development. Afterwards, tests and implementations would commence, whereas the entire process ended in code perfection.

Already, using the example of such sketchy model outline, one may see, that the waterfall model had its limitations, that cannot be omitted. Primarily, it isn’t very flexible, or, to be more precise – is not flexible at all – passing to subsequent phases of production would always require completing the former ones. Software created once, cannot fluently return to any phase, and it is necessary, to travel the entire cascade again, which burns through an enormous amount of resources, particularly time.

However, that is not the only result – within the waterfall model, the only moment during which the software is being tested, is a separate phase, dedicated to this very purpose, and final.

No one checks the rectitude of application functioning during the subsequent phases of development; it is also difficult to allow the QA to stretch over longer periods of time, as it often has strict time frame, which enforces compromise. Still, it was not this aspect, that contributed the most, to the gradual resigning from waterfall, but rather, the necessity of responding to the changing needs of the customer.

Obviously, one cannot state that waterfall is a bust – quite the contrary, it may be an optimal model, when the specification includes clear needs and project frameworks, where there is no doubt, that they will remain unchanged. In other cases however, one must consider the dynamics of the software development project, the necessity of responding to new needs and adapting code to the changing reality.

Exactly, this aspect had become the main impulse for popularising the agile methodology (also agile outsourcing), which, being an incremental-iterative model, was basically designed for allowing to conduct works in a more flexible, dynamic way. All this to respond to the changing realities more swiftly.

The agile era

It is worth examining, how the theoretical ramifications were formulated in the 2001 „Manifesto for agile software development”, a work which constituted the first codification of the new methodology, and how they translate to the practice of software development.

Contrary to the skeptical approach towards the software engineering theory, it is not an art for art’s sake or form over content, but specific actions with far-fetched results, that have direct impact on the quality of software, as well as, resource use – time, funds, and workforce capacity of the development team. No one can allow to waste them, obviously.

On the theoretical level, the agile manifesto presents four key premises. The first, is to focus on the collaboration of people, which is primary over the technical aspects of the processes. It is somewhat of an answer to the strict, framework waterfall model which – even if the necessity was obvious – did not allow the possibility to work within many stages at once, or coming back to the previous stage of production. In terms of agile, it is exactly the agreements between specific team members, as well as, the team and the customer, that play the primary role in e.g. the selection of tools and frameworks.

In result, instead of the cascade model, we are dealing with an iterative approach – initially, the general outline of the solution is agreed upon (instead of the end result, strictly defined by specifications), which can later be modified and adjusted to newly identified needs.

Work is commenced using small modules, and only in the course of works, aspects are defined, which are treated as priorities, however, they still may be subject to change. During each phase, tests are to be performed, which directly translates to software quality, similar, as one may collaborate with the customer on shaping the software, contrary to the strict agreements included in the specification. The fourth premise is to focus on reacting to change, that may turn the project much more flexible than in the waterfall model.

Differences within the iterative-incremental model, are therefore colossal in comparison to the cascade model. However, how does this theory translate into practice? Primarily, software development becomes a continual process, and the subsequent versions of software are released often and on a regular basis.

It is not about publishing subsequent large updates, that introduce large functional improvements, but about continual ensuring of the end users, with a dynamic development process using the often published point releases. Even if issues occur, they may be corrected immediately, as well as, the functionality may be adapted dynamically to the current needs. To make it possible it is necessary to implement adequate organisation of programming teams.

What is DevOps, and what it is not?

The DevOps methodology had emerged in direct connection to the popularisation of agile methodologies of software development. Let us answer the question, what is the DevOps methodology currently, what are the directions of its implementation, as well as, what are the misunderstandings or myths that have arose around DevOps through the years.

Developer roles worldwide:

It is mostly a work culture, rather than an assortment of features, skills or any other competencies related to an employee. The erroneous perception of the DevOps model results in the fact, that the team members are expected to know something about everything, rather than know everything about something, and it would be best, if they knew everything about everything in general.

However, that has little to do with the work culture established by the DevOps model – it is based on cooperation and information exchange between the team members, so that they could mutually learn about the progress of work on particular aspects, know their capabilities and limitation, and would be able to adjust their field of operation to them.

It is a model strictly adjusted to agile methodologies of software development. There is no division into particular phases of the project, no limitations regarding the dynamic change of development direction, no isolated processes or modules. The team working within the DevOps model is primarily focused on the information flow between people, mutual supplementation with the focus on product awareness, possessed by particular experts.

Here, we see the reflection of the theoretical agile premises – the focus on communication between people and dynamic adaptation to the changing reality, rather than strictly following a given path, that has a particular, clear goal.

Currently, it is difficult to execute the agile methodology without the DevOps work culture. It is particularly visible during the period of offering software as a service, when continuous delivery is a priority.