- Day-to-day banking
Day-to-day banking
Our day-to-day banking services cover everything you need to run your company finances, from accepting credit card payments to paying your bills.
- Finance
Finance
At Santander, we understand that to expand your operation you need access to finance. Here you’ll find a range of options suited to short and long-term needs.
- International trade
International
We’re focused on bringing a fresh perspective to businesses with ambitions to grow beyond traditional markets.
Our extensive local networks and knowledge around the world means we’re ideally placed to support your international trade plans. Let us help you uncover the path to international success.
- Sectors expertise
Sector expertise
Our sector specialists are here to help you prosper.
We understand the complexity and evolving needs of businesses in a wide range of industries. Our experts will work with you to help turn your aspirations into reality.
- Insights & events
Insight & events
Read the latest Santander news, market developments and insights, as well as register your interest to attend our events held across the UK.
Adopting Agile Business Methods
‘Agile’ is a project management method that saves time and money and has taken the IT world by storm. However, Agile thinking can also apply to the non-IT world, says Technology Editor Marcus Austin
The Agile project management method is fast becoming the de facto way of working in the IT world, enabling businesses to cut their development times by 25-50%. But Agile thinking can also apply to non-IT business projects. Agile essentially breaks down project management into sections (known as ‘iterations’), with each completed section reviewed by the rest of the project management team, as well as any project stakeholders, their collective feedback influencing the next step and so on.
The term was coined in 2001, when the ‘Agile Manifesto’ was published by a group of prominent software developers. The Manifesto was put forward as a partial response to the shortcomings its authors perceived in the more traditional 'Waterfall' method of project management. With origins in the manufacturing and construction sectors, Waterfall is a highly structured approach, best suited to environments where plans change less often in the middle of a project and where teams need to stick to a strict, pre-planned sequence of events, such as building a suspension bridge or projects that require solutions to be approved or are mission-critical.
A responsive approach
The main problem with the Waterfall method is down to long development- and build-lead times. These often result in amendments to either the overall project mission or specific features, as businesses respond to new technologies that have come along since the original project specification. These ongoing amends are known as ‘mission-’ or ‘feature-creep’. A common consequence of mission-creep is that it often leads to projects arriving late and over-budget. And because of the serial nature of many projects, failure within any section can result in the rest of the project being thrown into disarray.
"When the next game-changing technology or social network comes along, the Agile user can react to that change and have a solution out in the next quarter."
By contrast, Agile takes an iterative (rather than sequential) approach that is better suited to environments where mid-project changes come thick and fast. Agile methods break projects down into small increments that require minimal planning, to be carried out in short timeframes (or 'sprints') that typically last from one to four weeks. Regular meetings throughout ensure that progress is constantly monitored and required amends can be easily incorporated into the next sprint.
Greater flexibility
The Agile method builds greater flexibility into your business, keeping it in synch with the evolution of any long-term project and allowing you to perhaps steal a march on your competitors. For example, a solution provider using Agile can produce regular quarterly updates on its products, allowing them to integrate new features or quickly adapt to new technologies. So, when the next game-changing technology or social network comes along, the Agile user can react to that change and have a solution out in the next quarter. Whereas, a competing business that relies on the standard two-year Waterfall-driven build-cycle won't be able to incorporate new technologies as quickly.
There are many different approaches to Agile project management, and the right one for your business depends entirely on the product you are building or the market in which you operate.
Scrum
Outside of IT departments, ‘Scrum’ is a key Agile approach. Essentially a best-practice framework for project management, Scrum deploys a range of tools that can be applied to non-IT situations. These include product backlogs (a document for the entire project that prioritises required features by business value), sprint backlogs (a document outlining the work a team needs to achieve during a sprint) and burndown charts (a public chart, updated each day, that shows work remaining in the current sprint).
Another common application of Scrum to non-software projects is the Scrum daily stand-up meeting (also sometimes referred to as a ‘status update meeting’, ‘morning roll-call’, or ‘daily huddle’). The idea is that all team members gather for a 15-minute meeting every day, during which each person discusses what they've achieved since the previous meeting, what they'll be working on today and any problems they are currently facing.
Right tool, right job
Like any methodology, Agile is only as good as the people who use it. It’s still relatively new with only a small number of experts, which means the good ones are in short supply and expensive. While the rules are still quite well understood in the field of IT, it’s still very much a work in progress when applied to the world outside of software.
Lastly, it’s important to understand that Agile doesn't work for all types of project. It works well in areas where things can be changed quickly and frequently, in a build-test-refine manner. However, if you are using it in a situation where you only get only one shot at the solution, like building a bridge, then you should opt for a more considered and structured methodology.
