facts.
customer's requirement.
Ausy Technologies supported the customer in several phases of the development of a bank's own scaled agile framework and the subsequent iterative transition with experienced agile coaches. After an own model was set up in agile cycles in the first phase, cross-team processes and the modeled flow could be tested and refined in the prototyping phase. A number of challenges were successfully addressed. Critical to success was consistent support in the enabling team, process visualization and the agile approach of the project in order to arrive at the in-house framework iteratively and empirically.
Our customer is a bank that was one of the first providers on the market to offer a location-independent and fully digital loan. By differentiating the product range, an extensive product landscape was built up, which increasingly requires maintenance and further development.
The existing challenge at the customer
By 2020, the bank was already gaining experience with agile product development in "agile islands", parallel to the traditional waterfall model. This constellation and the acceleration of the market led to the following challenges:
- Uncoordinated expansion of the portfolio due to a silo perspective
- Reduced flexibility of solution development
- Lack of or insufficient teamwork and a lack of active management of dependencies
- Need to speed up deliveries to customers
- A lack of uniform processes for cross-collaboration
Goals of the transformation project & basics
To address these challenges, the bank now planned a transition from "agile islands" to a collaborative and goal-oriented system. The agile islands should work together ideally with the waterfall teams. The aim was to find a future-proof model that enables cross-functional, cross-team collaboration, breaks down silos and promotes cross-bank requirements management, actively manages dependencies and enables timely delivery of valuable customer-useful implementations as part of a holistic rollout management (synchronized and quality-assured).
Concrete steps were:
- Modeling of a bank's own framework
- Piloting the framework
- Extension of the transition to other teams
- Standardization of IT
- Common tools and processes
When testing the well-known scaling frameworks (such as SAFe) it was found that they were not precisely tailored to the specific needs of the bank, so it was decided to create a bank-specific framework which, however, selectively uses certain elements of other frameworks.
The model is based on the following concepts:
- the Agile Manifesto with its 4 values and 12 principles
- the Lean Principles (identify value, reduce waste) & Lean Budgeting
- the practice of continuous delivery, which usually aims to achieve centralized tooling and generic deployment automation
This transformation should first be worked out for the IT development department in 3x4 workshops and as a concept.
our solutions.
Ausy Technologies Germany AG supported this project with experienced agile coaches who successfully accompanied the change project at team and management level.
Concrete challenges of our agile coaches
Plan: concept of cooperation as result documents
At the beginning of the project, a number of workshops were planned for each core area, which should create result objects such as a defined procedure for requirements management, definitions of roles, uniform synchronization points and interfaces as well as a target for technical control and automated deployments in the respective environments.
Lack of cross-team processes.
The existing agile teams were “agile islands” within the bank and suffered from the silo perspective. Despite dependencies, it was often not clear how the cooperation could be regulated or when something could be handed over.
Integration of overarching areas.
Another problem arose from the fact that only the IT development was to be transformed: the integration of the comprehensive portfolio planning or the bank-wide release timing were not initially in focus.
regulatory constraints.
Due to BaFin regulations, special attention had to be paid to the definition of roles, processes and documentation. At first glance, this contradicts the agile team structures, which can also be subject to regular adjustments in accordance with the “inspect & adapt” principle.
line structure of employees.
The employees were integrated into lines and were "borrowed" to agile teams and withdrawn again as required. This led to bottlenecks in use and thus to a slowdown in development.
slow timing of the releases.
Traditionally, the bank only had a few releases during the year. This prevented quick delivery to users. The test phase of a release alone lasted several weeks, which was also due to the previous procedures.
solution approaches of our agile coaches.
First of all: Our agile coaches supported the various approaches with appropriate questions and pointed out possible pitfalls that could be avoided in advance. Thanks to the committed bank employees, the various challenges could not only be recognized, but also solved.
iterative modeling phase.
Instead of workshops, our agile coaches suggested using the scaling framework in an iterative approach during the modeling phase as well. In this way, the agile teams could already be involved with their experience in this phase. It also enabled stakeholders to update modeling progress, address concerns, and experiment through four-weekly reviews throughout the phase.
The online tool Miro enabled continuous development of content and transparency for interested parties.
After initial workshops to define the vision and goal for everyone involved, a team was set up for each core area and a four-week "sprint" was established with planning, review and retrospective, as well as a weekly, in which the teams coordinated with each other.
The vision was first further refined in "lighthouses" with concrete target images and then mapped in OKRs in order to obtain not only a desired target image, but also measurable milestones that ensured the progress of the modelling.
This type of cooperation proved its worth, so that the pilot phase was also followed iteratively and the bank's own framework could be successively refined. In addition, two teams were formed to support the Agile Coaches: a transition team for management issues (primarily staffed by team leaders) and an enabling team with representatives from the teams who are responsible for refining the framework and removing obstacles took care of For example, they took care of topics such as tooling.
In order to be able to decide on changes to the framework structure and process definitions from as many perspectives as possible, well thought-out and with a large majority, a corresponding regular appointment was introduced. Every employee was invited to this and was able to contribute and have a say in decisions.
In the long run, retrospectives and a smaller team should continue to iteratively refine the framework.
processes in flow view.
After extensive recording and visualization of the actual processes according to the process model "Draw how to make toast", work could be carried out on merging these processes in several cycles in a flow view. The image of this flow view shows how a project is planned and implemented within the bank. The visualization and the joint work of all those involved on this overall picture not only created a uniform understanding of the process, but also ensured easy-to-understand documentation.
integration of the overarching areas.
Since other (specialist) areas were organized in a classic way, there were different perspectives and difficulties in understanding the IT. This meant that communication and integration into the agile flow were inadequate. In order to improve cooperation, our agile coaches supported with change management initiatives and alternative approaches, as well as built understanding in discussions.
It was important not to impose the procedure here and to keep inviting other teams and areas to join. In this way, a temporary transition should be achieved, in which each area can gradually join at its own pace and old structures can be replaced.
common “definition of done”.
During the course of the piloting, it became clear that the teams needed a common, overarching definition of "done". This was then developed with the support of the agile coaches. The common definition of done (when is the implementation of the feature complete) and also a definition of ready (when is a feature ready for implementation) now also represent the central control element for development.
support in complying with regulations.
BaFin issues certain specifications, for example which roles and responsibilities must be covered in projects and must also be occupied by natural persons. The coaches helped to examine the definition of agility and to create a consensus in coordination with the enabling team. The aim was to create an auditable documentation of the bank's own processes that would do justice to the agile way of working.
line structure of employees.
The agile coaches helped to create an understanding of long-term cooperation in the teams. After the pilot phase started, it became increasingly clear that the classic line structure thwarted the agile way of working. The Agile Coaches supported an agreement with the line managers, which ensures that employees are seconded to a team for at least one year. In this way, the stability in the teams could be promoted.
Furthermore, our agile coaches were able to support inexperienced scrum masters through coaching, to reduce conflicts in the team and to establish a team structure that promotes agile working methods.
results.
- With the support of AUSY, the bank can now fall back on its own agile framework. This not only takes regulatory aspects into account, but also other framework conditions such as existing knowledge distribution and team formation, but also the company culture and previous processes. It is designed to drive further change, to continue on the agile path and to be able to make improvements to the framework. The bank's own experience in the area of agility could also be incorporated.
- This not only makes the framework more precise, but also increases acceptance when it is introduced. Procedural overhead caused by the previous use of standardized scaling frameworks has been reduced - the new framework follows lean principles. With shorter release cycles, agile requirements management and streamlined processes, the bank is equipped for further digitization and can react much more flexibly and quickly to changes in the market.
- In addition, the new process has also contributed to an increase in employee satisfaction. Not only lighter processes, which allow employees to focus more on their core activities, but also the opportunities to participate in actively shaping the company have made a noticeable contribution to this.