What is Agile?
Agile software development has established itself as the tech industry’s favourite project management methodology. It is much more than working faster. It is a completely different approach (and some might say more realistic) to problem-solving
during the product development process.
Agile is more than just a few techniques, it requires a different mindset throughout the whole organisation. We believe that this is one of the approaches that incumbent financial companies need to take in order to keep up with startups and ‘Big
Unlike Waterfall, an Agile team assumes from day one that they don’t have all the information they need in order to deliver a full product on time and on budget. There are too many unknowns in digital product creation to have a fixed plan. But that
doesn’t stop them from delivering a Minimum Viable Product (MVP) after short work cycles called Sprints.
An MVP is a very simple version of your final product. So essentially, instead of having documentation at the end of, say, a month, you have working code that can go live and gather analytics data for improvement in the following cycles/sprints. An Agile
team believes that the client is paying for working software and not for meeting notes.
The advantage for the supplier is that they don’t lose money. For the client, they’ll have something they could use after just a few weeks rather than months and maybe even years. In other words, they’ll be ahead of the competition,
potentially already recovering their investment and already learning from their customers what works and what doesn’t.
Of course, in order for this to work, Agile teams have to follow a radically different process which is way more dynamic than Waterfall. It could be daunting if you’re stuck in your ways and don’t like to talk to other team members! Agile
promotes constant face-to-face communication, sometimes even on your feet, in order to enable quick problem-solving and decision-making.
Scrum enables teams to break their work into actions that can be completed within timeboxed iterations called Sprints which are usually two-weeks long. The idea is to keep track of progress and re-plan in 15-minute stand-up meetings, called Daily Scrums.
There are several “ceremonies” the team needs to attend in order for this to happen and those are run by the Scrum Master. They are a “servant leader” to the team. Their main role is to facilitate those ceremonies and remove
blockers. More on the ceremonies in the “How to get started” section.
It is absolutely vital that the team doesn’t get blocked during a Sprint. Which means no one from the delivery team can be sucked into business meetings. To represent the business, the client appoints a Product Owner. This person is the connection
between the project team and the business. It is their responsibility to chase information for the team, to make business decisions and is the person who will decide and sign off whenever they feel like a user story is actually done.
This approach aims to manage work by balancing demands with available capacity and by improving the handling of bottlenecks. Work items are visualised to give participants a view of progress and process via a Kanban board. Work is pulled as capacity permits,
rather than work being pushed into the process when requested.
Lean Agile Process
Adapted from the Toyota Production System, Lean development can be summarized by seven principles, very close in concept to lean manufacturing principles:
Eliminate waste Amplify learning
Decide as late as possible (instead of based on assumptions)
Deliver as fast as possible
Empower the team
Build integrity in
Optimise the whole
How does Scrum work in practice?
As mentioned previously, there isn’t only one way of doing Agile. There are many different techniques that the team can use, adopt and adapt as needed. Below is an example using the Scrum methodology.
Any task that needs to be completed in order to deliver the final product goes into the backlog. It is the Product Owner’s responsibility to prioritise the tasks for the Sprints according to the roadmap. Every task is represented by a ticket and
every ticket needs to have all the information the developer needs in order to complete the task. During the Backlog Grooming sessions, the tickets are presented to the team. This enables the developers to ask questions and raise anything that they
think might be an issue. If the team know the answers, then this information goes into the ticket. If not, then the Product Owner needs to find the answer before Sprint Planning. If the developers are happy with the information on the ticket, then
they ‘size it’ during Sprint Poker. In this exercise, all developers vote on how long a task will take to be done. If there is a disagreement on how long a task will take then the ones that disagree have to explain why they disagree. Once
they’ve considered all points-of-view, then the team votes again until everyone agrees. This is important because, for instance, a developer might think that something is simple and not consider something that a more experienced developer knows
could be a problem.
The Scrum team hears from the Product Owner what the goal for the Sprint is. The tasks to achieve this are broken down into assignments. The ones that bring value to the user and to the business are called User Stories. They are defined as follows:
As a (user)
I want (goal)
So that (benefit)
As a broker
I want an intuitive lending criteria search
So that I can be sure that the lender is the best fit for my client
The team goes over every single task and agrees whether they have all the information they need in order to complete it during the sprint. If someone in the team says they can’t complete a task because they need X, the task goes back to the backlog.
Every task is measured in points, with complex tasks that take more time being assigned more points. Smaller, simpler tasks are assigned less points. After a few Sprints, the team finds its’ capacity. If they don’t meet this capacity, it means
they’re not talking enough and they’ll discuss this during a Retrospective.
It is a max 15-minute stand up meeting where the team talks about what they worked on yesterday, what they’re working on today and if they have any blockers. In this case the developer would say “I want to work on task X but I have no internet”.
It is the Scrum Master’s job to “unblock” this team member.
A retro is a ceremony run at the end of a sprint. The team talks about what worked, what didn’t work and what they can do to avoid it in the following sprint. The Scrum Master will keep tabs on those and make sure whatever happened before won’t
happen again. For instance, a person says they didn’t deliver a task assigned to them because they faced a particular challenge. Then it is the Scrum Master’s job to solve this issue. Ideally, this would never happen, as there are Daily
So how do I get started?
Adopting Agile is a big undertaking that requires a fundamental change in mindset. The bigger the organisation, the more dedication will be required. You might need one or more Agile evangelists and Scrum Masters to train and remind the staff of Agile’s
values and principles.
However, there are a few simple actions that a smaller organisation could start taking today. Perhaps the most obvious one is remembering that face-to-face conversations are more effective than emails. If you think you can solve something faster by talking
face-to-face, then stand up and do it!
Then, the next step could be to book a Daily Scrum with your team. Make sure that everything said is written on post-it notes on a shared wall. Once they are done, the owner of that task can stand up and move it to a column called Done. It really boosts
morale of the team to have visualisation of the progress of their work. Especially if there’s a little collective cheer every time something is moved to Done just before an important delivery. For more complex projects, there are many more techniques
that can be applied, such as Acceptance Criteria.
The key to success is to get stakeholder buy-in at a high level. When you’re making your case, make sure to study what is working, and what isn’t, in the organisation. Then explain how Agile can help with that. Hopefully there are plenty of
helpful arguments here, but if you think you’re going to need more assistance, there are plenty of guides online. Alternatively, if you work for an incumbent financial organisation and you would like some help or advice on getting started with
agile, drop us an email at firstname.lastname@example.org and our team would be happy to help.