The Allegro Group way to agility
IT Governance and AgilePMO Manager, Allegro Group
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.
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).
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.
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.
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.
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.
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.
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:
- Project Manager as medical patch – in the old system motivated Project Managers were spot on. If something happened on projects, the guilty person was always the project manager. If some project member was not so motivated, then the project manager tried to do the job for this person. If there was a problem on a project, it was the project manager’s task to solve it. Lots of tasks were done by the project manager, instead of project management. In the new system, the Project Team is spot on.
- Project Owner low availability – we’ve seen many times the business attitude, referred to as “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 time for a project, why should the project manager or team have the time?”
- For many years we were struggling with team members’ availability due to multitasking, team members were working on few projects. Now there is a rule: first the Team, then the 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 project manager and in the reporting system. Now we have Review Meetings during which team members show results of the work done in front of the stakeholders.
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.
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.
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.
J-Curve. (2013). In Wikipedia, the free encyclopedia. Retrieved from http://en.wikipedia.org/wiki/J_curve
Project Management Institute. (2012). PMI’s Pulse of Profession™ — Organizational Agility in Depth Report [Electronic Version]. Retrieved from http://www.pmi.org/~/media/PDF/Research/Organizational-Agility-In-Depth-Report.ashx
SDLC. (2013). In Wikipedia, the free encyclopedia. Retrieved from http://en.wikipedia.org/wiki/Systems_development_life-cycle
Sutherland, J. (2008). Power scrum: Secrets to a good meeting. Retrieved from http://scrum.jeffsutherland.com/2008/10/agile-contracts-money-for-nothing-and.html
©2013 Michal Raczka, PMI-ACP, PMP
Originally published as a part of 2013 PMI Global Congress Proceedings – Istanbul, Turkey