iZettle replaced their legacy CRM systems with off-the-shelf solutions using Agile contracting. The enabled them to go from idea, to working solutions in just 6 months. An interesting aspect of the challenge is that this involved updating critical business processes, around the globe. We interviewed Maria Izzo (Automation Lead) to learn how they did it.
(this article is also available in swedish here)
”As you create human connections, you also create bonds of responsibility.”
– Maria Izzo
What is iZettle?
iZettle is a provider of commerce solutions, with focus on small businesses. If you have paid with a credit card in a cafe, to a taxi driver or a craftsman, you’ve likely used our solution. You’ll find us in markets stretching from the EU all the way to Central and South America.
Tell us a little about yourself?
I work at iZettle as the Automation Lead, a recently formed team with the mission of contributing to scalable growth by delivering innovative ways of working and equipping iZettlers with tools to thrive in their roles.
The multifaceted nature of my background tells the story of a person who loves to learn, be curious and see the world: from marketing and communication to research and economics, from photography to financial services, from iZettle’s risk department all the way to the tech one.
I know that you have just finished a project where you used Agile contracting. Tell us a little bit about the background to the project?
Upon the acquisition of IntelligentPOS – better known now as iZettle Pro -, we realized that we had ended up with two CRM systems (Salesforce instances) used differently in different locations. We wanted to simplify iZettlers’ lives and replace the two instances with a global, enhanced one.
In a hyper-growing company like iZettle, the business processes in place grow organically at the speed of light and vary a lot. The merge was our starting point: some of the business processes used across our 12 markets ranged from existing but unmapped and highly manual to unclear and redundant.
One of the most exciting challenges with replacing a big system like a CRM in a fast-growing company is that you are doing it in an environment where people are busy running operations: from Sales to Support, from Risk to Marketing, they all work on the same system in very different ways.
The key people you need to run your daily business are the same ones you also depend on in order to improve it. Hence, any system replacement that you plan to do, has to be done swiftly, smoothly and with minimal disruptions; and things become even more exciting when processes evolve simultaneously with the tools you are re-implementing!
So to summarize the effect goals:
- Merge two customized Salesforce systems into an enhanced one.
- With the new system in place, harmonize and automate several business processes in order to make life easier for our different business units.
What were the main reasons for going with an Agile contract?
We knew that there were some key areas of uncertainty when we decided to start the project:
- The lack of uniformity of business processes across operational business units.
- Uncertainty on which exact functionalities our stakeholders considered the most valuable.
- We didn’t want to waste time and an Agile contract would enable us to gain in flexibility – both in terms of time and budget – and hit the ground running, without losing momentum after the initial discovery phase.
- Finally, the initial proposal and estimate we got for the project from our providers were sensibly high, so we asked ourselves how we could get the best out such a deal.
Given our situation, using Agile contracts seemed like the best solution and this approach granted us a number of benefits:
- There has been a high degree of flexibility with regards to prioritisation and workload over the sprints, during the whole course of the projects.
- A much greater level of control over budget and a lower risk of cost overrun, provided both parties deliver as per the agreement.
- It does, however, mean that more attention is needed to ensure that the objectives (at the end of the project) are achieved and signed off by the customer.
Let’s take a look at the overall timeline and the key steps:
| Phase | Steps |
|---|---|
| Initial discovery | Analyzing and mapping out our business processes. Select provider. |
| Sign contract | Negotiate and sign the Agile contract. |
| Kick-off | We organised a kick-off event, to bring together a cross-functional team, made of individuals who were running this project as their “night job”. This mattered because as you create human connections, you also create bonds of responsibility. |
| Implementation | Build up our new CRM environment. Continuously evaluate and demonstrate in a pre- production environment. Run acceptance test scenarios. |
| Go live | Switch over from our two legacy CRM instances to the new solution. The Automation team takes official ownership of the solution. |
| Continuously improve business operations across all markets ("bus.ops") | Across markets around the world, improve and automate business operations using two week cycles. Prioritization of highest business value using our "Thunderdome" concept (see below). |
The keen observer will notice that this is a very rapid timeline, from idea to continuously improving business operations (including replacing two legacy systems) in just six months.
As a customer, what prep work did you do before signing the contract?
The main bulk of the work was mapping out our business processes. We did this mainly on our own with a little help from a provider (who was paid using time and materials).
Then we needed to select which provider to go with, so we compared some alternatives. At the end of the day, we opted to go with a provider we had previous experience with and whom we knew had deep and reliable knowledge of the CRM system we were working with. We asked them if they would be willing to sign an Agile contract with us and they were keen to.
At the end of the day, this enabled us to keep the pace up and sign the contract just over a month after having started the initial discovery.
What was the reaction from the provider when you suggested using an Agile contract?
They were positive and open to using an Agile contract. They knew that if they did it right, that would open the door to other projects down the road. Fast forward to today, we are now working together on our fifth contract. So one can say that it has certainly paid off for both parties.
Let’s walk through some key elements of your contract
| Element | |
|---|---|
| Pricing | In the contract, we agreed on a basic fixed price per day for the provider during the lifetime of the project with reward share in case of an earlier delivery. |
| Timeline and milestones | Timeline with milestones plus a predicted go live date (Q1 2018). |
| Value and risk sharing | We used a basic target price model whereby if the end deadline was missed, the price of consultancy per each following day would have no markup (just covering costs), whilst if the end milestone was reached earlier, the remaining budget would be equally shared. This provided a shared incentive for both parties to deliver on time or even earlier. |
| Participation of key people | The provider guaranteed that the people they staffed the project with would not change (except in cases of force majeure) until the end of the project. The provider also guaranteed that the handover of knowledge would happen in the event that a member of staff took time off for vacation, for example. As a customer, we had the option to replace people in the project in the event that collaboration didn’t work out. |
| Project structure | Definition of key roles from the provider and from ourselves as a customer (see below). |
| Conflict resolution | When the contract was being drafted, we consulted Mattias (Crisp) to soundboard ideas and we ended up stealing a few ideas from him for this section. - People with a conflict have to try to resolve it (ideally by simply taking a walk together) before escalating it. - If the conflict remains unresolved, a mediator not involved in the project must be selected by the conflicting parties. - The final step includes escalation to the steering group. As it turned out we never had to invoke the final step, as we worked incredibly well together :). |
Did you have conflicts that you had to resolve?
Yes, once: we realized that we and our provider had different understandings of what ”done” meant. The good news was that as soon as the problem emerged, we could easily discuss it, take corrective actions and resolve it. One key lesson learned that we took into a following project – spin-off of this one – was to establish a shared understanding and definition of “done” between all parties already at the contracting phase.
Can you elaborate a little bit about the project structure (the key roles)?
Absolutely. Let me highlight the key roles:
The provider had a project manager and two system specialists focussing on different business areas of the CRM (Sales and Service) plus a general system specialist (wildcard). Combined, this meant that the provider had in-depth knowledge of the inner workings of the off-the-shelf CRM system we had chosen to use. Apart from following up on the progress on the timeline, the provider was also responsible for keeping the budget burndown chart updated at all times. This enabled us to follow up so that there wouldn’t be any unexpected surprises when it came to the budget.
For us as the customer, our participants were our Business Sponsors and Project Lead, me as the Project Manager leading a cross-functional team made of the provider’s consultants, two CRM Admins, two Tech and Data teams responsible for building integrations with our internal systems, four stakeholder business units (Sales, Support, Risk, Marketing) each one of them made of several geographical units distributed across the globe.
The geographical units collaboration was actuated step-by-step as the project progressed. During the implementation phase, the business units committed to active participation in acceptance testing and sharing scenarios for validating the business processes. The same stakeholders (a few per business unit) committed to training their staff on the updated versions right before the ”go-live” date, with using training material provided by the cross-functional team working on the project.
When we switched over to continuous improvement of our business operations (”bus.ops”) after going live, the collaboration among business units was intensified. Today, we improve our business operations using a shared 2-week sprint rhythm.
You mentioned the ”Thunderdome” concept earlier, can you elaborate on this?
Sure! A key ingredient inside ”bus.ops” is learning how to prioritise. The Thunderdome is our approach to determining – out of many requests coming from – the highest value we can deliver for iZettle in the next sprint. We generally run this 2 or 3 working days before the next sprint starts.
The name originates from the namesake Mad Max movie where ”two men enter, one man leaves” the Thunderdome. In our case, it’s a tad less dramatic :).
Our approach is more like: ”Several user stories from different stakeholders enter our backlog, and only some of them are delivered during the upcoming sprint” so they “fight” in order to determine (by walking in each other’s shoes) what are the true priorities for iZettle to be delivered in the following two weeks.
How do we do it? We use a shared digital board and meet up on Google hangouts for an hour at a fixed time (quite tricky as we have to match business hours for all our markets) with all our stakeholders, or at least with the ones who have user stories in our general backlog.
The deal is that if you don’t show up at the Thunderdome, you run the risk of your user stories not being prioritised; normally the participation is high across all business units.
Each sprint, our goal is to identify and prioritise those stories that have the highest value for iZettle and that our stakeholders want our team to deliver first. This means we seldom make it all the way down to the end of the backlog, but in order to make sure that we don’t miss out on important stories, we ask our stakeholders to review their stories, update them, make sure there are no duplicates and so on: they basically do the grooming of our backlog for us.
The benefit of working in 2-week sprints is that if a stakeholder accidentally forgot about a user story that was of value, there’s a new window of opportunity to correct this in just 2 weeks.
What was the result of the project? How did it turn out?
We launched on April 9th 2018, which was just 8 days off the ideal go-live date we had planned at the start. Considering that we had to replace two legacy systems and run core business processes across markets, this was an excellent result.
On an overall timescale, we went from idea to live in 6 months’ time. From that point on, we picked up the pace even further, improving our business processes on a regular basis.
Looking back, what were the key benefits of using an Agile contract?
The key benefit was that it generated trust on both sides. This made a close, effective and efficient collaboration possible. It helped us overcome unforeseen surprises and continuously improve value delivery throughout the project’s lifetime and beyond. It also made working in the project much more fun and helped us create long-lasting professional relationships as well some friendships!
Thanks Maria for taking the time to share your experiences and insights.