The Mandate

For over a year and a half, during my role as a Project Manager (PM) for one the world’s largest fund administrators, my primary mandate was to help them execute and deliver on platform and client enhancements, all while helping shepherd the Technology organization into using the Agile development methodology. The organization, by virtue of being one of the more established banks on Wall Street, was staffed with what you’d call ‘lifers’, or ‘near-lifers’. These were employees who have spent almost their entire careers at one organization. This was not a young, ambitious and progressive fintech company.

Within a week of joining, the mandate had come down from the CEO of the fund administration business that they were moving from traditional waterfall development to Agile development. The primary driver for this was to better service their client base by delivering change in a quicker and more effective manner. We planned workshops with all of the stakeholders – product managers, technologists, operations and business staff. The bank hired a seasoned Agile consultant and led the three day workshop. We listened to the Product Managers and Business staff as they discussed their pain points and issues. We then wrote user stories as a way of shaping the features they envisioned for the new Middle Office platform.

The Challenge

As the PM for the Middle Office/Derivatives workstream, my remit consisted of overseeing five different teams – derivatives lifecycle, pricing, messaging / enrichment, collateral management and reconciliation. The technology owners were based in the US, London and India. The staff was spread across all three regions and time zones.

Lessons Learned

NB: I’ll start using some Agile/Scrum terminology that you may not be familiar with. In that case, please refer to this site: https://www.scrum.org/resources/what-is-scrum

What did I learn?

• The scrum masters assumed an all-knowing persona and didn’t feel like they needed to listen to the Product Owners.
• As expected, many people decried the move to Agile development and didn’t believe that some usable functionality could be delivered in a three week sprint.
• The technology owners realized that some of their dev teams were Waterfall, while others were Agile and found it too difficult to cope.
• Product Owners and Business staff, after having relayed their requirements, felt they didn’t need to attend sprint showcases. These showcases were meant to demo new functionality every three weeks and ensure that the builds were tracking towards a minimum viable product.
• Many found the Scrum ceremonies – daily 15 minute stand ups, sprint planning, backlog grooming, showcases – too time-consuming.
• Product Owners used the Project Managers as their proxies for these meetings. They couldn’t be bothered with helping with scope and prioritization.
• Some didn’t grasp the concept of story pointing, the concept of relative sizing and the Fibonacci sequence.
• The definition of minimum viable product became distorted and meant whatever IT could deliver within a specified timeframe. This meant that if they planned for 10 items and could only deliver 6 of them…well, that’s our MVP and users be damned. In other words, they kept moving the goalposts.
• Business users didn’t write their users stories in JIRA and instead used Confluence to track items.

Epilogue

After a year of trying to move towards Agile development, the Bank hired a new head of Middle Office Technology. He decided he didn’t need Project Managers to help him run the project. Soon after, he started using a product roadmap software that didn’t fully integrate with JIRA and then issued a decree that everyone in his organization would be part of a dev-ops organization. This meant he expected everyone to code, build, test, configure and deploy. In short, he didn’t think the organization should have a division of labor between developers, QA and tech leads. One person would be able to take on all three roles at once. This resulted in duplication of roles, some people feeling left out and emasculated and a general sense of helplessness.

How can we help?

Do you remember the old adage, ‘hindsight is 20-20’? In a large organization ruled by many fiefdoms, no matter how well-planned you think something may be, there are always intangibles and unknowns that can come into play. Even in the most progressive technology organization, organizational behavior is an unknown, where egos, skillsets and characters mix and blend in unpredictable ways. When you factor in that this was, and is, a very traditional organization, that hubris can be downright cancerous.

If you have experienced these challenges, or are facing a similar challenge, feel free to reach out and contact us at info@finservconsulting.com or 646-603-3799.