In a previous article, I highlighted how the agile methodology first adopted by the software developers and technology team at Capital had spread like wildfire, with other departments across the wider Group becoming excited about implementing agile working into their own processes.
In this second part of our agile explorations, I want to delve into the elements of agile working environments that were adopted most quickly outside of the technology teams and the aspects that have made the biggest difference to our organisation. Interestingly, in most cases, these are working practices and ways of thinking that require no investment in technology tools and can be applied to any business.
Here are a few examples of agile working methods:
Show don’t tell
The incremental delivery of complex software products demands that teams constantly show stakeholders what they are doing to help refine the requirements. With agile delivery, there is a finite time between releases (termed a ‘sprint’) which, at Capital, is every 2 weeks. This means that on a weekly basis, the team will demonstrate what they are working on currently and what is about to be released to customers.
Regular demos lasting 10 minutes provide an overview of what is about to be released to customers. The stakeholders are taken on a journey. We start with the initial design mock-ups, then explore the tweaks made along the way and finally, we arrive at the end product ready for release.This story-telling session is a massively powerful forum, bringing all disciplines together to sharpen their focus on what is still required and to quickly highlight where things aren’t working as first thought.
Critically, taking this time to show stakeholders what is happening and bringing them along for the journey is effective in getting operational staff to buy into things that have the potential to rock their world.
Retrospectives
Another key practice of agile workplaces is the ‘Retrospective’: an honest and zero-blame review of what went well, what went badly, and what lessons were learnt during the previous delivery cycle. Unlike more traditional monthly operational reporting meetings, which still do exist at Capital, retrospectives involve the people doing the work, and the meetings are facilitated by someone with no line-management responsibilities (a ‘Scrum Master’ in the world of tech).
This grass roots focus in a neutral environment ensures that lessons are learnt, changes are made, then a few weeks later the impact of these changes are reviewed in a never-ending cycle of continual improvement.
Don’t sit when you can stand
At the start of every day, each team will meet for a short meeting (usually 15 minutes) to escalate any issues, talk through priorities and to get aligned for the day ahead. In agile speak, the meetings are termed ‘Stand-ups’, a remnant from the age when meetings were short enough to allow people to physically stand face-to-face although, in this current age, most stand-ups are held with participants sitting down on a collaborative video conference call. Crucially, stand-ups should be short and sweet. It’s not about getting into the nitty gritty. They simply serve as a bitesize update to ensure everyone in a team pulls in the same direction.
Can do KANBAN
Kanban is a simple scheduling system originally developed at Toyota in the 1940’s with the aim of managing work and inventory at every stage of the production line. The system takes its name from the paper cards that once tracked production within the Toyota factories.
Today, in its simplest form, nothing much has changed in principle. The stages of a process or workflow (e.g. onboarding a client) are drawn onto a wall and paper post-it notes are used to identify the items at each stage in the process. The post-it notes are then re-arranged at the start of every day during a team Stand-up.
Having such a strong and simple visual representation of an end-to-end process makes it easy to track progress, identify problems and to agree as a team on the resolutions.
I distinctly remember feeling that the agile working culture we were living and breathing in the tech team was spreading throughout the business when I found out that our Finance and Marketing teams were using Kanban boards. It was then even more rewarding to learn a client onboarding team had unlocked a 500% increase in productivity by aligning on Kanban principles.
To be clear, the old-school post-it note method has its limitations, not least when teams are distributed across different working locations. At Capital, we use digital Kanban boards which, in our case, have been created using the project management software, Jira.
Squads not Silos
One of the biggest organisational and management mind-bogglers when looking at agile organisations is the departure from traditional, department-led teams in which the co-ordination and decision-making happens principally at the director level of management.
As a concrete example, historically, the responsibility for onboarding clients in a financial organisation is typically shared across the ‘front office’ Business Development teams and ‘back office’ operational teams, with the overall ownership then sitting at a CXO level.
If this process were to undergo an agile face-lift, the onboarding of clients would sit with one cross-functional team who are solely focussed on ensuring a great client onboarding experience. One team with one goal, empowered to take their own decisions and held accountable for their performance.
At Capital, our approach was to reorganise, bringing previously siloed teams together under a single leader, co-locating all team members together to improve communications and the sense of team identity and then managing the team with the help of daily stand-ups, reviewing KPI dashboards and an onboarding Kanban.
Open alignment
The single most important foundation for building an agile organisation is to align everyone on a vision and common objectives. Based on experiences gained in tech organisations over the past two decades, the most effective way of doing this is to roll out objectives and key results (OKRs) that are openly shared from the CEO through the entire organisation.
In traditional companies, objectives are only visible 1:1 between a manager and a staff member. In contrast, OKRs are based on the principle that everyone’s objectives are visible and aligned.
Having aligned objectives that are visible to all is key to creating a common sense of purpose. Anyone, at any level, can see how their objectives and key results relate to their manager’s and to their teammates’. This openness helps drive a sense of team ownership and pride in hitting their goals and helps to create a better awareness of how other teams are contributing to those same goals.
Within Capital, my OKRs as Chief Technology Officer are agreed with the CEO, visible to everyone, and linked to the Technology department OKRs which cascade to every single member of the team.
Getting to know your users
The use of customer personas is not exclusively part of the agile way of working; rather, it is a user-centred design technique that emerged in the 1990’s as a way for digital product designers to better understand the needs of the customer.
A persona is a fictional character created to represent a customer type that might use a website or product. It is usual to construct multiple distinct personas representing specific market segments or customer types. Personas are useful in considering the goals, desires and limitations potential customers have in order to help guide decisions about product features, interactions, and visual design.
At Capital, we implicitly knew that our banking and investment products were used by different types of clients: from direct clients, to independent financial advisors, introducers, CSPs etc. For a long time, we had thought of these clients as being users of the same products, but by focussing on the creation of personas, we identified a staggering 22 distinct types of clients, all with differing needs! This shift in thinking has been profound. With hindsight, it seems obvious but from experience, very few internet banks and investment products are customised based on a detailed understanding of who the customer is and what they really need.
In conclusion…
Organisations must constantly adapt to be successful. To quote Winston Churchill: “To improve is to change; to be perfect is to change often.” The finance industry is unique in having ‘Change Management’ in many organisational structures, but in leading digital product organisations change is a constant, handled by everyone through agile ways of working — it is not a department.
The learnings from Capital, a very mature, traditionally structured financial services company, has shown that organisational agility can be improved not through a top-down directive in a Change Department, but from individuals embracing new ways of working that are supported by members of the technology team.
Agile ways of working are accessible to all organisations. There is no right way to do things, so start small with a few motivated people and empower others to pick up the agile practises that start to deliver results.
Disclaimer: The views, thoughts and opinions expressed within this article are those of the author, and not those of any company within the Capital International Group (CIG) and as such are neither given nor endorsed by CIG. Information in this article does not constitute investment advice or an offer or an invitation by or on behalf of any company within the Capital International Group of companies to buy or sell any product or security or to make a bank deposit.
