Allegro Group agility and agile data center project

img

IT Corporate Director, Naspers Group/Allegro Group

Introduction

This paper is about the transformation of Allegro Group. It is not about Agile implementation it is about way to 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. Their work was tremendous.

Allegro Group

Allegro Group is an e-commerce company that operates in the CEE market. Allegro Group comprises auction and fixed-price transaction platforms, classifieds platforms (e.g., auto, real estate, jobs, and travel classifieds), comparison and social shopping sites, as well as a payments platform. Allegro Group is a part of Naspers Group, a global e-commerce company.

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. Naspers Group operates in Asia, Africa, South America, and Europe.

Allegro Group continues to expand its operations across all of the territories in which it operates with the objective of delivering the best e-commerce experience to its users.

Now, Allegro Group has close to 150 Internet services. In order to manage growth, the company is focused on product development and agility. Allegro Group operates in a very challenging market. Fast market changes require fast reactions. In addition, there is low tolerance for mistakes. Due to this, there is always high attention paid to what we do (portfolio management) and how we do it (project management and product management).

Project Management

I personally joined the company in April 2008. At that time, there were 400 employees. Now, Allegro Group has more than 6,000 employees. During that time we went through many organizational changes. Beginning in 2008, there was high focus on project management as a way to grow business. We started implementation of professional project management in 2008. I was the first project manager. Shortly after that I was promoted to PMO1Manager, responsible for the project management team. We spent many years looking for the best ways to manage projects and deliver business value. We made lots of mistakes and had many successes. We started our first projects without any methodology. The team was using their own experience to manage projects. At that time, we didn't know what would be the best method to use. The year 2009 was the year of methodology and transformation. During that year we transformed from an IT PMO to a business PMO, and we implemented our 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 few important processes. During our maturity year we made lots of mistakes, such as putting too much focus on project management mechanics and too little focus on people. Another example was our heavy change management procedure. The year 2011 was a year of corporate PMO and collapse PMO (C&C PMO). There were plans to have a PMO in every main site of the company and to have a common international tool to manage projects. We even chose and implemented the tool. Every year we made lots of improvements (kaizen). Every improvement (change) was treated as optimization without big gain. This is what happens when you reach the fourth level of maturity. We needed revolution in order to make a huge step forward (kaikaku). And we achieved revolution, but at the beginning we did it with little PMO involvement. We started making our way toward agility. As an organization we were under high pressure from business. We knew that there was no chance to deliver what was needed using our current systems development life cycle (SDLC[1]) process. SDLC[1] 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 transitioned totally to an 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 using Kanban. We also changed the architecture of our new building in order to have special creative rooms for teams (i.e., IdeaPaint™).

We've transformed from a waterfall (SDLC[1]) process to agile. We started the transition in July 2011 with our first Scrum team—we treat this as PoC2. The team was collocated by the book and was very fast and very open to change. This team was working within a traditional environment. Due to this, we experienced a “two clocks issue,” when one team is moving quickly in order to meet business requirements, but the whole organization is not ready for it. For example, the Infrastructure Department works based on SLA3. Time needed to have task done is longer than sprint timebox (one week). 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 communicating using documentation. We gently avoided talking face-to-face. And now we were forced by agile to conduct face-to-face meetings with everyone, which we preferred to do only when worse came to worst.

What's more, although 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 slicing 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 had to do with the availability of our first Scrum project. Despite the agreements that our entire team would be dedicated full-time to the project, the reality was different. During every sprint we faced a parallel stream of small, different requests, which was absolutely distracting for the team. These requests pertained to bugs, small maintenance tasks, meetings, and other consultations.

PoC was a very important turning point within the transformation. Another point came from business representatives. They wanted to implement a new strategy, and they knew it was not possible to do it using an SDLC[1] process. Right afterward, the management (business and IT) of the company met in order to prepare Allegro Group for one of the biggest changes.

We, the transition team, decided to use Scrum as our approach to change. This was the best way to introduce Scrum framework within the company. We found an experienced agile coach and started with trainings for all levels of the 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 all of us got many operational duties. Everybody knew this was the most important task in front of us. Our backlog was built from many stories. The most important ones were connected with getting rid of silos departments and building interdisciplinary and independent Scrum teams. Also, we had to prepare infrastructure to comply with it. My role as a PMO was to secure all projects in portfolio and transfer them from project managers to future product owners. We had many discussions to determine how and who would join each Scrum team. At the very beginning we agreed on 10 teams; now we have a few dozen. We had to decide who would initially be a ScrumMaster and product owner. It was a very hard task, like changing from project manager to ScrumMaster. On a business level, we struggled to find proper product owners who would be able to make decisions about business needs. Before the change we had many different silos within the SDLC[1] process. Because of this we decided to have teams of 11 people each in order to gather every role. This was one of the first mistakes; the large teams were not as productive as we expected. At that time we learned how transparency works. When we broke silos it was obvious some departments were much bigger than others. We had to find a balance. Taking into account that the company is growing very fast, we decided to employ roles we lacked in order to have complete teams.

Transition Date

We chose 2 November 2011 as the release date. We started moving people from silos to teams. Within two days everybody changed seats, floors, even buildings. Business people now sat with IT people. This presented a huge administration challenge, but there were no longer problems with communication or availability of resources. 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. Team efficiency increased by 200 to 300%, and value delivery to businesses is now four to five times faster. Decisions at the project's start occur 10 times faster than they did previously. We moved from project management to product management. We now have 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. We did backlog grooming exercise and created next phase transition backlog. The first change took place within operational departments (e.g., infrastructure). At the beginning it was monolith silos comprised of SysAdmins, NetAdmins, and DBAAdmins. Infrastructure provides support to many Scrum teams using SLAs. Focus was on achieving SLA not quality. During the change we broke silo into product teams. Few small teams with all competencies needed to serves to products (websites). Teams are focused on delivering the best service possible. Every team is using Kanban to manage tasks.

Another change took place 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 took place within IT portfolio management. We've seen there is friction between business driven projects and IT business enablers projects. Both are very important. Within the old system we had a portfolio management department that managed those conflicts. In the new system we decided to move responsibility for portfolio management to managers. We've built a backlog hierarchy—from managers up to the CIO. For every backlog there is only one responsible person. There are also similar business backlogs with a similar hierarchy from product owners up to the chief product owner. Both backlogs are discussed on their level when there is some conflict (technical, resource, etc.).

Measure What You Do

When you are doing something, you can always ask yourself how you can do it better. To answer this question, we wanted to measure our results. We started to compare the old waterfall process with the new agile process. At the beginning, the results were better for the waterfall process; the numbers showed that we were doing many more small projects, but fewer strategic ones. An outsider would think that this change is bad for the company and projects. The results revealed a J-curve[2]; our efficiency had decreased due to the change. Later, however, we knew we were on the right track and focused on our speed to deliver products. After one year, the results were much improved. Team efficiency increased by 200 to 300%, and value delivery to businesses is now four to five times faster. Decisions at the project's start occur 10 times faster than they did previously. The lesson we learned was that you need to be consistent during a change.

In order to check how employees perceive transition we conduct surveys. We ask one simple question: “If it would be only your decision, would your team make development in Scrum?” The results are very positive: 96% and 92% (a few months later) of employees would choose the scrum/agile approach.

Tools

KISS4: This was our approach to tools. We knew transition alone would be hard, so why add another challenge with tools implementation? Before the transition we used JIRA 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. Both are also very good for Kanban teams.

PMO Challenge

During the transition I had a personal challenge to manage change within the PMO. This was very important, as there is no project manager role within Scrum. Scrum is really great when it comes to software development, but it doesn't always fit every project context. What is important, though, is that Scrum really fits product development and 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. The team was asking about their jobs. For short periods this was not a happy situation. I knew I would not need so many project managers for projects other than software development. But in the end, nobody lost his job. A few Project Managers decided to become ScrumMasters. It was not an easy task, but they successfully managed.

The PMO team is responsible for projects called business enablers managed within the IT department. Examples include: implementations of CRM, ERP systems, the new data center, connecting all offices within the group and merging companies. These projects require very strong project management competencies. The challenge was to implement a new agile project management process.

How do you manage projects using the agile approach? Can all projects be managed using the agile approach? What is the role of the agile projects manager? How do you manage supplier contracts? All of these questions required answers.

We decided to implement the change in small steps and agreed that all projects should be managed using as lean and agile an approach as possible. We decided to try hard to use an incremental and iterative approach in every aspect of our project.

My approach was to suspend all rules in order to give teams the freedom to find creative solutions. Every project manager was able to manage the project using his or her own style. The only requirement was using the agile approach. We did strong examination of conscience in order to adapt to new processes. We recognized a few mistakes from the past and wanted to change. Examples of these mistakes include:

  • Project manager as medical patch: In the old system motivated project managers were on spot. If something happened on projects, the project manager was always responsible. If some project member was not so motivated, then the project manager had to compensate for this person. If there was a problem on a project, it was the project manager's responsibility to solve it. Lots of task were done by the project manager instead of the team. In the new system, the project team is responsible.
  • Project owner low availability: There is a common business attitude called “fire and forget.” Business people were starting projects and then didn't have time for them. Everything was on the project manager's shoulders. Now our approach is: “If business people (product owners) don't have a time for project, why should the project manager or team?”
  • For many years we were struggling with team members’ availability due to team members multitasking on a few projects simultaneously. Now there is a rule: First team, then project. There is no project without the team and competencies in place.
  • Command and control style: In the past everything was reported in front of the project manager and in the reporting system. Now we have review meetings where team members present completed work to stakeholders.

After one year we agreed on one common process. We call it the agile project management process. It is consistent with Scrum, but modified for strong usage of project management.

Exhibit 1: Agile project management process

Agile project management process

External Suppliers Context

One of the big challenges we faced as an agile PMO was managing external suppliers and contracts. Almost every project we manage is realized with external suppliers. This involves contracts and big money. The best choice is to always have fixed price contracts, but how can we be agile under such circumstances?

Our approach was to work with lawyers to introduce a few contracts needed for projects. We used the famous quote: “Money for nothing and your change for free” (Sutherland, 2008) [3]. Using this approach we have two types of contracts in 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 has appeared we don't need more features than we had at that time. There was no reason to continue, as 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 (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. At the beginning we were focused on the mechanics of Scrum/agile.

But this only accounts for 20% of the success. The other 80% pertains to culture and people. For us, high agility means openness to change, looking for quick feedback and acting on it, and adapting to new situations. Every new team starts with a one-week sprint/iteration. This short time causes people to learn fast or fail fast. Our goal is to change projects or features in a maximum of two weeks—from idea to implementation. We want to be as agile as possible. We want to keep high agility.

High agility is not only about the product you produce; it is also about how fast your organization can adapt to changing requirements and how fast you learn. After we moved to a new agile organization we didn't know what structure would be the best for large-scale products. We started with the first one and then we learned from our mistakes. Over the next 16 months we changed the structure four times in order to find the optimal one.

New Data Center Project

Airport strikes, snow-covered motorways, orders halted by manufacturers—the factors jeopardizing a timely DC4 migration were many. Overcoming expected and unexpected hurdles was not all that easy, but we succeeded using agile project Management. The effects we achieved by applying the methodology were recognized and appreciated in the Project Excellence Award 2013 with its jury hailing our project number one in the competition.

The Polish Project Excellence Award is given by the International Project Management Association Poland. The prize aims to select the best and the most effectively managed Polish project each year and to promote project management in Polish business. IT initiatives are not the only ones to be nominated for this prestigious award. Last year, the section_head was given to EURO 2012, a project dedicated to the UEFA European Championship in Poland.

In the seven-year-long history of the competition, our venture was the first to employ agile project management. We believe it was one of the key factors behind our victory. However, the APM5 as such would mean nothing without the great dedication of over 60 people who built a brand-new data center within just 9 months and relocated the whole infrastructure from its previous location.

It would take thousands of words to describe the project, so it's best if you watch movie: http://blog.allegrogroup.com/events/excellent-agile-project-management

Results

At the end of September 2013 we received the IT Leader 2013 award in the “trade and services” category—the most prestigious Polish IT award.

In Allegro Group we're continuously developing our services and the organization is growing simultaneously. We had to find a way to dynamically control and adapt the products we develop and quickly react to changes in our environment. Two years ago we decided to adopt agile methodologies. The Scrum transition of the whole organization was distinguished by the jury of the competition. This was one of the biggest transformations of this kind in Europe, and all key managers both from IT and business were involved. What's more, the Scrum transition was done with the use of Scrum. The results included: shorter time to market, close cooperation between business and IT, more satisfaction for employees.

We were also honored for the creation of our new data center, which is much cheaper to operate than the old one. Cost reduction wasn't the only goal, though. We implemented a modern architecture allowing for linear scalability of infrastructure, including maintaining the 100% security in case of any failure of any of its elements.

What Next?

Allegro Group's path towards agility was full of ups and downs and although it seems promising, we are fully aware that we haven't finished yet. Just as Winston Churchill said in 1942, for us it's only “the end of the beginning.” There is always room for improvement. We still can do better. We believe we are on a good path to continue our story. Now Allegro Group is part of a bigger group: the global Naspers Group. In order to keep momentum we divided our business into smaller business segments with global reach.

References

1. SDLC. (2013, March 18). In Wikipedia, the free encyclopedia. Retrieved March 18, 2013, from http://en.wikipedia.org/wiki/Systems_development_life-cycle

2. J-Curve. (2013, March 18). In Wikipedia, the free encyclopedia. Retrieved March 18, 2013, from http://en.wikipedia.org/wiki/J_curve

3. Sutherland, J. (2008, October). Power scrum: Secrets to a good meeting. Retrieved from http://scrum.jeffsutherland.com/2008/10/agile-contracts-money-for-nothing-and.html

Project Management Institute. (2012, August). PMI's Pulse of the Profession™ in-depth report: Organizational agility. Retrieved from http://www.pmi.org/~/media/PDF/Research/Organizational-Agility-In-Depth-Report.ashx

 

1 PMO - Project Management Office

2 PoC - Proof of Concept

3 SLA - Service Level Agreement

4 KISS – Keep it simple and straightforward

5 APM – Agile Project Management (methodology)

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2014, Michal Raczka
Originally published as a part of the 2014 PMI Global Congress Proceedings – Phoenix, Arizona, USA

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.