PashaPay Case: improving Agility with CAO
By Ilia Pavlichenko – Certified Creating Agile Organizations Trainer.
PashaPay is an Azerbaijani fintech that launched in 2022. Its mission is to enable every person to manage their money anytime and anywhere. The company has a network of million payment terminals and an app with an electronic wallet called m10, or “Em-on.”
The m10 app and million payment terminals.
Users of the app can transfer money internally, withdraw it without fees, receive payments, and pay via QR code with cashback.
An interesting fact of the financial services market in Azerbaijan is that 70% of transactions involve cash. For PashaPay, the main challenge is to overcome distrust of banks and attract those who do not use cards and electronic transfers in general.
Organizational design of PashaPay
By the end of 2023, the company had 600 employees. The digital solution (mobile application) was developed by ten distributed teams, totaling around one hundred developers. The functions of back-office, support, sales, marketing, information security, finance, risk management, and terminal support were based in Baku.
Overall organizational structure
The CEO of the company led the Executive Board, which included the COO, CPO, CTO, and CFO. Each top manager was assigned specific oversight responsibilities. In the m10 app, programmers, testers, system analysts, and DevOps engineers were under the CTO’s oversight, while managers, UI/UX specialists, data engineers, product, and data analysts reported to the CPO.
Key Challenges
At that time, Professional Scrum Trainer Sergey Lobin was an Agile Coach and an employee at PashaPay. He conducted an investigation of the organization (Go See). Some of the behavioral patterns that he found:
- Representatives from different departments were not aligned on the company’s strategy. There were many different answers when they were asked what the strategy was. Therefore, people followed their own agendas and priorities.
- Sales and Customer Support departments complained that they were not being heard by the CPO, and teams were implementing features that were not the most important from the client’s perspective.
- There was a lack of transparency regarding what teams were working on and how tasks were prioritized.
“Copy Paste Scrum”
Copy Paste Scrum is a widely spread dysfunction when Scrum is seen as a team level framework and not as a product framework. Each team had its own set of goals and a local “Product Backlog,” which was managed by a local “Product Owner.”
Organization of product development based on Copy Paste Scrum principles
Copy Paste Scrum led to numerous problems:
- Teams were not focused on the most important features from a whole product perspective.
- There was low transparency regarding priorities.
- Teams specialized around narrow domains of the product and worked with only certain types of features. Therefore, they were not able to quickly shift their focus and start working on a different product area when needed. The “Copy Paste Scrum” caused low adaptability at the product level.
- Local social identities emerged, with teams concentrating on their own features and associating themselves with parts of the product. This resulted in technical debt not being addressed. Team level “Product Owners” were not interested in improving the whole system because they were responsible only for their specific parts.
On the other hand, the current organizational design achieved a relatively high delivery speed: 85% of features were delivered to the market in 16 days or less. The teams were fully cross-functional, including UI/UX, development, testing, analytics, and DevOps
Management training
In the fall of 2023, the CEO, CFO, Scrum Masters, and several Product Owners participated in the Designing Agile Organizations (DAO) training.
PashaPay senior managers at the DAO training
The training significantly impacted management’s mental models. The most impactful discussions revolved around the Product Group recommendation and teams with a shared Product Backlog (interchangeable teams). As a result, on the second day of training, the CEO decided to take on the accountability of the Product Owner and manage the Product Backlog.
A memorable moment occurred during a discussion on flow thinking when the CEO unexpectedly exclaimed, “So, I will be paying developers for only working 40-60% of the time?! We need to accept this notion!”
Another concept that resonated with the management team was Jay Galbraith’s “Star model,” which enables organizations to change systemically by considering strategy, structure, rewards, and HR policies as a whole, rather than focusing on local optimizations.
For the heads of marketing, sales, support, and functional leaders in IT, a second training session was conducted. It was quite tough because participants had many questions about how to apply the principles in practice. Some of the participants were quite skeptical about the overall approach and were questioning it, but eventually they supported the CEO’s decision to transform the company.
Weighted SWOT analysis and confrontation matrix
It’s important to understand which organizational capabilities need to be maintained and developed to implement the business strategy. To identify these, Sergey Lobin and Ilia Pavlichenko worked with the teams to conduct a weighted SWOT analysis – see Creating Agile Organizations (CAO) book chapter 8 “Preparing the Product Group”, listing the company’s strengths and weaknesses, as well as opportunities and threats:
- Strengths: teamwork, ecosystem support, product uniqueness, atmosphere and culture.
- Weaknesses: alignment of goals and strategy, technical strategy, predictability of delivery, discipline and accountability.
- Opportunities: customer needs, ecosystem support, 50% cash transactions, regulation.
- Threats: laws, competition, new payment systems, information security.
SWOT + Confrontation Matrix
Next, a confrontation matrix was created, juxtaposing the opportunities and threats with the company’s strengths and weaknesses. Points were marked at potential intersections to identify areas that needed special attention, for example, areas where threats meet a company’s weaknesses.
Systemic organizational design
PashaPay wanted to move quickly, so a three-day session on systemic organizational design was organized for 30+ leaders across the organization.
Urgency for Change
Defining the reasons for change creates the momentum needed for transformation. Therefore, Sergey and Ilia opened the session by explaining why the company would be undergoing changes. They used a shared objectives canvas from CAO (Creating Agile Organizations book chapter 8 “Preparing the Product Group”):
- Which problems will the change solve? Creates alignment on what current systemic issues one will address
- Which opportunities could we exploit that are presently out of reach? Invites the participants to align on the new opportunities that will be possible
- Why is this change needed now? Creates alignment on the urgency for change.
- What are the risks if the transformation fails? Aligns on all the bad things that will happen and that we want to avoid.
This message was then communicated at a Town Hall meeting with all employees of the company.
Why behind the change is explained with shared objectives canvas
Organizational capabilities
Based on the results of a weighted SWOT analysis and a confrontation diagram, the leaders compiled a list of organizational capabilities to be developed and maintained.
Capabilities to develop:
- Focus on shared goals
- Skill of prioritization
- Facilitating dialogue
- Discipline
- Predictable delivery
- Learning speed
- Responsibility
Capabilities to maintain:
- Passion
- Openly talk about problems
- Terminal network
- Scaling platforms
- Ability to learn from mistakes
- Ability to find business opportunities
Subsequently, the transformation group chose to focus on developing top 3 capabilities: shared goals, facilitating dialogue, and the skill of prioritization. Interestingly, it later became clear that responsibility and discipline are derivatives of these capabilities and therefore are automatically addressed.
Defining Product Boundaries
The most heated discussions revolved around defining the product boundaries. First and foremost, they established the following key criteria (Creating Agile Organizations book chapter 8 “Preparing the Product Group”):
- A product has users who are people.
- A product provides features to those users that address their needs and problems.
- A product has a business model; revenue stream, independent profit and loss (PnL) results, or return on investment (ROI).
- A product is developed and sustained by a system of people, components and processes.
Once we ensured that the entire group agreed on the criteria, we began searching for potential “products.” Several emerged:
- DailyPay — part of the m10 application
- BillsPay — part of the m10 application
- The m10 application as a whole
- The m10 application & million payment terminals
- Million payment terminals
After lengthy debates, the group decided to consider million and m10 as independent products. Firstly, they are practically autonomous. Secondly, DailyPay and BillsPay, despite being part of the PnL, are not independent products but rather parts of it, as they cannot exist independently. Combining million and m10 was impractical due to the sheer volume of changes required.
Leaders decided to focus on m10 first and agreed on assembling a product group around it.
Designing the Product Group
In CAO a product group has a purpose or a mission. Therefore, we started crafting it. After several rounds of discussion, we found the final formulation:
“Attract and then retain customers through simple and convenient solutions for daily financial operations.”
Next, the group began to identify the essential parts of the product group. Thus, they decomposed the mission.
First level of mission decomposition
Second level of decomposition
Two levels of decomposition proved sufficient to understand which organizational functions to include in the product group.
Launch of the Leading Team
Most transformations fail not because the changes are bad, but because organizations, as large social systems, wish to maintain the status quo and actively resist change. The goal here was to create a sense of ownership and reduce resistance to change.
The second intention was for company employees to make key decisions about organizational design themselves, as they had the context. Of course, prior to this, they took deep training in the principles of building agile organizations.
Thus, Sergey and Ilia proposed to establish a transformation group, or Leading Team (Creating Agile Organizations, chapter 5 “An Agile Adoption Approach”), whose goal would be to craft a detailed organizational design and present it to an expanded group of leaders for feedback. We had more volunteers than we expected for a Leading Team, so we had to organize a unanimous vote.
Creating Leading Team and unanimous vote
The Leading Team represented the company as a system and included senior and middle management, developers, Scrum Masters, and a HR representative.
Clarifying Organizational Capabilities
The first task of the transformation group was to clarify the organizational capabilities, as they had been defined at a rather high level during the strategic session. We divided the leading team into mini-groups that worked on defining capabilities and relevant metrics.
What the mini-groups accomplished at this stage:
- Gave a definition of what it means to facilitate dialogue
- Understood that focus on shared goals and prioritization skills are developed through a single Product Backlog
- Decided to track learning speed using Cycle Time and Time to Learn metrics, and track predictability through a Cycle Scatter Plot Diagram
Informing Employees and Building Transparency
Rumors about the transformation and the shared Product Backlog spread quickly through the teams and departments. It urged us to initiate a process of regular transformation updates through town hall, Sprint Review and corporate messenger channel.
Work of the Leading Team
There was a high level of engagement. Participants met daily, bringing new insights, sharing progress and engaging in extensive discussions. Not everyone embraced the idea of self-managed teams, so various models for team formation were debated, including those with technical and team leaders or without them.
Meanwhile, a comprehensive technical audit was conducted within the company. The auditors proposed their version of the organizational structure, which included technical and team leaders, project managers, an architectural office, and other traditional solutions typical of a “large” enterprise.
For a period of several weeks, the work was entirely taken over by the CPO and other Scrum Masters. When Sergey returned, Jay Gilbreath’s “star model” was still in place.
Foundation of Organizational Design for PashaPay
The leading team did not embrace the idea of team leaders as they wanted to rely on self-organizing teams. Therefore, the cultural DNA of the company remained actually unchanged.
Unfortunately, the Leading Group abandoned the idea of forming a formal, dedicated business unit for m10 (Product Group), and from that point on, we were dealing with a virtual Product Group.
Shared Goals
Separation of front-end (sales, marketing, support etc.) and back-end (development) units is generally not recommended in Agile organization.
It is not enough for the front-end units to identify customer needs and then hand them over to the back-end units. People within the product units benefit from a good customer understanding so that they can develop the right solutions (Creating Agile Organizations, Cesario Ramos and Ilia Pavlichenko).
Agile organization considers two options:
- Merging front-end with back-end units into a larger unit, the product group
- Creating shared customers and shared performance indicators for the different units’ managers. This coupling creates the conditions for each manager to do what is best for the shared customer (optimize the whole) instead of locally optimizing its unit.
As we dealt with the virtual product group, the best we could do is to use the second option. Therefore, shared goals were introduced for sales, marketing and product development (Guideline 6: Group by Common Customer).
Shared goals for product development, marketing and sales
Combine Authority and Responsibility
One of the key organization design guides in the CAO approach is Combine Authority with Responsibility. It leads to a Product Owner role fulfilled by a senior manager who is responsible both for product success and development. In our case the CEO became the Product Owner and soon it became clear that he needed to be relieved of some responsibilities due to massive overburden. Therefore, we used the Product Owner Team pattern. The latter took on most of the tactical tasks from the Product Owner. The CEO was left with only strategy, vision, and final decisions on Product Backlog ordering.
Product Owner Team
The Product Owner team included leaders of Value Areas (Area Product Owners) and representatives from related functions: marketing, sales, finance, and risk.
Teams with a shared Product Backlog
To enhance focus on shared goals and the prioritization skill capability, we recommended that all teams work from a single shared Product Backlog.
“It’s Counterintuitive, but shared goals worked—alignment was achieved”
Samir Mammadov, CEO PashaPay
Product Backlog with three Value Areas
Value Areas
Teams have started to specialize in specific parts of the product—value areas. In each area, there was:
-
- A product leader (Area Product Owner) responsible for a portion of the unified Product Backlog
- A technical leader (tech lead) who helps translate the IT strategy, build processes, assess and train team members, and improve overall technical quality
- A Scrum Master
- Cross-functional teams
Structure of the virtual Product Group and Value Areas
At the time of writing this case study, there were three Value Areas:
- Retail: 4 teams, focused on retail clients;
- Business: 3 teams, focused on B2B clients;
- Platform: 3 teams, serving users within the organization: sales and support.
Architectural Office
In the image above, you can see the “Architectural Office.” This is a new division for PashaPay that includes system architects and analysts. Similar to the role of the technical leader in the product areas, this is the result of a compromise reached during discussions with technical auditors.
During discussions within the Leading Team, it was concluded that team leads would negatively impact the work of Scrum Teams in the context of PashaPay. However, to systematically address technical debt and architecture, the role of the technical leader and the architectural office were added.
Facilitating Dialogue
In the Copy Paste Scrum model, each team has its own planning session. Once the teams began working with a shared single Product Backlog, all key stakeholders and functions—product managers, technical staff, sales, risk managers, and legal advisors—started attending the general planning session.
Initially, the meetings were challenging, but over time, we developed an optimal format, aided by effective facilitation. At first, Scrum Masters handled all facilitation, but it quickly became apparent that basic techniques for stacking and tracking were being adopted by other participants. Eventually, they learned to listen to each other.
Final results
What Worked
With the help of the CEO, senior management and leading team, applied the CAO approach and some of its organization design guides: Product Group, Merge Essential Interdependencies, Product Definition, Group by Common Customer, and Combine Authority with Responsibility.
The CEO of the company was the primary stakeholder and driving force behind the transformation. According to him, the main achievement was focusing teams and functions on shared goals and ensuring they work on the most important items from a company perspective. This focus on shared objectives emerged from process changes and the alignment of all teams around a shared Product Backlog.
The transformation hugely impacted the order of the Product Backlog and its contents. That led to an increased customer satisfaction, users’ loyalty and better product quality.
Several Quotes from Interviews with the Samir, CEO:
Transformation cannot be outsourced
We need people who want to take ownership.
This journey is ongoing, and the story is not finished yet.
We don’t have all the answers, but we will find them together.
We have created a peer space where cool things happen.
We don’t need Scrum or Agile; we need to achieve our goals.
There is no “us and them”, we are part of the same team.
What Did Not Work
The attempt to create a formal m10 Product Group failed. We dealt with a virtual Product Group, and the reporting structure remained unchanged. What did this lead to? Representatives of functional departments were still more loyal to their functional leaders and often hesitated to respond to requests from Area Product leaders (Area Product Owners), which slowed down product development.
What we’ve learned
Conclusions made by the case study authors — Ilia Pavlichenko and Sergey Lobin:
- Active involvement of senior management is a critical factor.
- Resistance significantly decreases when changes are made collaboratively.
- Instead of trying to adopt existing frameworks like LeSS or SAFe, it is better to create a custom framework based on the principles of systems thinking and flow thinking, and develop necessary organizational capabilities.
References
By Cesario Ramos & Ilia Pavlichenko. 2021
Creating Agile Organizations website: https://creatingagileorganizations.com/#guide
Value Areas in CAO – https://creatingagileorganizations.com/requirement-areas-vs-value-areas-different-perspectives-both-essential/
CAO Guide – https://creatingagileorganizations.com/#guide