Hyper Agile

Manifesto for agile software development^[1] in 2001 was a milestone in the production of information systems.

Reflecting the growing concern about the poor service provided by the software to its customers, some of the most conscientious voices of information technology formulated, in four lines, propositions that inverted everything that was previously considered irrefutable, and stated that they preferred to choose

• People and interactions instead of processes and tools.
• Functional software instead of detailed documentation.
• Collaboration with the client instead of contract negotiation.
• Response to change rather than the fulfillment of a plan.

A set of additional principles elucidated the consequences of this perspective.

Almost two decades past, the balance is mixed. There are many good experiences, but agile development is not yet widely applied. The iterative process is no longer used other than the alternative, the classic waterfall. “Already Agile” often means having a small Agile project, while most projects follow the linear and sequential decomposition of waterfall: requirements> design> development> tests> installation. It is also common, when something starts to run less well on a project, that teams (and clients) take refuge in waterfall practices. If the promises of Agile are not fulfilled, the tendency is to look for shelter in the old techniques.

However, these are outdated due to the rapid change of paradigms. These days, we have seen cases where the software before it is finished is already obsolete and it is already known that it will not respond to the needs of the client. Reality and needs change nowadays faster than software development when this is accomplished by the waterfall methodology.

On the other hand, agile development became the Agile methodology and, to some extent, bureaucratized. The notion of the goal is often lost, the medium is identified as the ultimate goal^[2]. Alistair Cockburn, one of the subscribers of the manifesto, complained, at the ScrumDay held in Lisbon^[3] in 2017, of this effect. The certification (of two days) of scrum masters and the identification of product-owners does not guarantee, in any way, the success of the projects.

Software success is not just a question of methodology. Following an Agile methodology, as the recent Lidl case demonstrates^[4], can also lead to a disaster. And it may even be more difficult and time-consuming (and therefore more expensive) to declare an agile project as failed. It is essential that this agility is already a technical feature of the software used for development, which, in Lidl, was not the case.

The software inspires other areas of management and we must follow BBVA’s project of changing its organization, strategy and (more difficult) its culture with the goal of “More than 30,000 people working” agile “in 2018 “^[5].

Quidgest contribution

Almost two decades later, we must demand more from Agile.

Software development will not become agile (faster) as long as code writing is performed by humans at a writing rate of 2 characters per second and yet subject to natural human errors, sometimes quite difficult to detect, even with the practice of peer-reviewing.

It also does not become agile or faster if it applies to a traditional standard software configuration. These configurations are manipulated by the standard component (an untouchable black box), which has similar agility to concrete. In this case, talking about reconciling Agile and a traditional standard ERP, for example, is just fooling the customer^[6].

The gains made simply by reorganizing teams and tasks (ie Agile not supported by code generation automation) are limited and confined to small, short-lived, short-lived projects developed by relatively small teams.

The reality is that Agile is limited^[7], and to overcome these weaknesses and apply the lessons learned where it was not as successful as it might have been, Scaled Agile^[8] (now SAFe 4.5) has emerged. This methodology incorporates a set of concerns related to higher levels of complexity and concurrent project portfolios while integrating Lean IT concepts.

Quidgest is a proud advocate of Agile and Scaled Agile, but has been contributing in raising these methodologies to another level of effectiveness.

Quidgest’s decisive contributions to Hyper Agile are

• Automation: By jumping from 2 to 1,000,000 characters written per second, and without errors.
• modeling: what means control at a higher level of abstraction, high-level representation and an explanation of the architecture of the information system;
• Team efficiency: With the skills integrated into Genio teams are smaller, there is very high reuse of standards and much less direct work for each project;
• Reduction of software production cycles: for just a few hours;
• Communication and interaction with the business: it is easy to communicate and reflect at the model level, a task that is impossible at the code level, since programming languages ​​(whatever they are) are not the appropriate way to design software or to talk to CEOs or key users.

[1] http://agilemanifesto.org/
[2] An interesting position https://www.lambdacambridge.com/blog/2018-05-how-scrum-destroyed-agile
[3] Experience Agile https://www.experienceagile.org/
[4] https://www.consultancy.uk/news/18243/lidl-cancels-sap-introduction-having-sunk-500-million-into-it the proposed methodology was intended to be agile: https://www.kps.com/en.kps-transformation.html/article-2203-unternehmen-der-unterschied
[5] https://www.bbva.com/en/bbvas-journey-becoming-agile-organization/
[7]For example, the limitations of the Scrum application were well documented in the first article on the subject, “The New New Product Development Game”, from Hirotaka Takeuchi and Ikujiro Nonaka, Harvard Business Review, January 1986, long before the term was taken advantage of by agile software production.
[8] https://www.scaledagileframework.com/