Maximize your organization’s potential
The manifesto for Agile software development in 2001 was a milestone in the production of information systems.
Reflecting the growing concern about the poor service provided by software to its customers, some of the most conscientious voices of information technology formed, in four lines, propositions that inverted everything that was previously considered irrefutable, and decided to choose:
- People and interactions rather than processes and tools.
- Functional software instead of detailed documentation.
- Collaboration with the client instead of contract negotiation.
- Response to change rather than compliance with a plan.
A number of additional principles clearly elucidated the consequences of this perspective.
After two decades, there are mixed results. There are many good experiences, but agile development is not yet widely applied. The iterative process is still not more common than the alternative, classic waterfall. “We are already Agile” often means having a small Agile project, while most projects follow the linear and sequential decomposition of waterfall: requirements> design> development> testing> installation. When things do not run as expected, is common that teams (and clients) shelter in waterfall practices. If Agile promises are not accomplished, the trend is to turn to old techniques.
However, these are clearly outdated. Due to how rapidly change of paradigms these days we have seen cases where the software is already obsolete before it is finished and will no longer respond to the needs of the client. Reality and needs change faster than software development when it is performed with the waterfall methodology.
On the other hand, agile development became the Agile methodology and, to some extent, was bureaucratized. The notion of the goal is often lost; with being identified as the ultimate goal. Alistair Cockburn, one of the subscribers of the manifesto complained about this effect at the ScrumDay, hold in Lisbon 2017. The two-day certification of scrum masters and identification of product owners does not guarantee the success of projects at all.
The success of software is not only a matter of methodology. Follow an Agile methodology, as the recent case with Lidl shows, can lead to a disaster. It can be even harder and slower (and, thus, more expensive) to declare an agile project as failed. It is essential that agility is already a technical feature of the software used to develop, which, for Lidl, was not the case.
The software inspires other areas of management, we need to close follow up on BBVA project to change their organization, strategy and (even more difficult) their culture with the objective “More than 30,000 people working “agile” in 2018”.
After 2 decades it is time to demand more from Agile.
Software development will not become more agile (faster) while code is still typed by humans at a rate of 2 characters per second and prone to human errors difficult to detect, even with peer-reviewing.
The gains obtained just to reorganize teams and tasks (Agile is not supported by code generation automation) are limited and are limited to small-scoped, short and simple projects, developed by very small teams.
Agile has limitations, and, in order to overcome those fragilities applying the learned lessons, Scaled Agile originated (now in SAFe 4.5 verison). This methodology incorporates a set of concerns related with more elevated levels of complexity and simultaneous projects portfolios, at the same time incorporating Lean IT concepts.
Quidgest is a proud advocate of Agile and Scaled Agile, and has contributed to elevate those methodologies to a higher level of efficiency.
The decisive contributions of Quidgest to Hype Agile:
- the automation (skipping from 2 character per second to 1 million of characters written per second, without errors)
- modeling (control at an even more elevated abstraction level, high level representation and making explicit the system’s architecture)
- team efficiency (integrating skills with Genio allows for much smaller teams, reusing of patterns and less direct work for each project)
- reduction of software production cycles (only a few hours)
- communication and interaction with business, (making easy to communicate and reflect at model level, difficult task at code level programming languages are not the right way of conceiving software solutions or speak to CEO or key-users).
 An interesting position https://www.lambdacambridge.com/blog/2018-05-how-scrum-destroyed-agile
 Experience Agile https://www.experienceagile.org/
 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
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.