Finland's Slot Machine Association (RAY) has recently undergone a major transformation from a steady operator of slot machines to an agile innovator of new games and concepts. As a key part of this transformation, agile methods used in product development teams have been scaled up to the organizational level using Scaled Agile Framework (SAFe). To help analyze the development in the organization's product development capability, we outline the Agile Product Development Maturity Framework (APDMF) that addresses the type of product market, complexity of work, the nature of development process, and the scope of agile approach. We argue that SAFe provides RAY with a “scaffolding” to support this transformation and to institutionalize agile product development for the future.
The general objective of this study is to contribute to the understanding of
prerequisites of implementing agile product development. Using a single case approach, we
analyze how agile product development was implemented at Finland’s Slot Machine
Association (Raha-automaattiyhdistys, RAY) to come to grips with the progressively
complex product market of the organization. To structure our analysis, we outline
Agile Product Development Maturity Framework (APDMF) that helps explain how
the product development capability of the organization has recently transitioned to an
essentially new level of complexity and coherence. This “level of work” [e.g. 1,2] is
commensurate with RAY’s evolving product market [cf. 3] that entails technological
change and evolving preferences of customers. In line with the observation that
formalized new service development processes are an antecedent of new service
development competence [
The structure of the paper is as follows: In Section 2, we review the business context of RAY that prompted the transformation in its product development capability and the introduction of the SAFe framework. To provide a theoretical framework to assess this transformation, we review three strands of literature in Sections 3 through 5. In Section 3, we introduce the notion of “Levels of Work” – a normative stratification of complexity that underlies human work. Section 4 presents a typology of three product markets of increasing dynamism and respective approaches to product design. And in Section 5, we discuss the three levels of “agile enterprise big picture” that underlies the SAFe framework. An integration of the theoretical background presented in Sections 3–5 is provided in Section 6 that puts forward the Agile Product Development Maturity Framework (APDMF), a framework that is intended to help assess an organization’s product development maturity and inform its further development. In Section 7, we review the implementation of agile product development at RAY, analyzing it, ex post, against the backdrop of this framework. Finally, we conclude the paper with discussion and reflection in Section 8. 2
RAY offers entertaining games in about 20,000 physical slot machines around Finland, in restaurants, arcades, online, and at Casino Helsinki. It is a non-profit special organization, governed by legislation and decrees, which give it the exclusive right to operate slot machines, Internet casino games, and physical location casino activities in Finland. The profits from RAY’s games are channeled to a wide range of organizations promoting health and social welfare. The fund allocation is guided by policies created by RAY’s Board of Directors and as agreed with the Ministry of Social Affairs and Health. RAY is a responsible operator that also ensures players’ legal protection, prevents misuse and crime, and reduces the harmful social effects of gaming.
In the wake of 2000’s, a number of trends suggested that the organization should transform the way in which it conducts business. Firstly, electronic means of payment started to challenge traditional cash payment. Secondly, international online casinos emerged and very quickly found their audience irrespective of national borders. At RAY, the need was felt to create a responsible, local alternative that is safe and reliable compared to many overseas online casinos. Moreover, Veikkaus, another Finnish organization governed by the Lotteries Act, had already embraced the digital channel. Thirdly, the new generation of potential players started to have growing expectations for the functionality and user experience of slot machine games. The good old, triedand-tested games needed to be updated to the new millennium.
In the early years of the 2000’s, RAY experimented alternative means of payment and around 2005 decided to furnish its slot machines with debit card terminals. This decision was the turning point towards RAY’s capability of producing contemporary digital consumer services. The deployment of new devices started in 2009. Rolling out the entire installed base of about 20,000 machines was a major undertaking that took five years. In addition to the debit card terminals, many other features were implemented during 2010–2012: new types of games as well as updates and configuration over network. The required new payment transaction system was a challenge in its own right, but the new slot machines also needed to be always online. Authentication of the player was enabled at slot machines as well as in online gaming services. So far the feature has made it possible to set individual limits for playing and to benefit from exclusive perks. Today, there are over 300,000 registered customers. Parallel to the development in slot machine games, a new decree allowed RAY to establish an Internet casino in 2009/2010. The Web also provided a new channel for games.
By the early 2010’s, the product development teams of RAY had already attained a reasonable level of maturity in agile software development methods, but steering of product development and business units was not commensurate with agility in teams that worked separately and in different rhythms. As the number of product development projects increased from 2011 onwards, an increasingly large part of projects called for creating crosscutting capabilities related to RAY’s gaming systems. The amount and complexity of projects brought about the need to improve design and steering of product development. The management of product development realized that without agile practices extended to budgeting, concepting, and decision-making, agile product development and deployment would not develop enough to account for the future needs. As a framework that would support large-scale agile product development, RAY decided to adopt SAFe, a model that helps roll out enterprise-wide agile methods for software-based product development. 3
Each organization has its unique structure, with an idiosyncratic number of
organizational levels. However, according to late organizational psychologist Elliott Jaques [
I. Quality: excellence of task.
II. Service: effective coordination, continuous improvement, efficiency. III. Practice: work practices and systems, productivity.
IV. Strategic Development: innovation, change and continuity.
V. Strategic Intent: direction, profit, long-term viability.
VI. Corporate Citizenship: vision, building strong national and world wide presence.
VII. Corporate Prescience: new forms of social, political and economic institutions.
In the following, we will briefly review three of these levels, Strata III–V, which represent middle and top management levels in a typical self-governing organization (of Str-V complexity) such as a large single-organization business or an independent strategic business unit of a large corporation organization. We will also discuss the dynamics of transition between these levels, as the organization grows in complexity. 3.1
At Stratum III, work is about systematic provision [
Stratum III is about creating value in the present within the existing asset base;
there is no expectation for investing new capital for innovation in new products, new
services, and new businesses, but the decision-making authority is limited to
shortterm core business process efficiencies to maximize return on investment [
The unit managers at Stratum III typically manage a mutual recognition unit, such
as a department of the organization, up to 300 people [
At Stratum III level of complexity, employees have a considerable degree of
autonomy and are empowered to take initiative on their own. This allows fast and systematic
response to a large market. However, this differentiation begets decentralization that
sows the seeds of the “crisis of control” [
Work at Stratum IV is markedly more strategic. It is necessary to think beyond
individual products, services, systems, or units, and to integrate, manage and support
interactions between a number of systems and practices. Whereas at Stratum III work
always has to be done within given concrete resources and limits, at Stratum IV a
broader overview and comprehensive management of the organization are necessary:
budgets and resources can be allocated and shifted in order to align the
comprehensive output of the organization with the needs of the constituents that it serves [
At Stratum IV, the focus shifts away from operational concerns to managing both
continuity and change [
Stratum IV is about breakthrough innovation of new products and services and
discovery of new markets [
At Stratum IV, coordinative means such as organization-wide programs, federated
governance mechanisms and profit sharing schemes allow the organization’s limited
resources to be allocated effectively. However, at some point the many systems and
programs tend to outgrow their original intention and become overly bureaucratic.
The ensuing “red-tape crisis” [
A move from Stratum IV to Stratum V is marked by a much more open definition
of the product field: concrete terms like “kitchen chairs”, “microscopes” or
“telephones” at Stratum IV will be replaced by broader terms like “furniture”, “scientific
instruments” or “communications equipment” [
Field coverage [
Product markets differ in terms of stability of technologies and customer preferences
[
In stable product markets [
In the respective “traditional” sequential development process [
Evolving product markets [
These new capabilities call for collaboration with complementors and overlapping
problem solving approach that organizes the sequential development into overlapping
stages [
Dynamic product markets [
The respective “modular” organization of product development processes [
The term agile was first introduced in the context of software development. Agile
software development promotes self-organization, close collaboration, rapid delivery
of useful software, and adaptation to changing requirements [
Leffingwell [
At the team level, agile teams define, build, and test user stories in a series of
iterations and releases. The teams of 7±2 team members are self-organizing with respect to
the work in the program backlog. They are also self-contained, having all the roles
necessary to develop the software features or components the team is tasked to
deliver. Typical roles in an agile team include a product owner, a Scrum Master,
developers, and testers. The team may also include (or share) specialty resources such as
database administrators, user experience experts, or test automation experts, as
necessary to define, develop, test, and deliver working and tested software. [
At the program level, multiple teams synchronize their development in an agile
release train (ART), which produces potentially shippable increments (PSIs) at typically
fixed 60- to 120-day intervals for customer preview, internal review, and system-level
quality assurance. Typically a PSI consists of four to five development iterations
followed by a hardening iteration (with an empty backlog) that is used to resolve defects,
refactor code, and to provide time for release validation and testing. SAFe is based on
the tenet of “develop on cadence, deliver on demand,” allowing the development team
to continuously build incremental product functionality, while marketing/distribution
is free to deploy external releases as necessary. [
At the portfolio level, a mix of investment themes establishes investment priorities
for the organization. These themes ensure that the work will be in line with the
business strategy. They drive the portfolio vision that is translated to epic-scale initiatives
that are prioritized, estimated, and maintained in the portfolio backlog. The epics span
several releases and are described at the level of detail that is only sufficient to initiate
a further discussion. Prior to release planning, these epics are converted into more
detailed stories that are allocated to various release trains for implementation. On the
other hand, architectural runway addresses architectural epics, which enable the agile
enterprise to implement high-priority features in short term without excessive,
delayinducing refactoring. [
Based on the theoretical background presented in Sections 3 through 5, we construct a preliminary Agile Product Development Maturity Framework (APDMF) that is intended to help assess the product development capability of a given organization and to inform how the capability can be further developed. As exhibited in Table 1, the framework integrates together requisite strata, types of product market, the respective development processes, and the levels in SAFe that help implement the respective levels of capability. The APDMF outlines three levels of product development maturity: Linear, Agile, and Coevolutionary.
Linear product development is of Stratum III complexity [
Agile product development addresses Stratum IV complexity [
Coevolutionary product development is of Stratum V complexity [
Product development at RAY dates back to the 1960’s, when RAY developed its mechanical payazzo games. Slot machines followed in the late 1970’s. Technological know-how pertained to design of games, production of machines, as well as resource planning of distribution and maintenance.
Product development based on software started in 1978, when RAY took on the task of creating a fruit game type of a slot machine. The development of games and supportive software increased in the 1990’s, when the machines were connected to the network and when the first multigame machines were built.
All in all, it was pretty much business as usual for RAY for almost 70 years: deploying new slot machines in the field, running casino type table games in night clubs and Casino Helsinki, collecting money, and channeling it to beneficiary organizations. The saturation point of the installed base had been achieved and business was not developing. The mode of operation was largely offline. As building a network for the slot machines started in 1995, Internet connections were poor, the network was only used as an incident and reporting channel, and games were operated with coins.
RAY’s agile game and service development dates back to six years ago. The programming of games has always been in RAY’s own hands, but only in the last three years in-house service development has been strongly adopted. This is in line with the strategy of building and maintaining products in RAY’s own teams, reinforced by external consultants, rather than sourcing these strategic capabilities from vendors. 7.2
In 2009, RAY took up a new project portfolio tool, whose purpose was to provide a comprehensive view of the projects in progress at RAY. However, project portfolio management at this point represented traditional project work, and RAY desired to work in a leaner manner. As the development of decision-making structures begun enterprise-wide in late 2013, product development seized the auspicious moment and adopted selected features of SAFe in 2014. These features constituted the planning and steering model of RAY’s product development.
The framework was first adopted in product development, but since then it has expanded step by step a team or a unit at a time to embrace parties directly connected to product development. RAY applies the model critically, adopting only practices that are considered as value-adding to its own work.
At the time of writing, the management model is as follows: • The board of directors is responsible for creating strategy. • The business steering group is responsible for developing and implementing strategic plans. • Distribution channels are responsible for implementing channel-specific plans. • The business operations group is responsible for the coordination of operational cross-channel work, e.g. pertaining to the SAFe-based “development train” of product development. • The development train implements prioritized tasks in both channel-specific and cross-channel backlogs and reports of the progress to the business operations group and thereby to the business steering group.
The governance of agile product development at RAY is illustrated in Fig. 1. All operational units, including product development, participate in the business planning process for strategy implementation. In this process, the financial goals for the coming few years are attained through product and service development initiatives driven by business needs. Business needs and concept ideas are compared with architectural needs as described in the enterprise architecture so that the necessary new capabilities and developmental requirements are recognized as early as possible.
The concept ideas chosen in business planning end up to the portfolio management process, in which the concepts are further developed, until some of them are mature enough to be implemented. A part of the concepts are still translated to projects, but it only has relevance from a project portfolio point of view. At the time of writing, the concepting phase is still on the development agenda of product development management. It might be ideal that within strategic themes, a number of concepts and project ideas would be cultivated and the best ones be chosen for further development. The coordination of work selected for implementation as well as dependence and resource management take place in the so-called planning process of product development trains.
As per the SAFe definition, a train is a team of teams, which at RAY involves around 120 people. Its purpose is to co-develop products and services for business. The product development train unites the teams in a shared rhythm, in which planning, implementation and continuous process development occur. The product development trains are designed to be 10 weeks in duration, so that visibility into future work is as realistic as possible and that the teams can agree upon the schedule for common work. In other words, the product development train arranges the work under one planning umbrella that defines the beginning, end, and quality, but not the scope. Each team is responsible for the scope, schedule, and releasing within its own area of responsibility. Each team contributes to the mutual plan by publishing which tasks are its own and which ones are shared with other teams during the trainplanning period.
The work is done in teams, whose backlog consists of 1) maintenance tasks pertaining to products and services in their area of responsibility and of 2) new development and testing. The teams are built based on the tenet that they are self-sufficient and self-governing. Members of the team include the product owner and other members that can often take on different roles within the team on an equal basis. 7.3
It is our interpretation that, in the last decade, RAY’s product development has developed from Linear to Agile, in terms of APDMF levels (see Table 2). This denotes a developmental transition from Stratum III to Stratum IV complexity, wherein the specialization of functions and operations has been counterbalanced by respective integration of these faculties. As RAY started to develop digital services alongside games, business planning was still domain-specific. Characteristically to Stratum III operational logic, the organization was siloed in separate and poorly integrated units of ICT, games development, and service development. Projects were aligned with strategy, but they focused on single distribution channels, single products, or single concepts. Decisions on products were made independently of each other within separate channels. No need was felt to consider the customer perspective across the channels. Cross-departmental product development projects were rare.
In the 2010’s, RAY has started to ask itself what its customers truly want. A watershed in the transition towards Stratum IV was in 2009, when the strategy was revised and several major initiatives, such as the online casino and the preferred customer program, were launched. These new capabilities posed a great challenge to RAY’s organization and technology platform. The programs were independently budgeted, and for the first time agile methods were employed in implementation teams.
Internet gaming and the preferred customer program entailed a multi-channel approach: the business wanted to have same products both online and in physical locations, and information on the customer was naturally of common interest. Coordination across teams and units posed great challenges to RAY’s organization, which were met with agile methods and team organization around different capabilities. In addition to carrying out the afore-mentioned strategic programs, RAY designed and started to implement a common cross-channel platform that provides functionality required by one or more distribution channels as service.
Over time, it became apparent that the new Stratum IV logic of cross-channel integration and coherence called for closer connection and better visibility between the teams and the top management. To enable decentralization of governance and interfunctional coordination, the organization revised its management model and implemented the SAFe framework. These organization-wide frameworks provides a casein-point example of overarching strategic systems that help the organization allocate its limited resources in the face of Stratum IV complexity.
Today, product decisions are made in collaboration so that channels, product managers and product development all have a say before making the decision. This approach is driven by new overall holistic thinking but is also mandated by the games that are published in several channels.
The increase in work complexity has transpired in step with change in RAY’s product market context. In the pre-Internet era, RAY was a true monopoly in its legally decreed field. While it is still the only operator of physical slot machines in Finland, the monopoly is challenged by the proliferation of online casino games and other digital entertainment that are available to consumers worldwide. The customers’ preferences are more fluid and technological change is more rapid than before. As a result, quicker responses are required to adjust RAY’s comprehensive provision.
The development process has evolved accordingly. When business was still project-based, systems were developed by vendors on a one-off basis, resulting in suboptimized, siloed solutions. Architecture was an emergent outcome and not planned from product portfolio point of view. Today, enterprise architecture embraces all systems that have both a business owner and a technical owner, and products are designed with respect to the portfolio and its objectives. A product owner plays an important role in the development of critical systems. He/she is responsible for developing the product throughout its life cycle and has a team of in-house developers and testers as well as external consultants, if needed.
Finally, the scope of agile has grown. In the past, teams were responsible for systems underlying RAY’s machines. Integrations between these systems were based on configuration-, reporting- or fault information, but product specifications did not span across systems. The adoption of agile methods started in these individual teams. However, they soon formed enclaves of high-quality, agile software development that stood out from the surrounding organization. At some point, the teams begun to have increasing demands towards the rest of the organization, which had become the bottleneck for further increases in quality and performance: strategic development, concept development and prioritization took too long and were often of inadequate quality to high-performing agile teams. This prompted the adoption of SAFe at RAY. Nowadays, product or service development increasingly entails inclusion of several systems. This calls for inter-team coordination, portfolio management, and governance. In the early 2000’s, after decades of relatively stable and predictable business as usual, Finland’s Slot Machine Association (RAY) increasingly started to sense the disruptive forces of digitalization in the gaming business: overseas online casinos as well as changes in consumers’ preferences, use of time, and playing behavior challenged the status quo and forced RAY to respond by upping its ante (pun intended). In just a few years, the organization invested in new technology; developed requisite organizational capabilities to match new requirements of 24/7 availability, information security, and agility; and managed a transition from a steady operator to an agile innovator. Seen against the theoretical backdrop of Levels of Work [e.g. 1,2,10], this can be seen as a shift from Stratum III to Stratum IV complexity and capability.
We surmise that SAFe provides a “scaffolding” that helps the organization develop
its software-based products and services in an agile and lean way. It enables scaling
agile product development to the team-of-teams (i.e. program) level and further to the
portfolio level [
With its adaptation of SAFe, RAY is well geared to establish continuous, agile product development in the future. Further work is needed, particularly in developing the concept development process and in fulfilling the customer needs. Too many layers still exist between the customer and the product development team, which inhibits a more direct feedback loop between the two.
It is to be noted that the proposed Agile Product Development Maturity Framework (APDMF) is based on theoretical contemplation and only tentatively tested trough this case study. As such, it will need more empirical corroboration and further theory building. We view that the framework is not only of theoretical interest but bears a number of practical implications. The framework would provide a yardstick that helps managers and other practitioners assess and address capability requirements in order to further develop the organization’s product/service development vis-à-vis the organization’s product market. If developed further, it has potential to inform the development of product development capacity by providing insights into the types of competencies, systems, structures, and respective investments that will be needed at a given stage of development. For instance, it can be argued that a dynamic product market would call for a modular approach, which, in turn, would require Stratum V product development capability. In the case of RAY, this will not be required in the foreseeable future, but if it ever will be, insights into work complexity and requisite capabilities will be helpful in informing how to navigate the organization to the next level of complexity and coherence.