Is Agile Effective in an IBM i Arena?
Agile concepts of software development though teamwork, short cycles, adaptive planning and evolutionary tactics have been discussed and implemented for more than a decade and, like anything else in IT, diverse opinions and experiences exist. My employer embraced agile about five years ago, and was one of the first IBM i shops I knew of personally to do so. As a team, we’ve watched the strengths and complications evolve. As an insurance company, our interface to the agents is critical. The responsive nature of agile and the emphasis on relationships lets us put our best face forward to existing and new customers.
My Introduction to Agile
My first exposure to agile came when tasked with covering a Scrum meeting my boss usually attended. Initially my thoughts were “Scrum? Do I need a scrub brush?” Scrum is an agile framework for managing development that focuses on flexible, holistic strategies of working together toward a common goal rather than a more traditional sequential approach. I took an immediate dislike to the process. However, I was honest enough to admit that, as an IBM i advocate through and through, this being advanced by a non-native IBM i group made me suspicious on principle.
Successful IBM i shops are becoming multidiscipline and this is not easy for any group involved. After so many years of being considered old technology, irrelevant and passé, it’s hard for procedural programmers to trust innovative business processes. As a quality assurance (QA) and testing analyst, I’m firmly in the enemy camp yet adhere to the IBM i doctrine and thus fear being phased out. My response to the discomfort was to read about this “new” development we were adopting so, even if I didn’t like it, I would at least understand it.
The more research I did on agile, the more I respected it and saw its natural place in our environment. The first thing that had bothered me specifically—that development tasks discussed in Scrum didn’t correlate to testing tasks and I couldn’t follow what the others were discussing—was actually indicative of an issue needing resolution. Agile was a way to identify that disconnect early. As I learned about agile methodology, I had to appreciate anything that had so many interesting people writing about it. Unfortunately, little of what I read was reflected in our shop or experiences specifically enough to resonate with me. The ideas were great but weren’t enough to sell me on why this was now so important to my career.
Agile in the Real World
A chasm often lies between the ideals of agile and the real-world manifestations. One of my favorite examples came from a programmer introduced while integrating two merging companies. Predominantly they used the Scrum concept of daily meetings, calling them huddles. The change in name was out of American pride in football versus European rugby term—which led to there being a clear quarterback in the room negating the equalitarian aspects of the meeting. Worse, project managers and application development managers were in frequent contact with developers requesting status updates throughout the day. Not surprisingly, this resulted in developers feeling another 30 minutes of their day was being spent in an unproductive meeting. They still couldn’t concentrate on getting anything done because of constant interruptions. When asked for any agile concepts that could be recalled, the answer was when coding anything a programmer should have someone looking over his or her shoulder.
However, the chaos of mergers is an excellent time to have the clarity of agile principles helping teams cope. If management were truly committed to this concept, developers and testers would have been radically more productive. The visibility would have aided people learning to work together, and communication would have reduced duplication of effort and the accompanying frustration. And most importantly, by ignoring the no-interruption directive, managers were irritating the producers they needed, thwarting progress and alienating the team.
The official Agile Manifesto is:
“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
That’s quite a bit different than we have a meeting once a day, everyone should work in one large room and hovering is good.
comments powered by