JP Morgan Chase Is Going Agile
JP Morgan Chase is going agile! It only took a hundred years or so. Leo King has the details of the New York City-based banking titan’s agile transformation over at Computerworld UK:
Extensive redevelopment of key platforms has included the elimination of many legacy systems, an increase in automation, and better virtualization and capacity on demand, according to Mike Cavanagh, head of that division.
Cavanagh said that technology was enabling the bank to "optimize the location strategy" of staff, with an increase of the percentage working in low cost sites from 26 to 40 percent. The use of Agile development methodology was also enabling faster application deployment and better functionality, he said.
Of course, to many of you readers, it may come as no surprise that more organizations are using agile as a way to build products faster with team collaboration and automation tools.
We recently got the chance to chat with agile consultant Bob Galen, a regular speaker at STAREAST who shared his thoughts on how agile has changed the role of the tester in today’s organizations. In the conversation, Galen explained how modern day tools and agile methodologies have allowed for better communication between members of product teams:
So the functional testers could have an impact by evangelizing and really leading their teams with exploratory testing. The scripters—and I’m not trying to stereotype these folks—found their niche and were supplementing some of the automation code. There are some tools now that actually enabled them to “write automation.” The middle-tier tools like FitNesse and Cucumber allow non-programmers to “automate.” So it really empowered them. For the developers who were testers, they could now start writing user tests and middle-tier tests.
But automation may also introduce new challenges for agile teams. Author and software test lead Bob Jones writes:
On agile teams where all testers are automators, there may be conflict between the need to build automation and the need to keep up with the regular needs of the sprint team. If not carefully managed, this time conflict can lead to “mini-waterfall.”
Jones recommends that teams implement an automation hour—“one shared hour a day that everyone on the test team sets aside to work on automation projects together.”
