For years, I worked in several Berlin-based, fast-growing startups in my capacity as Scrum Master, agile coach, and Product Owner. These are my lessons learned on making Agile work — including Scrum as a framework — in a fast-growing startup. Also, let me introduce you to the anti-patterns agile startups shall avoid at all costs.
🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 30,000-plus other subscribers.
Join us on March 9, 2021, for a live virtual workshop to create actionable recommendations on how to deal with the outcome of a forensic Product Backlog analysis. (Participation is free.)
From 2010 to 2017, I worked several years in three Berlin-based, fast-growing startups in my capacity as Scrum Master, agile coach, and Product Owner. ‘Fast-growing’ in the sense of this article refers to startups of at least 200 staff strong. Each of the before-mentioned organizations doubled in size each year during at least three consecutive years. All startups built double-sided marketplaces, serving B2C as well as B2B customers.
These are my lessons learned on becoming agile as a fast-growing startup and what anti-patterns to avoid at all costs.
If you ask founders and managers of startups why they want to become an agile organization, they typically name reasons such as:
If you compare these answers to the actual benefits of becoming an agile organization, such as:
you immediately recognize the misalignment of founder motives and the agile mindset.
Cannot see the form?
Please click here
The change to become a learning organization within a startup is by nature fundamental and continuous. It requires to permanently:
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.
In 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. Limited or lackluster support will render efforts practically 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.
Change is much less appreciated than innovators commonly believe. Organizations have inherent inertia to change, which is why they are successful: they provide stability.
However, stability also breeds self-interest at all levels, but particularly at the middle management level.
There is the ‘what’s-in-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 & CV optimization efforts are a motivation to consider.
Self-organization, on the other side, needs a different kind of management: teachers, coaches, and mentors. And just relabeling the positions of the old middle management rarely works.
Read more: Why Agile Turns into Micromanagement
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 product's future direction.
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 else was wrong no one could not foresee.”)
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.
“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.” (A Berlin-based startup CEO summarized his expectation of becoming an agile organization.)
There seems to be a belief—even among informed stakeholders—that scaling an agile organization can be achieved by going through a successful startup’s checklist. 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.”
Source: Don't Copy the Spotify Model
The truth is, you cannot just copy the “Spotify model” as there is none. This organization was built with such an idea in mind from the beginning, 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?
A PMO – short for project management office – signals to agile practitioners that:
The idea to install a communication gatekeeper between the product delivery organization and its stakeholders and customers contradicts everything ‘Agile’ stands for. An agile organization does not require a PMO as the magic key to “scaling agile” is descaling the organization.
Becoming an agile organization is a tedious, lengthy journey. Therefore, the first question any aspiring agile 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 the competition is fierce, technology is advancing rapidly, and big players are investing large amounts, there is no way to avoid becoming a learning organization.
And that process requires several steps as the following graphic visualizes:
Source: What is Agile? Graphic: By the author.
Getting from the processes & 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 will remain likely plateau at level 2, establishing some isolated agile islands within the organization, such as using Scrum for product development. Be honest with yourself: is that level of becoming an agile startup worth the effort?
Great, you want to become a truly agile organization. Then let’s start with the most challenging issue right away.
You started with a small team, and your way of being agile seems to start working. Your startup is getting traction, new funding, and your investors urge you to hire more people, mainly to hire more “senior people” from larger organizations.
If you are now onboarding five, ten, or 20 people a month, you have a severe issue at hand: how to preserve your original team spirit, your authentic (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. Former BCG managers will likely urge to establish a project management office (PMO) because this is how they learned organizing work. And as culture tends to follow the structure, you will strangle your agile culture precisely in this way.
There are only two means of how to avoid this sort of collateral damage. You need to invest both in the 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 everyone's hearts and minds within the organization.
Read more: The Big Picture of Agile.
How do you teach the big agile picture, thus winning the new hires' hearts and minds? Train everybody–without regard to 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… — no specific knowledge required.
In my experience, a class 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 and how Scrum and user story mapping work.
At the end of the workshop, people either love building products or the product delivery organization earned at least their respect. Both are highly valuable mindsets for an agile startup.
Read more: App Prototyping with Absolute Beginners.
As you may have guessed already, recruiting the right people for the organization is the make-or-break frontier for any plan to become an agile startup.
Sticking to the following hiring principles will make the process significantly more manageable:
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?
Read more: Peer Recruiting.
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:
Other team building lessons learned:
Read more: Zappos’ Outrageous Record For The Longest Customer Service Phone Call Ever
If you decide to work as a co-located team, pay attention to the workspace–the often underestimated success factor for agile organizations. It is interesting to observe that even newly designed offices of startups that pride themselves to be agile lack 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:
There is a 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 factory floor wasn’t that great as an agile workspace. It is probably simpler to consider the distributed, non-co-located approach to creating agile startups, think Automattic, Gitlab, or Basecamp.
Read more: Agile Workspace: The Undervalued Success Factor
Garbage in, garbage out, no matter how well agile startups craft their product discovery process, similar engineering practices need to be matched.
You build it, ship it, run it:
Component teams need to become cross-functional product teams, empowered to solve customers’ problems:
Lastly, don’t let Salesforce just “happen” by accident. It is a familiar story: since engineering is busily building the customers’ application, the internal backend for sales and customer care is left temporarily to Salesforce.
The typical sales pitch goes like this: “we need CRM software, and why would we build something that we can license anyway?” (Which is legitimate.) The initial set-up is small, just a bit of customization, but after a short period, requirements from sales start emerging that only can be met by custom development.
And this is the moment when a parallel IT universe is created, and people without software competence – not to 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 significant task for the engineering teams.
Without proper technical leadership and stakeholder management, Salesforce will irrevocably spread to the organization, causing frustration throughout engineering & product, bypassing many agile practices. (All three of the before-mentioned startups suffered from that syndrome.)
The general purpose of agile metrics is to understand the current situation better and gain insight into change over time. Therefore, an agile metric should be a leading indicator for a pattern change, providing an opportunity to analyze the cause of 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 improving 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:
Good metrics are, for example:
A bad metric is, for example:
Finally, an ugly metric is:
Read more: Agile Transition: Agile Metrics—the Good, the Bad, and the Ugly
There is no one-size-fits-all approach to become an agile organization. There is no checklist that you can apply to the issue of becoming an agile startup.
You need to figure out your way. It will take money, brain, and time to do so. You might fail, you will probably plateau at a particular stage, and once your startup stops going forward, it will likely start moving backward.
So, don't lose faith in the process and always question yourself:
“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)
Source: Goodreads on Dogmatism
How do you make Agile work in fast-growing startups? Please share your experience with us in the comments.
Download the Scrum Guide 2020 Reordered for Free.
I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.
You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:
See all upcoming classes here.
You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.
TL; DR: Technical Product Ownership Dive deep into the benefits—or the lack thereof—of the technical…
TL; DR: System-Level Scrum Stakeholder Anti-Patterns Learn how outdated organizational structures manifest themselves in system-level…
TL; DR: Scrum Master Tasks: Let's Bust Some Myths! Rumor says that a great Scrum…