Since 2015 Bankdata has been subject to one of the largest agile transformations in the history of Danish software industry. Over a period of 1.5 years we have adopted Scrum in over 100 teams and more than 650 employees have begun the journey towards an agile mindset. As our company name implies we work with financial software supporting a wide range of banks in Denmark. The company is more than 50 years old and have a long legacy in the industry.

Situation

One of our ambitions for the transformation has been to get closer contact and dialogue with employees from our costumer banks. Using the Scrum framework we have involved the employees from our costumer banks through the Product Owner role to great success. However, the Scrum framework and role setup quite fast shed a light on a major impediment within our organization. We actually already knew about it before introducing Scrum, but as our customers were on the distance we were able to handle it with little interference to our customers with a longer lead time in our deliveries:

Not all customer requests are targeted directly at one system or one product in our portfolio. Customers work with process optimization, we work with product and system development.

Following the agile transformation in Bankdata our Scrum teams identified this as a major organizational impediment. The structure of our organization needed to be handled systematic and with care. As a customer employed Product Owner how do you navigate the organizational structure of another company and how do you gain priority and overview together with other Product Owners originating from other competing customer banks?

Complication

To fix the impediment we started looking for similar situations and references in available literature and theory. However, they all fell short in our complex situation:

• Scrum guide: States that it is the responsibility of the Product Owner to maximize the value of the product and work of the Development team – and continues to state that implementations vary depending on situation. No answer here.
• Scaled Agile Framework: Introduces the role of a Release Train Engineer who collaboratively with System Architects and Product Management seeks to handle the dependencies. This setup does not work in our case as the processes that our customer tries to change may target different portfolios over time and as such the group is impossible to define and get to work.
• Scaling agile at Spotify: The nature of the software developed at Spotify is unlike the software that we develop at Bankdata and as such the organization does not help our impediment. We looked into the structure of Chapters and Guilds but as they primarily focus on knowledge sharing (guilds) and problem solving (chapters) we were not able to adopt this.
• Nexus Framework: Introduces a team called Nexus Integration Team. The team exists to coordinate, coach and supervise the development. This setup is close to optimal when considering our challenges. We decided to use this setup as a stepping stone towards an organization that would fit our situation.

Resolution

The resolution to the impediment at hand was to introduce the FAPOITA framework and team structure. FAPOITA is the concatenation of the abbreviations of the Danish words covering Business architect, Product Owner and IT-architect.

FAPOITA is responsible for making sure that the right people interact at the right time and has the overall responsibility for making the flow between teams run smoothly.

This means that FAPOITA members assist the individual Product Owners in understanding their part of the solution and create priority for refining and development across all involved Scrum teams.

We have designed our scaled agile setup using a few ground rules:

• Don’t escalate, facilitate
• Product Owners are responsible for prioritization (and adhere to the coordination)
• Development teams are responsible for coordination (and adhere to the prioritization)

We operate with two setups: Continuous team and on demand team.

Continuous team

Parts of our portfolio is continuously subject for cross team work and therefore a core team is responsible for driving this work. This gives our customers a single point of entry for these types of requests. The continuous team is responsible for involving and updating the customer. The continuous team consist of a business architect, IT-architect and a Product Owner. From start till finish of a cross Scrum team task the individual Product Owners and other Scrum team members will be required to join the FAPOITA team to make sure the right people interact at the right time. 

On demand team

In some cases our Scrum teams face challenges that requires work to prioritized and coordinated between several other Scrum teams. When this happens an on demand instance of FAPOITA is started and continues to live until the solution is delivered. Startup of an on demand team is performed by the responsible Scrum team where the Development team is responsible for identifying other involved Scrum teams and the Product Owner is responsible for gaining consensus on needs, benefit and prioritization.

FAPOITA work flow

The FAPOITA team is responsible for the development flow from start till final delivery of a solution. Whether the flow is facilitated by the continuous team or an on demand instance depends on the specific task.

Typical tasks of a FAPOITA team:

• Receive task and understand initial scope and dependencies. This typically involves one or more Scrum teams who can help identify dependencies to other Scrum teams.
• Describe and evaluate benefit of the task. All relevant Product Owners from the involved Scrum teams is summoned to discuss the benefit of the task. The benefit could be estimated in business value points relative to the Product Backlog of each Product Owner.
• Gain priority for refinement of task across all involved Scrum teams to learn about development cost. When the Product Owners agrees that the task has high enough benefit to move on, the individual Development team is asked to refine their part of the solution and give a cost estimate. The cost estimate is typically delivered in story points relative to the Product Backlog of each team.
• Gain priority for development of task across all involved Scrum teams to deliver within agreed deadline. When the cost is collected and the cost/benefit ratio is rated sufficient by the FAPOITA, each Scrum team is asked to develop their part of the solution and coordinate as agreed earlier.

It is important to stress that FAPOITA relies on face-to-face communication and that one or more person from the involved Scrum teams carry information from one step to the next step in the flow.

Please note:

• Arrows illustrates that on or more persons carry information from arrow starting point to arrow ending point
• Boxes describe decision points or work situations
• Starting point may be through the continuous team or by creating an on demand team
• Delivery point is coordinated among the development teams following prioritization from Product Owners

Author: Rasmus Kaae, Agile coach at Bankdata. Co-authors: Tue Laursen, Business developer at Jyske Bank and Henrik Duedal, Business architect at Bankdata.