Back before scaled agile frameworks had matured, one high-pressure situation taught me a few lessons that are still relevant to enterprise agility today.
Renowned surgeon and author Maxwell Maltz once said: “Close scrutiny will show that most ‘crisis situations’ are opportunities to either advance or stay where you are.” I can tell you from personal experience that this is true. Let me explain.
It’s common knowledge that the financial services sector went through a slew of regulations between 2009 and 2016 in the aftermath of the infamous financial market crash of 2008. But it might not be common knowledge that several of these regulatory initiatives during that period competed against each other for time, attention, and resources within banking organizations. I witnessed one such initiative close-up while working with an IT team in an advisory role.
It was nothing short of a crisis situation for my client company at that time, who I will call “X-Bank”. There was a regulatory deadline looming in just three months and a lot of work remained incomplete. The deadline was immovable and the stakes couldn’t have been higher for X-Bank: their reputation was riding on compliance with these new regulations (not to mention the fines for failing to comply). To get the unfinished work done, X-Bank’s emergency management procedures kicked in.
An “action force” of ten people came together, and I was a part of this group. Our task was to integrate the work of various siloed teams attempting to build a regulatory reporting solution and scale the solution across banking operations. The team was made up of X-Bank’s staff, consultants (like me), and vendor representatives. Team members had significantly divergent backgrounds and seniority levels, which turned out to be beneficial (more on that below).
Back then, people simply called this “crisis management”. But with collaborative efforts, we did get to the least anticipated outcome, a successful finish! How we dealt with the situation gave me my most important lessons on agility and scaling change across an enterprise. This was my first experience of a real gemba.
Gemba (現場) n. – A Japanese term meaning “the actual place”. In Lean methodologies, the gemba refers to the place where value is created. This could be the shop floor at a factory, the kitchen in a restaurant, or workstations in an office.
Frameworks for scaling agile are undoubtedly much more evolved today, and over the years I’ve had other experiences too. But I keep reflecting on X-Bank as it has remained an unparalleled learning experience. Here’s what I took away from it.
1. Urgency matters when you need to make a radical change
In X-Bank, the situation demanded a sense of urgency, which had us all on edge as things unfolded, but ultimately proved helpful. Unfortunately, people tend to overlook the importance of urgency when driving major changes in non-emergency situations. I’ve often worked with frustrated clients who have been running multi-year agile transformation programs without substantial results. They’d be better off creating a sense of urgency that can spread like wildfire, rather than merely relying on gradual incremental changes that could take years to achieve.
A sense of urgency can come from either external or internal forces, but the external ones are more powerful. For example:
- Market changes – In the case of X-Bank, a regulatory deadline.
- A pandemic (or other prolonged global drama) – As we are currently witnessing, companies want to be more agile than ever so they can navigate an environment of constant change.
- Disruptive innovation – This can be internal from within the company, or external from competitors.
In Lean parlance, all these lead to kaikaku (or “kaizen blitz”), the lesser-known cousin of kaizen. Kaikaku is all about radical change. This does not necessarily mean that kaizen (incremental and continuous improvement) is less important. But in the context of orchestrating an organizational change, kaikaku is more efficient. It is like being airlifted to reach a destination 200 miles away, rather than trying to reach there walking. In other words, one creates a pathway for the other. Kaikaku first, then kaizen.
The Bottom Line
Build events or other points of resetting (e.g., offsites, end-of-quarter) into the cadence. Driving toward those points will help bring out the right behaviors and make it easier to implement radical change.
2. Agility requires a holistic change to your operating model
Many organizations have pockets that embrace popular frameworks, such as SAFe or S@S or LeSS. But any contradictions or mismatched operating procedures (and/or culture) in other parts of the organization can result in a failure to scale agile effectively. Hence, we cannot scale organizational agility merely by using popular frameworks without making holistic changes to how the company actually operates.
In the case of X-Bank, the regulatory compliance initiative touched every aspect of the business. This meant the entire value chain had to be analyzed. The subject matter experts on the team traced every product and service offering to map out each value stream. This visualization was the key to finding all the places where we had to change a process in order to meet the new regulation. Consequently, various ring-fences of people were formed to start integrating and testing the updated process steps. This led to significant organizational agility within a short period.
The Bottom Line
Agility requires holistic change to the operating principles, which are optimized by aligning teams, processes, and governance to the value streams.
3. Lean budgeting makes a big difference
In the past, enterprises aligned budgets to “cost centers” on an annual basis. But we know today that aligning budgets to value streams is better for creating agility. That said, the vast majority of companies are still using traditional budgeting and accounting methods, which add significant constraints to agility.
In X-Bank, the business sponsors temporarily transferred budget ownership to the delivery organization during the crisis period, making it possible to adjust funding iteratively based on plan→do→check→act (PDCA) principles. Interestingly, there were no guardrails around how the funding was used – we just had greater accountability for how it was spent.
Admittedly, X-Bank did use cost center-based reconciliation, which resulted in a post-implementation nightmare of cross-charging to the cost centers. But the takeaways are still valid: a high degree of openness and adaptability lead to enhanced agile delivery.
The Bottom Line
For most IT teams, budget is a major constraint to being fully agile. Funding the value stream by cadence minimizes this constraint. The accounting practices need to adapt Capex vs. Opex definitions based on the long-term transformation roadmap of a value stream.
4. Agile practices can (and should) extend across your supply chain
One of the best things X-Bank did was create an open dialogue with suppliers. The informal community-based approach of shared values, standards, and methodology built rapport to an extent that everyone could rely on one another in a crisis.
Otherwise, working with suppliers without compromising agile practices is a significant challenge to many companies. Procurement processes are notoriously bureaucratic, for one thing. Plus, suppliers can have their own practices and standards, which could be significantly different. They might not want to collaborate on a daily basis, and instead just want to deliver a finished product.
The Bottom Line
Promoting a culture of openness and shared values with supplier organizations creates seamless agility across the supply chain. A sense of community goes a long way in creating cultural shifts.
5. Design thinking along with a Lean approach helps you scale efficiently
At the time of the X-Bank initiative, the challenge of scaling agile was well known. But frameworks such as SAFe, DaD, Scrum@Scale, and LeSS had not fully evolved. Instead, our team embraced user experience (UX) design best practices to identify personas and user journeys. The delivery was influenced by the Lean Startup approach, popularised by Eric Rees.
The primary focus was on redefining the MVP (minimum viable product) necessary to satisfy the auditors by the regulatory deadline. The scope was visualized in concentric circles, with core parts of the backlog represented by the inner circles. The scaling methodology was based on classic build→measure→learn feedback loops, which quickly got us to the stage where we could accelerate our efforts with confidence.
The Bottom Line
Customer experience plus design thinking is the new hotness (and for good reason!). There are lots of companies buying into it, but many struggle to scale practices. When design thinking is used in conjunction with a Lean approach, scaling the change becomes more efficient.
6. Dogfooding really works
As part of build→measure→learn, the delivery teams at X-Bank engaged key internal groups, primarily auditors. The internal audit teams provided significant feedback and helped refine the user journeys. Their involvement also encouraged various business areas to embrace the product more quickly. And in case you’re wondering, when the external auditors got their first look, they were impressed with the quality of work.
The Bottom Line
Even the best teams struggle with conceptualized vs. actual user behavior, which leads to technical and functional debt. Continuous dogfooding helps you avoid that.
7. Vertically sliced teams help you navigate along the way
Agile has emphasized cross-functional teams since its earliest days. But one of the most significant things I learned from the X-Bank initiative is the importance of slicing teams vertically as well as horizontally. That is, having not just subject experts who know all the nuances of their job function, but also senior leaders on the team who can help navigate the various organizational nuances.
The Bottom Line
Organizations get to a point in their transformation journey when their conventional structures become bottlenecks for scaling. Vertically sliced cross-functional teams can accelerate scaling.