The Allegro Group way to agility

Introduction

This paper is about transformation of the Allegro Group Company. “It is not about agile implementation; it is about the way to an agile state.” It was a challenge. The effort was huge, but the gain was much bigger. Personally, I was committed to this change and I am happy I could work on it. I am also happy I can share our story with you. Many more people were committed to this change and I would like to thank them. The work done has been tremendous.

Allegro Group

The Allegro Group is E-commerce Company and operates in the CEE Market. The Allegro Group comprises auction and fixed-price transaction platforms, classifieds platforms (i.e., auto, real estate, jobs, and travel classifieds), comparison and social shopping sites, as well as a payments platform. A number of these services operate across Poland, the Czech Republic, Turkey, Slovakia, Hungary, Bulgaria, Romania, Ukraine, Latvia, Lithuania, Estonia, Russia, Belarus, Kazakhstan and Serbia.

Allegro continues to expand its operations across all of the territories in which it operates with the objective of delivering the best ecommerce experience to its users. Now the whole Allegro Group has close to 150 Internet Services. In order to manage growth, there is high focus on product development and agility. Allegro Group operates in a very challenging market. Fast market changes require fast reactions. In addition there is a low tolerance for making mistakes. Because of this, there is always high attention to what we do (portfolio management) and how we do (project management and product management).

Project Management

I joined the company in April 2008; at that time there were 400 employees. Now Allegro Group has more than 5000 employees. During that time we went through many organizational changes. Since 2008 there has been a high focus on project management as way to growing business. We started implementation of professional project management in 2008. First, I was a project manager. Shortly after, that I was promoted to PMO Manager, responsible for the project management team. Over many years we were looking for the best ways to manage projects and deliver business value. We made lots of mistakes and had many successes. We first started projects without any methodology. The team used their own experience to manage projects. At that time we didn’t know what would be the best to use.

The year 2009 was the year of methodology and transformation. During this year we transformed from an IT PMO to a Business PMO and we implemented first formal project management processes. The year 2010 was a year of maturity. While using a traditional approach we reached the fourth level of project management maturity on a few of the most important processes. During the maturity year we made lots of mistakes. One of the main ones was to put too much focus on project management mechanics and less on people. Another example was to have a heavy change management procedure. The year 2011 was the year of the Corporate PMO and Collapse PMO (C&C PMO). There were plans to have a PMO in every main site of the company and have common international tools to manage projects. We’ve even chosen and implemented these tools. Every year we made lots of improvements (kaizen). Each subsequent improvement (change) was treated as an optimization without a big gain. This is what happens when you reach the four level of project management maturity. We needed a revolution in order to make a huge step forward (kaikaku). And a revolution was done, but at the beginning with little PMO involvement. We started our way to agility. As an organization, we were much pressure from business. We knew that there was no chance to deliver what was needed using our current SDLC process. SDLC was our core Software Development Process (waterfall). It was the most important process for an e-commerce company.

Transition

During this main organizational change we’ve transitioned totally to agile organization. Everybody was involved, including managers and senior directors. Commitment to agility was and is very strong. For example, even the HR department is working using Kanban. We also changed the architecture of our new building in order to have special creative rooms for teams (i.e., idea painting).

We’ve transformed from THE waterfall (SDLC) process to agile. We started the transition in July 2011 with the first Scrum team – we treat this as a PoC. The team was collocated, done by the book, very fast and very open to change. This team was working within a traditional environment. Due to this, we experienced “two clocks issue” when one team is willing to be fast in order to meet business requirements, but the whole organization is not ready for it (for example, Infrastructure Department works based on SLA, that is longer than the sprint timebox). This PoC failed. We were calling it “fragile.” “Fake Agility Leads to Fragility” First of all, we were unable to communicate properly. Years of living in caves of specialization on different floors created serious problems. We were accustomed to communicate using documentation. We gently avoid talking face-to-face. And now we were forced by agile to conduct face-to-face meetings with this entire people, which we prefer to meet only when worse comes to worst.

What’s more, despite the fact that we were working in sprints, our sprint was just a mini-waterfall. We could not think in terms of user value, because we were accustomed to slice software in a horizontal way. So, we were not able to deliver real customer value, because first we were developing business logic, then user front-end, and, finally, our code were sent for testing. Another problem was about our availability for the first Scrum project. Despite the agreements, that all our team is full-time dedicated to the project, the reality was different. During every sprint we were facing a parallel stream of small different requests, which was absolutely distracting for the team. It was stuff like bugs, small maintenance tasks, meetings, and other consultations.

PoC was a very important turning point within transformation. Another point came from business representatives. They wanted to implement a new strategy, and they knew it is not possible to do it using SDLC process. Right after it, the management (business and IT) of the company met together in order to prepare Allegro Group for one of the biggest changes. We (Transition Team) decided to use Scrum as our approach to change. This was the best way to introduce Scrum framework within company. We’ve found an experienced enough agile coach and started with trainings for all levels of company. Concurrently, we built a Scrum Transition Team (IT and Business Management) and started to work on change using weekly sprints. We were committed to the change, even in many operational duties. Everybody knew this is most important task in front of us. Our backlog was built from many stories. The most important ones were connected with getting rid of silo departments and building interdisciplinary and independent Scrum teams. We also had to prepare infrastructure to comply with it.

My role as a PMO was to secure all projects in the portfolio and transfer them from Project Managers to future Product Owners. We did a huge exercise to agree on how and who will join each particular Scrum team. In the very beginning we agreed on 10 teams (now we have a few dozen). We had to decide who will initially be a ScrumMaster and Product Owner. It was a very hard task, like changing from a Project Manager to ScrumMaster. On a business level, we struggle to find proper Product Owners who will be able to decide on business needs. Before we changed, we had many different silos within the SDLC process. Because of this we decided to have 11 people teams in order to gather every role. This was one of the first mistakes—too big teams were not as productive as we expected. At that time we found out how transparency works. When we broke silos, it was obvious some departments were much bigger than others. We had to find balance. Taking into account that the company was growing very fast, we decided to employ roles we lacked in order to have complete teams.

Transition Date

We set THE date – 2 November 2011 to do the RELEASE. We started moving people from silos to teams. Within two days everybody changed seats, floors, building. This was a huge administration challenge! Business people sat together with IT people. There were no longer communication problems, no longer resource availability problems. We totally changed our portfolio management. Now this is done using backlogs. Within one year we learned how to manage value. Measurements are really positive: a 200% to 300% growth in team efficiency, with four to five times faster value deliver to business. The decision on the project start is ten times faster. We moved from Project Management to Product Management—constant, iterative, and incremental product development.

System Change

Quick feedback loops and team collaboration are at the heart of agile. In order to have a successful transition, we had to change other parts of the company. This started as a next phase of transition. The first change was within operational departments (e.g., Infrastructure). In the beginning, it was monolith silos comprised of SysAdmins, NetAdmins, and DBAAdmins. Infrastructure serves many Scrum Teams using SLAs. The focus was on SLA. During the change we broke silos into product teams. A few small teams with all competencies needed to serve to Products (websites). Teams are focused on delivering as good a service as possible, and every team is using Kanban to manage tasks.

Another change was within the appraisal system. We care about people and teams. In Scrum — the team is successful. Our old appraisal system was focused on individual achievement; the new one is focused on team achievements and collaboration.

Another change was within IT Portfolio Management. We’ve seen that there are collision Business Driven Projects and IT Business Enablers Projects and both are very important. Within the old system we had the Portfolio Management Department that managed those conflicts. In the new system we decided to move responsibility for portfolio management to the managers. We’ve built backlogs hierarchy – from managers up to the CIO. For every backlog there is only one responsible person. There are also similar Business Backlogs with similar hierarchy from Product Owners up to the Chief Product Owner. Both backlogs are discussed on their levels when there is some conflict (technical, resources, etc.)

Measure What You Do

There is always a question when you are doing something, about how you can do it even better. In order to show results, we wanted to measure our results. We started to compare the old waterfall process with the new agile process. In the beginning the results were better for the waterfall process – the numbers showed that we were doing much more small projects, but much less strategic ones. An external person would think that change is bad for the company and projects; this was exactly according to the J curve. We were at the bottom of efficiency due to change. Later we knew we are on a good track and that we should be focused on our speed to deliver products. After one year, the measures are really great for the company: 200% to 300% growth in team efficiency; 4 to 5 times faster value deliver to the business; and, the decision on project start is 10 times faster. This is the lesson learned – you need to be consistent during a change.

In order to check on how employees perceived the transition, we conducted surveys. We asked one simple question: “If it would be only your decision, would your team make development in Scrum?” The results were very positive for us (96% and 92%, respectively, a few months later) of employees who would choose the Scrum/agile approach.

Tools

KISS — this was our approach to tools. We knew transition alone would hard, so why have another hard and unknown point as tools implementation? Before the transition we used the JIRA tool to manage portfolios and projects. Our employees knew how to use it. In order to avoid friction, we decided to use JIRA to support Scrum development as well. There is an addition to JIRA — Greenhopper. Both tools fit our requirements and they are also very good for Kanban teams.

The PMO Challenge

During time of transition I had the personal challenge of managing change within PMO. This was very important, because there is no Project Manager role within Scrum. Scrum is really great when it comes to software development but it doesn’t always fit into every project context. What is important is that Scrum really fits into product development, not strictly project management. During the transition we were not so sure what would happen. There was uncertainty about the Project Manager’s future within the company. Team members were asking about their jobs. For a short period, this was not a happy situation. I knew I would not need as many Projects Managers for other projects as I would need for software development. Finally, nobody lost his or her job. A few project managers decided to become ScrumMasters, which was no easy task, but they successfully managed it.

From that time the PMO team was responsible for projects called Business Enablers managed within the IT Department (e.g., implementations of CRM, ERP systems, New DataCentre, connect all offices within Group, Merging companies). These projects require very strong Project Management competencies. The challenge was to implement new agile approaches to project management processes.

How do you manage projects and use an agile approach? Can all projects be managed using an agile approach? What is the role of agile projects manager? We work with suppliers – how do we manage contracts? All those questions required answers.

We decided to do changes in small steps and we agreed that all projects should be managed using as lean and agile an approach as possible. We decided to try hard and use an incremental and iterative approach in every one of our projects.

My approach was to release all rules in order to open the team up for creative solutions. Every project manager was able to manage projects using his or her own project management style. Only what was required was an agile approach. We tried very hard to adapt to the new processes. We made a few mistakes in the past and wanted to change. Following are some examples of these mistakes:

After one year, we decided to agree on one common process. We call it: Agile Project Management Process (Exhibit 1), which is consistent with Scrum, but modified to strong use of project management.

Exhibit 1 – Agile Project Management Process

External Suppliers Context

One of big challenges we faced as an AgilePMO was managing external suppliers and contracts. Almost every project we managed is realized with external suppliers. This requires a contract and much money is involved. The best choice is to have fixed-price contract, but how can you be agile under such circumstances?

Our approach was to work together with lawyers to introduce a few contracts needed for projects. We used this famous quote: “Money for Nothing and Change for Free” (Sutherland, 2008). Using this approach, we put two types of contracts into place:

- Buy the sprint

- Time and material with fixed price and flexible scope

Thanks to this approach, we were able to finalize one of the projects within two months instead of nine months. There was strong collaboration with the supplier and we prioritized heavily needed features. After two months, it appeared we didn’t need more than we had at that time; and there was no point to continue because users of the system were happy.

High Agility

According to PMI’s Pulse of the Profession™, now there are fewer companies with high agility than in the past (PMI, 2008). During the transition we realized why it is so hard to achieve high agility. It is not about doing agile, it is about being agile. In the beginning we were focused on the mechanics of the Scrum/agile. But this is only 20% of the success; the remaining 80% is culture and people. High agility means for us openness to change, looking for quick feedback, and acting and adapting to new situations. Every new team starts with a one-week sprint/iteration. This short time is needed to learn fast or fail fast. Our focus is to have the possibility to change projects or features in a maximum of two weeks – from idea to implementation. We want to be agile as much as possible. We want to keep high agility.

What Next?

The Allegro Group way towards agility was full of ups and downs and it seems promising, but we are fully aware that we haven’t finished yet. As Churchill said in 1942: For us, it’s only the end of the beginning; there is always room for improvement. We still can do it better. We believe we are on a good path to continuing our story.