Don’t Go Chasing Waterfalls
The financial services industry is evolving quickly – almost as quickly as the tech industry. This evolution is parallel to adjustments I’ve had to make in my own career over the years, and credit unions need to be ready for these changes to remain competitive, as well as relevant to their members.
Are you using an Agile process internally? Kanban or Scrum maybe? Or are you still doing development using Waterfall Methodologies? Look - if you want to do it quickly - you really need to start being Agile.
Waterfall is known as a traditional process. In it, the tech is planned out from the beginning, the requirements built and then the software or tech is delivered. Any changes along the line become part of Phase II, III, etc.
On the other hand, Agile is a looser schedule, revisited at the end of each sprint, which is typically two weeks long. Additionally, software is continually being delivered as requirements are being updated and adjusted to adapt to the varying needs of the business. What’s important to remember about Agile is that it’s about the people, not the processes.
That’s right up the alley of the credit union, isn’t it?
Agile, while it has become a process, is first and foremost a mindset – an approach. It’s about teams operating as teams and not as a leader barking to his crew. Take a quick peek at how it works.
The Product Owner (Product/Marketing Manager) works with the company to determine what’s going to be built. This person will communicate across the credit union, working with member service, tellers, finance, training and others to determine what needs to be done to label the project as completed, typically called success criteria.
The Product Owner or Business Analyst will craft user stories – breaking the entire project into smaller, bite-sized chunks. Each of these user stories will be reviewed by engineering to determine how to accomplish the requested user story.
The Engineering and Product teams partner to define when a project is done, as well as effort and timing. Work for these stories is then scheduled into sprints.
Sprints, again usually lasting two weeks, include daily check-ins with the stakeholders listening to the engineering team discussion on a daily scrum. They cover what they’ve been working on and what they will be working on prior to the next check-in. This is their opportunity to discuss any roadblocks or challenges, and the team can jump in to help.
At the end of the two-week cycle, software is delivered. It may be a feature, a new package, or a new user Interface. These small cycles of continuous improvement on large platforms can greatly alter the platform over time. But what’s important to note is that these short cycles allow the team to remain nimble and adjust priorities based upon member demand.
Do your engineers need to build a new UI for your mobile app?
Or is your online banking needing a drastic fix now?
Agile allows you to shift these priorities quickly - especially in resource constrained situations.
This ‘process’ isn’t solely reserved for tech projects.
Is your credit union acting as nimbly as possible?
