Scaled Agile transformation:

Portfolio Kanban in TBC Bank

Transformation context
TBC Bank is a leading Georgian bank. It is ranked number 1 in multiple segments of the local economy.
The business has been evolving, leading to rocketing demand for in-house IT development.

The major growth directions in 2017 were:
● Enhancing in-house IT development;
● Transforming the bank with a scalable organizational structure that would answer the current needs of teams and the infrastructure, and
● Implementing Agile at Portfolio and Program level.

The main goal of this transformation is to improve the time-to-market by creating scalable and predictable delivery processes and to meet the business demand for IT resources.

Related goals:
  • Creating a new metrics ecosystem for Agile teams that could bring together and align business needs and IT performance;
  • Defining an approach for cooperating with outsourced IT vendors;
  • Improving value delivery transparency and predictability, while constantly ensuring business continuity.
When the Bank started its Agile transformation journey, it faced a number of challenges:
● The bank launched the transformation with an Agile island for 3 teams. It wasn't clear what to do next.
● Transition from Centralized to Decentralized control was difficult.
● A transformation team was organized to drive the enterprise-level transformation process, but it didn't have enough knowledge.
● The existing Agile teams had problems with Scrum.
● The bulk of IT development is outsourced, but there is little control over the IT vendors.
● The bank's Management board decided to roll out Agile to the whole enterprise wherever possible, but was unclear on how to do that.
● Agile Portfolio Management is not introduced yet.
● Certain change management processes are not transparent.
● Some IT vendors don't use Agile and require a custom approach to incorporate their deliveries in the Transformation backlog.
● Business and IT speak different languages.
● Business analytics is a bottleneck for the whole value delivery system.
● Business provides incomplete requirements to IT for development.
● Delivery dates are not clear.

When TBC Bank ran into these issues on their way to Agile transformation, they got in touch with AgileLAB for change implementation support.

The collaboration started off with an Agile audit.

It revealed a few less obvious hurdles on the way to implementing Agile:
● Business keeps sending new tasks to IT for development with no regard for priority. They demand new features or change priorities at least once a week.
● The major focus in planning bank activities was on the “we only do what we planned” approach, with a 1-year planning horizon.
● Features are deployed to production every month, but almost all deliveries depend on service teams.
● The average lead time for one feature is 6 months.
● IT does not track its delivery velocity or throughput.
● Development depends on a number of key employees, who have unique competencies that aren't scalable.
● Vendors are engaged in multiple Value Streams at once, with no defined way to distribute their resources.

AgileLAB also did a set of corporate Agile training courses for the bank's teams.

The bank decided on a custom SAFe configuration as their Agile scaling framework, and used Kanban at all SAFe organizational levels.
They finally made the first steps towards a Kanban system.
Powered by the Kanban system design, the first quarterly Program Increment (PI) Planning was done at the enterprise level. 
The transformation successes that helped improve the time to market, keeping the designed quarterly PI Planning in mind:
●       The bank's strategy was finalized and made available to the whole enterprise.
●   All the experts involved in the Planning process highlighted that Business and IT started to communicate much better.
●  Some of the features that Business wanted to include in the PI Planning were allocated to the next quarter due to a lack of IT resources. This transfer was visualized and Business approved.
●    A huge number of dependencies were identified and resolved.
●    Every Value Stream was visualized with a clear work design for a quarter.
●    Every Value Stream understood what every other Value Stream is doing.
●    The service teams' workload became transparent and predictable.
●    Teams identified risks and highlighted them for stakeholders.
“Dependency board designed at the quarterly PI planning. A huge number of dependencies were identified and resolved”
The growth areas revealed because of the collaboration:
●       Business is not engaged enough in designing and planning.
●   The initial backlog contained items with no owner identified and with no business needs defined.
●       Most items in the initial backlog didn't have business priorities.
●     Some items had release dates, scopes of release, and other important aspects decided by Business Analysts rather than Business itself.
●       The quarterly PI Planning lacks representatives from some of the teams.
●     Business Objectives, Impediments, and Dependencies were poorly described in a way that Business uses.
●    There is no official Lean Agile Center of Excellence in place yet. This Center is meant to support knowledge sharing within the bank.

Transformation insights:

●  The top management should be fully involved in the Transformation process. Otherwise, there might be problems with involvement and commitment from the other employees.
●   Transformation should go bottom-up and, at the same time, top-down.
●   Transformation is futile without serious product competences, so ongoing education is crucial.
●   The Kanban method is a perfect fit for SAFe.
●    The Kanban method is a perfect fit for managing vendors.
●  Large enterprises should apply the Kanban method as it helps align all of their business processes, whereas Scrum is a better fit for small IT companies or teams.

The next steps in the transformation:

●   Apply the formulas to the Cost of Delay and Weighted Shortest Job First (WSJF) prioritization model;
●    Standardize the roles of Service Delivery Manager and Demand Manager;
●    Review the WIP limits for Portfolio management and Value Streams;
●    Set WIP limits for Program management;
●    Train the management to apply the Kanban method, and
●    Follow the "Improve collaboratively, evolve experimentally" practice.
Contact us

Might be interesting