Regarding the multitude of agile software development techniques, I personally tend to make a note. Some managers may overlook the fact that software actually has to be developed by programming a computer, whereas the actual programming never is the object of the developing techniques. These merely focus on the managing of the developing of software. As a consequence the developing of the software in itself can sometimes be an issue that is not sufficiently addressed. In my opinion, it is to be noted that the actual programming can be a time-consuming task including many challenges.
Throughout the years software developing has become an ever more complex task to perform. Today’s software architecture has many layers (three-tier to seven-tier) and has to be implemented on a multitude of clients such as smartphones on Android, Tablets and dedicated professional devices such as barcode readers.
Servers too get ever more complex. In my opinion, the different existing agile methodologies fail to address issues related to complex databases. The possibilities offered by today’s Oracle servers really outperform the database servers of some 15 years ago.
In the early days of software development the actual deploying tended to be rather easy. The programmer could copy the software directly from his developing device to the platform that would take part in the production process. Personally I remember the many discussions in the year of 2009 that I had with contracted professionals who argued that the fact to have to develop their software on a developing platform was a mere waste of time since a month later, after passing the testing phase, it would be implemented directly on the production platform anyway. Why not directly programming in the production environment, so I was told, which at the time was so much less time-consuming.
Luckily, nowadays developing lanes have become mainstream. When wanting to apply Scrum, as a software architect one can only organize sprints of maximum one month’s work. That sprint will then have to deliver a “potentially releasable increment of product” : a fully completed functionality that has undergone full testing to the level required for implementation in the production process. And all that in a few weeks time.