You are currently on IBM Systems Media’s archival website. Click here to view our new website.

AIX > Tips & Techniques > Application Development

Agile Development Concepts Prove Effective Regardless of Platform

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. 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 allows us to put our best face forward to existing and new customers. Coming from an IBM i perspective, the process of adopting agile development has been a learning experience, however, many of those lessons are applicable to developers, regardless of their OS.

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. 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 egalitarian 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.

As more companies hear about the value in agile practices, interest peaks in how these concepts play out. As much as I’ve absorbed from research, my real education came from observation. We’re a conservative insurance company committed to modernization of IT practices as much as is responsible, and we embrace philosophies only when they correspond with our core beliefs. We’re committed to IBM i as our base while using other technologies as necessary to move forward. And we’re in the last third of an enterprisewide endeavor to GUI all our business processes and organize our custom business logic in modular advanced RPG. This decade-long project started in a waterfall development model and has been the initial focus of implementing agile.

As a tester with responsibility for our automated testing tool, I’ve been frustrated trying to deal with the substantial changes in the tool regarding front-end scripting and the needs of our non-native IBM i UI group. When research didn’t help me determine how to support the IBM i technology testing and the User Experience group’s testing, I sought out champions in my knowledgeable co-workers. I found one in Phillip Schlatter, a business analyst executive and advocate of agile implementation. I came away with a comprehensive understanding of why we embraced this methodology as a company and where it can drive the IT department. His appreciation for agile is based in the importance of teamwork and communication—the idea a group can transcend any complication if it has healthy interaction and wants to work together for the common good of an organization.

For example, a Scrum meeting should be more like rugby. There’s no quarterback in rugby; rather all members of the team are equal and have the same weight placed on their opinions and ideas. He then applied the concept to a group not in business such as a church-service planning team. The pastor or priest, music leader, youth leader, etc., gather once a week to talk about their endeavors and the other ministers can see how they can support that in their own areas. I started thinking about this applied to a family with school-aged children where everyone is going in a million directions at once. What if the family met on a regular basis to talk about each person’s needs for the day or week? Would the family run more smoothly?

Phil spoke about things like when and how to involve stakeholders, how management can help and motivate, where processes bog down and how to break lose the logjams. Listening to him, I heard a dozen ways I could better utilize Scrum to inform/be informed by my team members.

Recently, our RPG development team implemented a new Scrum-like meeting. As is usual, they are buried in needs and demands. But the tech lead discovered a Scrum meeting allowed his team members to discuss topics applicable to their current tasks. I’m sure many can relate to having a specific super developer on staff to whom everyone looks for guidance; however, this prevents super development from getting done. With a Scrum meeting, everyone on the team who’s working on the same type of development can have issues and solutions reasonably applicable to all. As a group, all those needs will be addressed once a day. Then, unless there is a blocker, no one should need to interrupt the lead or super developer so they can accomplish their own objectives. This is not a specific application of agile as we know it, but it is brilliant. An added benefit is the team brainstorms together to resolve things enabling peers to see one another as resources, reducing the need to always go to the super developer.

Buzzword or Valuable Change?

As IT expands into every segment of our lives, we’re exposed to new concepts and philosophies. Many people feel agile is the latest business buzzword and its popularity will fade. This is likely to be true for organizations that use it superficially. However, for teams that value all the contributing members and want to empower employees to reach new levels of synergy, it’s a worthy pursuit.

Yvonne Enselman is a testing and deployment analyst and quality assurance expert for Brotherhood Mutual Insurance.



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters