Bwin.party (now part of GVC)

(June 2013- August 2014)

Background

Bwin.party Digital Entertainment is the world’s largest listed online gaming company, with revenues in 2013 of €652.4 million and 2,770 employees worldwide. The company resulted from the merger of bwin Interactive Entertainment AG and PartyGaming Plc, completed in March 2011. In 2015, it was purchased by GVC

The company creates its own real money online games and its own gaming platform, and is operational in several markets around the world. The go-to-market product lines are focused on Sports betting, Poker, and Casino games, all of which depend upon a common platform for basics such as player identification, account, wallet, and compliance.

The product development was distributed between Hyderabad, Vienna, Gibraltar, London, Stockholm, Kiev and Vinnytsia (both in Ukraine), and Sofia (Bulgaria) and Kluj (Romania).

I was hired in mid 2013 as Group Head Product Governance, with a primary focus of leading a lean and agile transformation of the company’s product and development organization.

Following the merger, the company had not, yet, settled on a common development approach, and the structures, cultures, technologies, and beliefs of the pre-merger companies were still largely intact. There were a number of cross-site technical and service dependencies, in particular from the game development sites in and many of the development sites depended upon remote product management. The lion’s share of development effort was often focused on modifying the code base to adapt to a specific new or recently changed market and regulatory environment, with tight time pressures and evolving requirements, creating the conditions for the “contract game” to be played between component-based development teams, project management, product management, marketing, and general management.

The strains over time, which had their roots in the organizational designs, resulted in a lack of trust, a substantial cultural rift that needed to be closed, especially between sites. Other areas of opportunity for improvement included:

• duplication from alternative (.NET vs. Java) platforms
• technical debt expressed in large backlogs of known defects
• inadequate and out-of-date development skills and build practices that were continuing to produce still more debt
• competitive concerns
• regulatory deadlines
• need for alignment in portfolio and product management on priorities and focus.

The key stated goals that motivated the change to an agile development approach were to:

• be able to release more frequently
• improve quality in product that is released
• shorten feature cycle time
• improve flow

My background before joining bwin.party, and the reason that I was hired, was that I had deep experience in lean and agile transformation programs. I had previously worked at both ThoughtWorks and Valtech, consulting firms known for their leadership in lean and agile delivery, transformation, coaching and training. At Valtech I led agile transformations for several of our large clients, including Alcatel-Lucent, Schneider Electric, and Michelin, and had the good fortune to work in depth with Craig Larman there. At ThoughtWorks I had management responsibility for the US West Coast, and for major clients who were customers of agile delivery and co-creation services. I am quite experienced in working with large, distributed and complex product development organizations in the process of transformation towards lean and agile, and the opportunity to lead this change at bwin.party was personally very motivating.

I worked closely with Craig Larman at Valtech, where he served as Chief Scientist and where I led Agile Services globally (among other roles), beginning in 2006 when I joined the Paris office. We worked together at Valtech India (in Bengaluru) to help develop applying Large-Scale Scrum (LeSS) to offshore development, and very deeply together with Alcatel-Lucent, where I gained applied LeSS “Huge” training and coaching experience. I spent more than 3 years there teaching, coaching, and applying LeSS in the Fixed Access and Wireless product divisions at Alcatel-Lucent, and have also taught and coached LeSS at Schneider Electric and other large product companies.

Guy Duncan, who served as CTO of Valtech US while I was there and who then hired me at bwin.party in his role as the group CTO was one of the key sponsors of agile transformation at bwin.party, as well as a major direct contributor to change and innovation. His insights and leadership were important factors in our success, as was his support for LeSS.

Starting the LeSS Adoption

At bwin.party, I began by “going to gemba”, touring and observing the key sites of the company, meeting directly with the development teams and product managers at each major site who are involved in guiding, creating, testing, deploying, and supporting the products and gaming platform which the company operates. I also met with the executive sponsors, key stakeholders, product and development management and individuals throughout the organization in HR, client service, marketing, legal and finance, in order to try to understand the company structures, culture(s), and the group dynamics, and to plan our efforts. From experience, I know that it is essential to have both top down and bottom up support in a large adoption, to prepare for the sometimes hard change to come.

Larman and Vodde’s first two books on LeSS (the “Scaling Lean and Agile Development” series) were made required reading for a large population in product development, product management, and the leadership team, to provide a shared context and vocabulary for agile, lean, and LeSS. This was part of “step 0” in the LeSS adoption guide Getting Started: educate everyone.

I quickly ramped up a team of expert consultants, trainers and coaches, with a model of pairing external experienced and vetted coaches with a small internal team of coaches and trainers who had agile experience, who were motivated to help do the heavy lifting ahead, and who convinced me that they had the necessary mindset and skills to contribute. We worked primarily in pairs, with intensity and focus, by site and by product line.

From experience, I knew that we would need to provide intensive coaching support for each product’s management and teams over several months at each site, and that individual coaches rarely can support more than 4-5 teams each for these initial months. I also shared the LeSS adoption guide to to go “deep and narrow over broad and shallow” with one product line, rather than wide (and potentially superficially) with many at once. So we went “deep”, rather than “broad”, with most of our effort, while maintaining a communication effort at the corporate level and supporting broad transparency via webcasts, newsletters, and collaboration platforms.

While coaching style varies naturally as each person uses their personal wealth of experience in the context of their work, it is very important to align a coaching team on the approach we would take. I brought in two seasoned coaches who had worked with me at Alcatel-Lucent and who knew LeSS, XP practices and who had experience with DevOps, I engaged with an agile consulting company in Hyderabad that had a coach experienced with LeSS from Nokia Siemens Networks and several others willing to learn, and we engaged Craig Larman for a two week intensive workshop in Vienna, with both senior management and development teams. All coaches had to first read the first two LeSS books (from 2008 and 2010), and I personally interviewed and tested the knowledge of each coach to insure a high level of common understanding.

Innovation Games

I found an opportunity to work together with the executive team (CEO plus direct reports and heads of product and technology), whose support I know to be essential to an effective transformation. I asked Luke Hohmann, CEO of Conteneo and author of Innovation Games™ and someone I trust and have worked with several times in the past, to come in to facilitate a workshop to help set our portfolio strategy. We spent 3 days in a workshop in Gibraltar, poring over the forecast investments to be made, or not to be made, in the next 18 months, using Prune the Product Tree and Buy a Feature games, both in person and using the Conteneo digital platform. We successfully sharpened the focus and aligned the leadership team on upcoming key initiatives and their priorities, which provided needed input to sizing the forthcoming product organization that was designed according to LeSS. A secondary objective of this meeting was to increase the collaborative decision making capability at the top, trying to contribute to building a tighter team with shared vision, and to gain a shared understanding of the benefits of working collaboratively, visually and in an intensive workshop setting, and this objective was also satisfied.

Changing Structures, Roles, and Responsibilities

We worked on an ongoing basis with the executive sponsor team to agree on the main initial improvement goals of the transformation; given the size of the coaching team, we needed to select our initial site and product focus to get started. We decided to first work with the Sports product organization, queuing up Poker and Games to follow, in part because of Sport’s relatively greater experience with “Scrum”, to increase the odds of a first “success”, and in part because of the relatively high dependence of Poker and Games on the common platform, which was, itself, in need of very significant organizational and technical change which would take more time and delay our change. I wanted to focus in a part of the organization which could experience improved end-to-end delivery using lean and agile thinking, and which could subsequently have a strong impact on other parts of the organization by sharing experience and learning.

The pre-existing organization had an emphasis on site-specific hierarchy, with as many as 7 levels in some sites, and significant overhead, in particular in our largest development site, Hyderabad. None of the senior managers in this hierarchy in India were experienced with lean and agile methods, and certainly not with LeSS. They had some idea that change was coming, but were not ready for the extent and depth of change. There was significant resistance among some of the management team there. Within several months most existing management roles were eliminated, those remaining were focused on mentoring, coaching and continuous improvement, and most people found themselves within one of nearly 100 new self-designed and self-organizing cross-functional teams in a flat organization. Those who decided to leave the organization were well-treated and assisted in finding other opportunities.

Most teams were grouped into product and requirement areas, following the patterns of LeSS Huge.

The products varied widely in their number of teams, ranging from one to dozens of teams. In the products that adopted LeSS, no product had more than six teams working on a single backlog. For those products that adopted LeSS Huge, the number of requirement areas varied from two to five, with from two to six teams per requirement area and APO. Each product had one Product Backlog and one Product Owner. The Product Owners of all the products were part of a new Product organization (an evolution of the prior Product Management organization), and they were supported by Area Product Owners for the requirement areas. Naturally, there were also Scrum Masters, one for each two or three teams.

The creation of the new Product organization was the subject of much deliberation, and this organization took longer to establish than did the self-designing team formation. Active communities of practice were formed for scrum masters and automated functional testing, each of which had a nominal site lead (a part-time role).

“LeanOps” and Handling Technical Debt

As DevOps had become a strong interest area for the organization, a parallel and aligned initiative began to introduce DevOps thinking and practices. A workshop including people from each of our development sites was conducted in order to develop a Value Stream Map for our development processes by product line and for the platform. Non value-adding activity was targeted for elimination or reduction in order to shorten overall product development cycle time and to improve the value ratio. Particular attention was paid to reducing and finally eliminating the use of branches so that teams could work directly on the trunk, to automating the creation of environments that had previously been built and maintained manually, and to the reduction / elimination of defects that had accumulated over time. There was fairly painful deliberation over what organizational model to use for work related purely to technical debt reduction.

Strong advice was given and reinforced to use regular teams working in rotation in Kanban mode to resolve defects that made it outside of development Sprints, with a small triage group to route items and prioritize queues. Management felt very strongly that a persistent focus should be kept on technical debt reduction; the result was that some teams were placed temporarily into a separate “LeanOps” group. It was called “LeanOps” and not DevOps to avoid the impression of jumping onto the DevOps cargo cult bandwagon. DevOps – says the creators of the term – implies the elimination of a separate group, and ultimately you should not need to have a separate area for it. The LeanOps group was viewed a temporary (~6 month lifespan) group outside of the product organization, managed separately in terms of backlogs which were prioritized by LeanOps service owners reporting up to the CTO and the portfolio function.

As there were not enough deeply experienced functional and technical experts for all of the teams, in some cases individuals who were normally members of long-lived feature teams rotated in and out of the LeanOps teams. This particular pattern did not make the individuals involved at all happy; with the help of Scrum Masters, these teams moved towards a pattern with the whole team staying together and “pulling” defect items into their Sprints instead of having the team disrupted.

After several Sprints, a groundswell of self-determination led the Sports product organization to successfully propose that regular Scrum feature teams would stay together, and pull LeanOps work (bugs and other technical debts) into their Sprints, serving on rotation, usually working in Kanban mode on LeanOps items for 1-3 Sprints, returning after to working on regular new feature development from items prioritized directly by their Product Owner. Actually, this approach was the one originally suggested by Craig Larman, and it illustrates the point that oftentimes a group has to come to a conclusion through their own struggles and learning.

Over time, the portfolio function matured to permit dynamic rebalancing of a mix of technical debt reducing allocation and strategic new product initiative focus. Strong leadership and involvement in the transformation by the company’s chief strategist was critical for giving teams, managers, and the overall organization time to learn and improve, and to provide leadership for what was, and was not a priority to work on.

HR Challenges and Support

In any ambitious transformation I know of, there are bound to be problems, which is of course what makes this work appealing and interesting! The most intractable of these are usually people problems, and usually more painful the higher in the organization the people are. At bwin.party, I found that the surprisingly deep involvement and willingness to learn and change on the part of most of the senior team, who we directly coached and collaborated with, was an effective force. This change is especially difficult, as it requires critical and at times public self-evaluation, and is especially valuable, as it can help to renew the trust and dedication of employees.

The HR department in many organizations is under-leveraged in lean and agile transformation, and can be seen as a source of trouble by lean and agile coaches, in particular when a company is going through an intentional downsizing. To fault the HR department, however, is likely to misunderstand the economic reality of a company’s position; they are often foot soldiers, carrying out a mandate given to them to control costs. Clearly, we would mostly like to be able to grow out of the economic problems that lead to cost cutting, but this often does not happen, or not fast enough. The problem presented by a difficult economic situation and a strategic decision to focus the company’s activities more narrowly geographically created an opportunity to revisit site strategy and the qualities that we sought both individually and organizationally.

Informed in part by lean thinking, we achieved some cost savings through reducing the number of sites, and substantially more by a reduction in headcount.

Our HR leadership became a very powerful source of lean and agile leadership, and the agile transformation of HR, itself, became a coached and trained initiative to produce self-organizing, cross functional HR teams, co-located at each major site, with a reduction of management overhead and a flattening of hierarchy. This change of a service organization, while not the traditional product development organization that is the focus of LeSS, led to a more effective cultural change and an organization better able to nurture the development of agile leadership.

Some Outcomes

Nearly 18 months into the transformation, it is possible to look back at what we have achieved:

• Feature time-to-market has been reduced
• Ability to release frequently has been increased
• Technical debt has been reduced
• Reactivity to portfolio prioritization is much improved
• Work-in-Progress has been reduced, and projects can be started and stopped faster
• Morale is strongly improved within and between teams
• Trust between sites is improved
• The dispersion of development over many sites has been reduced
• We share a common language, product cadence and priorities
• Global product and technical leadership is visible
• Site and organizational-level impediments are made visible and worked on by leadership
• Innovation games have become a common tool for people to use at each site, and the online games have proven useful for large scale distributed retrospectives, feature prioritization and problem identification and resolution

The change at bwin.party has been due to the individual efforts of the people at all levels, including a substantial number of new leaders and long term contributors. The company is determined to continue to improve continuously, and to strive to provide cutting edge digital entertainment to players and partners in the markets that it serves.

The lean and agile transformation we have undergone helps to make bwin.party a stronger, more flexible and more viable competitor, and I believe that it has been well worth doing.