Agile Startups: The Berlin Success Story of Zalando
Back in 2015, Zalando – Europe’s largest online fashion retailer – introduced its flavor of Agile, dubbed ‘radical agility.’ It has proven since to be a smashing success, not just fueling the bottom line of the business, but also Zalando’s ambition to build an outstanding product delivery organization. Here's what Matteo Bovio, Zalando SE had to say on the matter:
“Over the last year and a half, we have doubled the technology team from around 800 in 2015 to over 1,600 currently. In addition to changing our business model, we also implemented a unique culture within the technology team called Radical Agility: This has seen monthly technology applications grow from 500 to over 2,000, and allows to ensure that we are hiring only the best quality.”
If becoming Agile, as opposed to merely doing Agile, is so successful, how come not all organizations are pursuing a similar path as Zalando? Certainly, there are no shortages of Agile methodologies, frameworks, and practices to choose from.
Six Fallacies that Prevent Startups from Adopting Agile Successfully
From 2010 to 2017, I worked in three Berlin-based, fast-growing startups in the capacity of Scrum Master, Agile coach, and Product Owner. ‘Fast-growing’ in this article refers to startups that are at least 200 staff members strong. Each of the organizations I worked for during my time in Berlin doubled in size each year over a period of at least three years. All these startups built double-sided marketplaces, serving B2C as well as B2B customers.
These are the lessons I've learned on how to become an Agile, fast-growing startup, and what anti-patterns to avoid at all costs.
Fallacy #1: ‘Agile’ Equals More Bang for the Buck
If you ask founders and managers of startups why they want to become an Agile organization, they typically name reasons such as:
- To become more efficient in software delivery.
- To deliver faster.
- To improve the predictability of software deliveries.
If you compare these answers to the actual benefits of becoming an Agile organization, such as:
- Outperforming competitors by creating a learning organization.
- Creating an outstanding culture by providing room for autonomy, mastery, and purpose, thus attracting talented people.
- Mastering continuous product discovery as well as product delivery.
- Minimizing risk, and improving the return on investment for product delivery organizations.
By comparing these two lists, you immediately recognize the misalignment of motives and the real Agile mindset.
Fallacy #2: No or Limited C-Level Sponsorship
The change to become a learning organization within a startup is by nature fundamental and continuous. It requires you to permanently:
- Run experiments.
- Embrace failure.
- And finally, to abandon the famous “heroic inventor” mental model.
Unfortunately, the latter is often the driving force behind the founders’ mental model of entrepreneurship although we all know that Steve Jobs did not single-handedly create Apple out of a void.
From my experience, the challenges of becoming a learning organization can only be handled effectively by self-organizing teams. Their collaboration will lead over time to a ‘team of teams’ structure. This approach requires at any stage the full backing of the C-level. A limited or lackluster support will render all efforts useless.
Equally futile by comparison to the lack of C-level support is a bottom-up approach by hacking the existing culture. It usually leads to frustration, and talented people with an Agile mindset will seek better-suited organizations elsewhere.
Fallacy #3: Everyone Loves ‘Agile’
Change is much less appreciated than innovators commonly believe. Organizations have an inherent inertia to change, which is a reason that they are successful: they provide stability.
However, stability also breeds self-interest at all levels, but particularly at the level of middle management.
There is the ‘what’s in it for me’ syndrome: why would a middle manager put his or her career on the line by supporting the Agile mindset? Taylorism – or supporting command and control structures in siloed organizations – still pays well today. It results in local optimizations and personal agendas. Also, career and CV optimization efforts are a motivation to be reckoned with.
Self-organization, on the other hand, needs a different kind of management: teachers, coaches, and mentors. And just relabeling the positions of the old middle management rarely works.
Fallacy #4: We Know What to Build
This issue applies to both established as well as new organizations. You will often find a strong cognitive bias at the founder and management level towards the future direction of the product.
The bias tends to be reaffirmed if things work out (“I was right, and I will be right in the future”), or it will be rationalized in the case of failure (“Something went wrong that no one could have foreseen”).
Consequentially, the bias often results in micromanaging the product delivery organization. Also, it will nurture ignorance towards opportunity costs or costs of delay as strategic concepts.
Fallacy #5: Scale Like Spotify
“I don’t understand the fuzz about Agile coaching, and aligning the rest of the organization with product development. Once we are Agile, we will copy the Spotify model and scale accordingly.”
There seems to be a belief even among informed stakeholders that scaling an Agile organization can be achieved by simply going through the checklist of another successful startup. One of the favorite blueprints for that purpose is Spotify.
However, according to Henrik Kniberg – one of the head coaches at Spotify– it wasn’t that easy:
“[It] wasn’t a big remake, more like a continuous stream of small iterative improvements to our organization and process. We have been growing for three years, and the way we work today has evolved naturally over time.”
The truth is, you cannot just copy the Spotify model. This organization was built with such an idea in mind from the beginning, and yet Spotify needed to find its way. This “way” is what every other organization needs to figure out on its own: how to become an Agile organization?
Fallacy #6: We Need a PMO for Product
A PMO – short for project management office – signals to Agile practitioners that:
- You have a command and control mindset.
- You are a Taylorist at heart.
- You consider functional silos to be beneficial.
- You neither understand product discovery, nor product delivery in the 21st-century.
The idea of installing a communication gatekeeper between the product delivery organization and its stakeholders and customers contradicts everything ‘Agile’ stands for. An Agile startup does not require a PMO.
Then How Do You Make ‘Agile’ Work in Startups?
Apparently, becoming an Agile organization is a tedious, lengthy journey. Therefore, the first question any startup should answer for itself is simple: is it a sales-driven, product-driven, or tech-driven enterprise?
Not all organizations need to become truly Agile and may still create a great culture, and deliver a return to investors.
However, if competition is fierce, technology is advancing rapidly, and big players are investing large amounts, then there is practically no way around becoming a learning organization.
And that process requires several steps as the following graphic visualizes:
Getting from the processes and tools level to the Agile mindset is a daring journey, and no one can guarantee that the endeavor will result in the desired outcome.
So, if your startup is a call-center with a homepage, you may want to consider not going down the Agile rabbit-hole. You may very likely plateau at level 2, establishing some isolated Agile islands within the organization. So, be honest with yourself: is that worth the effort?
How-to #1: Culture
Great, you want to become a truly Agile organization. Then let’s start with the most challenging issue right away.
You started out with a small team, and your way of being Agile seems to have started working. Your startup is getting traction, new funding, and your investors urge you to hire more people, and particularly to hire more “senior people” from larger organizations.
If you are now onboarding five, ten, or 20 people a month, you have a serious issue at hand: how to preserve your original team spirit, your original (Agile) culture?
“ Culture eats strategy for breakfast.” (Peter Drucker)
This observation is the main reason that you need to protect your nascent Agile culture at all costs. Don’t let culture “evolve” by hiring people from (legacy) organizations. A former BCG manager will likely urge to establish a project management office (PMO) because this is the way she knows how to organize work. And as culture tends to follow structure, you will strangle your Agile culture if you go this way.
There are only two means of avoiding this sort of collateral damage. You need to invest both in diversity and education of every new hire.
Ensure that everyone understands why your startup needs to be Agile. This learning is not achieved by handing out leaflets. It only works by teaching the big Agile picture and winning hearts and minds of everyone within the organization.
How-to #2: Winning Hearts & Minds with Education
How do you teach the big Agile picture, thus winning hearts and minds of the new hires? Train everybody – without regard to his/her future position – hands-on in all value-creating activities of the organization. Start with customer care, and steal from Zappos.
Plus, and that is my favorite activity, run mandatory workshops with all new hires where they have to prototype a new app. The exercise works for everyone — sales, marketing, customer care, finance, HR, etc. — no specific knowledge is required.
One of my workshops takes about 6 to 8 hours, and the participants build a clickable prototype of a team-event organization app. They learn how to figure out what app might be valuable as well as how Scrum and user story mapping work.
At the end of the workshop, people either love building products or the product delivery organization at least earned their respect. Both are highly valuable mindsets for an Agile startup.
How-to #3: Hire the Right People
As you may have guessed already, recruiting the right people for the organization is the make-or-break frontier for any plan to adopt Agile in fast-growing startups.
Sticking to following hiring principles will make the process significantly more manageable:
- Always hire for mindset and cultural fit, never for skills. The latter can be taught, but you’ll never turn an a**hole into someone likable.
- Look for intrinsically motivated people: they will care for what they help create.
- Hire for the best possible team, not for the best fit for a particular position. (If you haven’t yet read or watched “Moneyball,” do so, and you will understand the principle).
- Lastly, diverse teams are more innovative.
As far as the recruiting process is concerned, let the teams choose their new teammates, and your failure rate will drop significantly. HR will probably not like it but how can you aim for self-organizing teams and patronize them at the same time?
How-to #4: Team Building
You cannot overestimate the importance of team building: the team wins, the team loses. And Tuckman’s findings are still very valid. The objectives of the team building effort are apparent:
- Let the teams constitute themselves, avoid drafting team members.
- All teams shall become self-managing over time.
- All teams need to become cross-functional, as feature teams are required, not component teams.
- High performing teams are co-located.
Other team building lessons learned:
- Ensure that the onboarding of new members is done properly. Prepare everything in advance, and hook them up with a buddy from a different part of the organization
- Don’t shuffle team members around between teams — a team is not a resource pool.
- Line managers and subordinates cannot be teammates.
- Use delegation poker to outsource tasks from teams to the management.
How-to #5: The Agile Workspace
The Agile workspace – the underestimated success factor for Agile organizations. It is interesting to observe that even newly designed offices of startups that pride themselves on being Agile lack the proper facilities.
Adopting Agile does not come cheap as far as the workspace is concerned. You will not just require more space, you will also need different spaces to support the four modes of creative work:
Another common error is the startup-like feast-and-famine cycle of stuffing more people into a once generous space until the next move is no longer an option. Whiteboards and other information radiators require space all the time if an Agile startup wants to reap their benefits.
Looks can deceive: the floor plan wasn’t that great as an Agile workspace.
How-to #6: Sound Engineering Practices
Garbage in, garbage out. No matter how Agile your product discovery process is, it needs to be matched by similar engineering practices.
You build it, ship it, run it:
- Probably a micro-service architecture
- Test automation (TDD, BDD)
- Continuous integration
- Probably continuous delivery
- You need to keep technical debt at bay
Component teams need to become cross-functional feature teams:
- Encourage a holistic product view
- Focus on end-to-end feature delivery
- There should not be any form of code ownership
- Co-locate all teams. No matter what effort you put into communication between remote teams, they cannot match the effectiveness and productivity of co-located teams.
Lastly, don’t let Salesforce just “happen” by accident. It is a familiar story: since engineering is busily building the application for the customers, the internal backend for sales and customer care is left temporarily to Salesforce.
The typical sales pitch goes like: “we need a CRM software, and why would we build something that we can license anyway?” (Which is legitimate) The initial set-up is small, it just takes a bit of customization, but after a short period, requirements from sales start emerging that can only be met by custom development.
And this is the moment when a parallel IT universe is created, and people without software competence – not mention an understanding of software architecture – gain a say in designing your application. The situation will get particularly nasty when Salesforce begins to deviate in functionality from the real application, and syncing data back and forth becomes a major task for the engineering teams.
Without proper technical leadership and stakeholder management, Salesforce will irrevocably spread in the organization causing frustration throughout engineering and product development, bypassing a lot of Agile practices (all three of the before-mentioned startups suffered from that syndrome).
How-to #7: Agile Metrics
The general purpose of Agile metrics is to understand the current situation better and to gain insight on change over time. An Agile metric should, therefore, be a leading indicator for a pattern change, providing an opportunity to analyze the cause for change— and act in time if required.
Contrary to traditional command–and–control organizations, metrics in an Agile context are not used to (micro-)manage the individual, the creative worker. In an Agile organization, metrics are used to provide the team with insights on how to improve continuously.
So, a simple way to undermine the process of becoming an Agile organization is to apply the same bean-counting approach as a command–and–control oriented organization would pursue. Therefore, consider carefully what Agile metrics your startup is using:
- Lead time
- Cycle time
- Ratio of fixing work v. feature work
- Number of bugs in production
- Story points per engineer.
There is no one-size-fits-all approach to becoming an Agile organization. There is no checklist that you can apply.
You need to figure out your way. It will take money, brains, and time to do so. You might fail, you will probably plateau at a certain stage, and once your startup stops going forward, it will likely start moving backward.
So, don’t lose faith in the process and always ask yourself if there is a better way.
“Whenever a theory appears to you as the only possible one, take this as a sign that you have neither understood the theory nor the problem which it was intended to solve.” ( Karl R. Popper)