Why do teams that work in a mainframe environment barely use an agile working methodology?
What are the key factors of not doing this despite all the technology available?
If so, which agile methodology would suit a mainframe environment the best?
4
I would suppose there are two factors which lead to this:
-
Mainframes are used for applications for which Waterfall is usually more suited:
-
Many mainframe applications are business-critical or life-critical: those projects require a lot of paperwork and don’t fit well with Agile.
-
You rarely see mainframes in start-ups. Mainframes are rather used by government agencies, healthcare sector and financial institutions. Those entities have a habit of using Waterfall, defining the cost of the project prior to its beginning (as well as drafting the requirements specification).
-
-
Mainframes are used by developers who are habituated to Waterfall more than Agile. They worked with Waterfall for decades, and may not necessarily accept to radically change their methods.
In the same way, guess where would a young developer interested by Agile search for a job? In a start-up or in a government agency?
5
There are many reasons:
-
Mindset: Many of the developers working on mainframes do their work for decades. They ‘grew up’ with water fall and aren’t exposed that much to new ideas as other environments where the average developer has maybe 5years experience and brings lots of new ideas to the table.
-
The environment: A lot of stuff they code is tightly bound to a database. Also the components they create a often tightly coupled. This hinders automatic testing a lot, which is one of the important foundations of agile approaches.
-
Tooling: The tooling they have to live will is often horrible. They often don’t have any testing framework nor a version control that would be acceptable for other developers. Automatic builds as a Java/C#/whatever developer expects are unheard of.
Of course the different reasons affect each other and normally enforcing them even more.