Being Agile With IBM i In A Changing Business Climate
February 26, 2018 Dan Burger
Business conditions are changing, and C-level executives are troubled by a lack of IT responsiveness to changing business conditions.
CIOs are feeling the pressure to step up. At the bi-annual CIO Summit, hosted by Seiden Group’s Alan Seiden, IT executives discuss agile development practices as one tool to help their IBM i development teams deliver better business solutions in situations where IT is breaking new technical ground or user requirements are uncertain.
“IBM i environments of the past were unified with RPG and Db2 and with few choices for user interface. Developers would copy an older program and know what to expect (end users knew what to expect too). Now we have Web and mobile interfaces and diverse technologies working on the i. And integrating with systems off the i. That level of choice and complexity benefits from an agile process, ” Seiden says.
Incremental change as a result of continuous customer feedback is one of the hallmarks of agile development, a process that has gained favor among organizations that see business transformation as critical for business success.
“Agile allows the product to evolve over time,” says Lisa Sieverts, an Agile Certified Practitioner and principal at Facilitated Change. “It facilitates continual work on small feature sets that are prioritized by customers and delivered in small increments of functionality.”
Agile is team oriented. Done correctly, it promotes collaboration among the developers and the business and operations people.
“Business cannot just hand off projects to IT with a vague idea of what needs to be accomplished. Business people must be involved every step of the way and have shared responsibility for the results. The team also needs to include someone who represents the end user of the software,” Seiden says.
Alan Seiden and Lisa Sieverts discuss the value of agile development at a Seiden Group training session.
It’s obvious IBM i development teams are growing more diverse. Modern RPG skills and traditional backend skills remain coveted, but modern SQL database skills; open source development skills such as PHP, Node.js, JavaScript; user interface and user experience expertise; and a new breed of business analysts are adding to the diversity. All these skilled people need to work together and understand each other better. As a group, they will decide what technology fits best in each situation. Agile methodology promotes the inter-department knowledge transfer that is important to future development.
A good example is when the integrations with other platforms become necessary. There will be decisions that determine how the integrations will be done, the data that will be transferred, and which users get their functionality first. These decisions won’t, or at least they shouldn’t be, made in a vacuum.
Product owners will gather opinions and gain a consensus based on feedback from the business side, the operations side and from IT. Gaining a consensus may seem like pie in the sky, but Seiden and Sieverts have witnessed positive results. They credit the retrospective process—a review of what was delivered and the way the work was done. During the review, which takes place after each incremental delivery, they look for things they could change to be better.
“There is a tendency to see this as a praise and blame session,” Seiden says. “But there are usually other reasons for success or mistakes along the way. They are brought out in the retrospective process. What was good and what could have been better is noted and applied to the next sprint. A sprint is agile terminology that refers to each of the incremental deliveries.
“We’ve found when we run through the retrospective process with the developers and the product owners (those responsible for the business outcome), there’s a degree of transparency that prevents some individuals from seeing the progress as different from the others. The product owner sees the developers are being honest and solutions come easier – perhaps another meeting needed to be scheduled because we weren’t as coordinated as we thought. Better co-ordination is often the outcome. Mistakes are not seen as a reason for resentment because we are improving the process.”
“The retrospective process becomes the engine for agile. Teams become more efficient and effective over time,” Sieverts says. “Continuous customer feedback is one of the most important aspects of agile development. Team are engaged in continuous improvement. They look for things they could change to be better.
“When an agile team gets really good at continuous improvement, the things they start incorporating are the processes of technical excellence. Strong programming practices, continuous integration, continuous deployment—they look for these things in every sprint. They get better, become more efficient, and the work is of high quality,” Sieverts says.
A constant emphasis on collaboration diminishes adversarial relationships that often doom projects. A classic example is the vendor-customer standoff. The organization argues that the vendor committed to an imprecise scope of work and the vendor argues that numerous change requests without compensation is unrealistic.
Compared to the traditional development process, often referred to as waterfall development, agile advocates believe their approach is far better at delivering what businesses need. The distinction, as they see it, is that traditional project management collects all information up front and then a design is created that delivers all the expected capabilities. The entire project is developed tested and rolled it out. To a large degree, IT must imagine what the software needs to be, and development builds it based on the initial assumptions. Collaboration is minimal and feedback isn’t received until the entire project has been delivered. By then, fixing the effects of incorrect assumptions can be costly.
What does an organization do to prepare for a switch to agile development?
“The most successful move to agile is when it’s done in an agile way,” Sievert says. “Switching everything at once in a process that’s been mandated across the entire company is not effective. It can be bottom-up or top-down, but cultural changes are easier if done in small groups rather than company-wide. IT is as good as any other starting point.
The first piece is to determine the people most affected. Usually that includes the development teams. They need to have the most participation.
“Pick one or two projects, run them in an agile way and observe how it worked. Then reflect and decide how agile can be spread more widely across the organization. Just as a project accretes sprint after sprint, small organizational changes accrete over time. Bring people together, keep them focused, help them identify the right steps.”
“Look for a motivation,” Seiden adds. “Why would a company begin looking at agile? The most likely reason is the waterfall approach has not been effective. Projects that are large have a greater amount of uncertainty and risk. Planning every aspect in advance is unlikely. Business people often they don’t know what they want until they see it.”
“When comparing waterfall to agile, Sieverts endorses waterfall in certain situations.
“It works for low uncertainty projects when schedules are easy to develop. However, many software projects are high uncertainty, and time more wisely spent doing development and getting feedback rather than trying to figure out how to schedule a large project.”
The review or retrospective process is a critical element. Organizations that try to convert to agile without including the retrospective step – what was done, how it was done, and determining how to do it better in the next increment –will fail.
“Agile is about continuous learning. Everyone gets their observations out on the table. It provides a forum for honest discussion without blame or recriminations. The tech side understands the business side and vice versa. Celebrate successes,” Seiden says, “and pay attention to where things are not aligned.”
RELATED STORIES
CIO Summit Planned For IBM i Executives
Tomorrowland: Optimism, Risk, and Preparation For IBM i App Dev
