ORLANDO, Fla.–Credit union IT execs have been challenged by more than just rapidly evolving technologies and near-daily attacks by hackers: many have also transitioned from the waterfall model of software development to the so-called “agile” methodology.
During the CUNA Technology Council meeting here, three executive discussed their experiences in making that move to the agile model, which is designed to help teams respond to unpredictable environments through incremental, iterative work cadences, from the waterfall model, which is a sequential design process that is more consistent and predictable.
Participating on the panel were Trey Kelso, VP-business solutions and development with Virginia Credit Union in Richmond; Dustin Montoya, director of application development and support at Open Tech Solutions in Centennial, Colo.; and Scott Rabe, product management and development manager at Spokane Teachers CU in Washington. The discussion was moderated by Caroline Martorano, senior manager, software optimization, with Baxter Credit Union in Vernon Hills, Ill.
Below is a look at the questions that were posed by Martorano, and how the panelists responded:
Q: When did you use Agile Methodologies for the first time?
From left, Dustin Montoya, Scott Rabe and Trey Kelso.
Kelso: Probably about three years ago. We were overhauling the Enhanced Loan Experience, or ELE. We wanted it to be more responsive. We saw that 60% of the clicks on our advertising were coming from mobile devices. We saw the benefits right away. There really weren’t any problems. What we did find was that it shed light on the problems that exist in traditional projects, we just learn about them faster now. In the end I think we came out with a very robust product. As long as everyone is involved in the project throughout, you don’t find out at the end that you’re late; you know if you are.
Rabe: In the first project we did with our software development team (under agile) we brought in a software coach. Itt was an online membership application. We had just finished with a vendor and it didn’t work out very well and never shipped. We brought in a coach to help us get started so we were talking the same language. It really helped us to get more immediate feedback from what needed to change and what would be off. I think one of the biggest challenges we had early on was understanding what our real philosophy would be. A lot of that was around what the word ‘done’ means
Q: What are the top three characteristics that make Agile different from other methodologies?
Montoya: I think some of the key characteristics is that the trial and error piece promotes fast failure and course correction. Teams are allowed to fail early as opposed to waiting to the end of a lost waterfall effort. Another is the constant customer engagement and taking a lot of the middleman out of the loop. And another I don’t like to lose sight of is there is a difference between what you’re trying to get out of an adaptive process vs. a predictive process.
Rabe: Overall, adaptability is my number one. We find more and more that you just can’t plan out all the work you need to do next year. You comee to a conference like this and see a bunch of other things you want to do. So for agile teams the communication process that happens all along the process really helps to put out a product that meets the end user’s needs.
Q: What is the single biggest success factor?
Kelso: The biggest success factor for the implementation of an agile project is having strong leaders who are flexible. Implementing agile is a big change, so having leaders who can focus on the intent and letting team members self-organize is important in executive leadership. Some control has to be given up to a servant-leader paradigm, and that can be an uncomfortable space. But by instilling ownership in the team it makes the agile implementation that much more successful.
Q: How does the agile methodology balance the conflicting demands of changing requirements?
Rabe: A lot of times people think everyone in the credit union likes to make change requests, and the fear is that being agile means lots of change. We expect that, because we know we don’t know everything going into it. You have to better define the work as it comes up and you’re ready to work on it. What I find is as those project changes come in it really leads to a good conversation, because sometimes those changes are things that really need to happen, and you can talk to the owners of that and it allows for some good negotiation. In the past we would have put in everything at the bottom of the list; with agile, we have found that some things at the bottom of the list are not in the way of shipping, and sometimes they just fall off because they are not needed.
Kelso: Change is not bad thing. If you expect change you’ll deal with it a lot better. One of my favorite things to say is ‘Ideas beget more ideas.’ So being able to adapt throughout the process means you end up with a better product sometimes. You find that you didn’t know you needed that until someone brought it up. Before we adapted agile new ideas got jammed into the existing schedule and something substandard was shipped.
Q: What is one thing that would derail an agile project?
Montoya: Sometimes there are people who are adverse to change, saboteurs who can impact the culture. I think another thing is just from an exective point of view, glomming onto the sound-bites of agile, rather than the care and feeding and managing of the process.
Rabe: I think one of the big things that can really derail agile is not taking the time and making sure you have a good definition of “done.” Without it, you pile on a lot of technical debt and something isn’t fully tested or integrated, which spawns more projects into the future.
Kelso: I’d have to say having someone in the group who fails to negotiate. Everything for them is priority #1.
Q: Culture is a big part of project methodology. What cultural changes do you have to make related to agile implementation?
Montoya: It’s a big change if you’re going from one methodology to another. It’s a silent hurricane between changes in your people, processes, tools and sometimes even your working space. With people, you might be introducing new roles into the team. With process, there may be behavior changes going on. With tools, you might be applying new lifecycle management tools for development team that everyone has to use.
Rabe: If you don’t take the time upfront and you’re used to doing waterfall, you have to get everyone on the same page on terms, etc. It can fall apart pretty quickly. People might be used to seeing everything written down on a document, and there is a need to have trust. You have to get people on board.
Q: What do you believe are the characteristics of a high-performance agile leader?
Kelso: Agility. Someone who recognizes mistakes and who is willing to fail fast. Someone who is a good listener, someone who can weigh risks, someone who can play the man in the middle and not take sides.
Q: What is the best advice you have ever received?
Montoya: The best advice is there is no silver bullet. At the end of the day it’s about art. I think a lot of that lesson is about flexibility, being a good listener and working hard at it, and going against something you believe in and going toward something your teammates believe in. In the end it is about your team owning the process.
Kelso: I guess it goes back to my personality type. I’m a charge-ahead person. My lead developer likes to plan everything out piece by piece. Taking the time to do that upfront planning and having the project broken into tiny slices helps make it a lot clearer to the developers.
Rabe: I come from a project management background, and that has a lot of waterfall in it. You always want to have an agile team move along a timeline, and for me I have had to trust in the principles of agile. You can’t reconcile the two.
