Agile is now one of the most important buzzwords in the business and technology world. Everything we do requires some form of “Agile”: decision-making, coaching, practices, methods, processes, operations etc. The list of ways in which companies and people use the word “Agile” to describe themselves is endless.
So much so that it has become an industry in itself, and it’s booming. According to Version One’s state of agile survey 2015, 95% of organisations surveyed have adopted agile methods.
Despite this, Banking Technology has remained one of the last strongholds of waterfall methods. Switching from waterfall to agile isn’t an overnight change, it requires a massive cultural shift. This is something that is happening with the Fintech revolution, but banks are just a little slower to catch up.
The systems, structures and culture banks have put in place over the years make even the smallest changes cumbersome, which means they are now playing catch up with the digital revolution that hit every other industry over the last decade.
At Leveris we use Agile software development methods to create the banking platform of the future. We do this because we believe it is the best way to build the products and services required in the new digital age of banking. So how do we do it?
I am very lucky to have been around to see the rise and evolution of Agile methods. Every company I have worked at or with has attempted to use Agile methodologies to deliver projects with varying degrees of success and failure. So I am going to tell three very different Agile stories and then try to summarise why Agile has been working so well for us.
An old success story
In my first IT job, I worked as a tester with Intel on a small internal project that used Scrum. We broke two rules that a lot of people say are key to success; we weren’t a dedicated team (some members worked on other projects too) and we weren’t all co-located. In fact, the team was split across three different time zones.
Yet to this day it was one of the best implementations of Agile I have been part of, because you could see value consistently being added to the business. The reasons it worked:
- Project had a clear vision that everyone understood, and it was supported by all the key stakeholders
- It was a long-term project perfectly suited to iterative releases
- It had an impressive backlog of stories, and more was being added, scoped and prioritised by stakeholders on a continuous basis.
- It delivered daily builds with bug fixes and new functionality for the test team
- The team was given the time needed to achieve a regular flow, so that estimation and sprint burndown reached an accurate equilibrium
- The team was engaged in the process and motivated to succeed
The key learning from this experience though was that method implementation doesn’t have to be perfect to make Agile a success. It is the team that makes it a success.
A Successful Failure
I am not going to name and shame the company in this story. It was a large company looking to ride the wave of hype surrounding the benefits of Agile. During my time there, I worked on Agile projects and helped coach new Agile teams. The main issues I saw there at the time were:
- Hired in a consultancy to create a bespoke Agile process that took all the worst bits of waterfall and tried to layer them in on top of Agile
- No change in corporate culture to support Agile delivery. Every project still required estimated costs and timelines for full scope delivery. There was no tolerance of change to scope or priority
- Teams were dedicated to projects but didn’t have all the skills required to deliver end-to-end solutions. For example, teams that had dedicated developers without business support, testers or other key skills, were required to complete their work in a sprint
- No cultural shift to support proper business prioritisation. Stakeholders weren’t engaged: they gave a scope and deadline, and expected delivery
- Delivery teams weren’t engaged or motivated by the process or the projects
However, despite the above, the Agile implementation was still considered a success by the business. There was a perception that projects were being delivered quicker and cheaper, and that teams were more efficient. Perhaps timelines were a little more aggressive and projects were a little cheaper, however, the lack of stakeholder engagement meant that the quality of deliveries didn’t improve.
Teams also appeared to under-deliver, because there was a set project scope and timeline with no stretch goals or roadmap to work towards. There was no motivation to over-deliver, to make the stakeholders happy, or to try something new. Everyone was just happy to plod along through the motions of yet another delivery methodology because the culture shift wasn’t right.
The Leveris Story
Now on to the latest and greatest chapter in my Agile experience: using Agile to build the future of Banking As A Service (BaaS). I am one of the lucky few that has been with Leveris from almost the beginning, and I have been involved in our Agile evolution.
When we started our journey on the lending platform, we didn’t use any methodologies. We were a group of twenty people from different backgrounds, working hard to solve the lending world’s problems and creating beautiful prototypes you will never see.
During that time, we wrote stories and started to create a backlog that could be used when moving from prototypes into actual build. We started to grow and build our dev team: we put our “Agile” development processes in place; we set up a Jira; uploaded our stories; and started grooming sessions, demos and retros.
As we grew from a team of 20 to 60, so did our need for better ways of managing our teams and workload. We split into two teams: core platform and middle/front end team, sharing one backlog and one workflow. As we continued to grow, we evolved our teams and processes, creating more teams and multiple backlogs.
We are now using a customised version of the Scrum framework for Agile. As we have grown, we have learned and adapted to what works for us. Each team uses the basic ceremonies of Scrum, but as we go through retros we allow our teams to adapt and learn for themselves.
Some teams have created their own jira processes or use different estimation methods. we trust our teams to do what’s best for them, and in turn, they continue to deliver excellent results.
What has worked for us:
- Having a clear and concise company vision that everyone understands and supports “We are Leveris, and we build the banking platform of the future for the customer”
- We have endless backlogs of great features that we want to build
- Empowering our teams to make the decisions that best facilitate their day-to-day work
- Adapting to change and growth quickly
- Scrum of Scrums meetings keep our teams synced and manage our blockers
- The company culture has been built around the 4 values of the Agile Manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
I’m not saying our processes are perfect, but we are constantly learning and improving as individuals, teams and as a company. Everyone is motivated and we are constantly delivering new and innovative solutions in banking and lending.
Agile is not a methodology or a tool: it’s not about following the countless rules of Agile methods, tools or frameworks. It’s a mindset – it is the culture and dynamics of the teams that deliver the work.
If you go back to the original Agile Manifesto, the four values that it poses and the principles that derived those values are all focused on a mentality and culture of doing things rather than focusing on how they are done. Once you build the right culture around the values of Agile, the how and what of applying Agile can change but the positive results should remain the same.
That is something we have achieved at Leveris. We have built a culture that understands that things are going to change constantly and we embrace that. We have built our processes and our products so that they can adapt to different client needs.
Some info about our teams
- We have 8 Agile development teams that use our custom Scrum approach
- We work across three locations: Dublin, Prague and Minsk
- We have iterated our core process at least 4 times, but now have 10 different workflow schemes in Jira
- We have used man days, t-shirt sizing and story points to estimate for projects (story points is winning)
- We have 4 Dev environments and 4 Deployment environments for staged releases
- We have used 32 Jira projects
- 2 teams use a Kanban approach (Business Dev and Design)