How to Make Agile Work in Fast-Growing Startups

TL;DR: How to Make Agile Work in Fast-Growing Startups

From 2010 to 2017, I was working several years in three Berlin-based, fast-growing startups in my capacity as Scrum Master, agile coach, and Product Owner. These are my lessons learned on how to make ‘agile’ work in a fast-growing startup, and what anti-patterns to avoid at all costs.

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. Quote:

“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.”

Source: Matteo Bovio, Zalando SE

If becoming agile, as opposed to merely doing agile, is so successful, how come then, that 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 was working 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 a period of at least three consecutive years. All startups built double-sided marketplaces, serving B2C as well as B2B customers.

These are my lessons learned on how to become agile as a 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,

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 to permanently:

• Run experiments
• Embrace failure, and 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.

To 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 for better-suited organizations elsewhere.

Fallacy #3: Everyone Loves ‘Agile’

Change is much less appreciated than innovators commonly believe. Organization 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 the middle management.

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 be reckoned with.

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

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 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.

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 a successful another 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.”

Source: Don’t Copy the Spotify Model

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 & 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 to install 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.

If you prefer a notification by email, please sign-up for my weekly newsletter and join 6,242 peers…

How to Make ‘Agile’ Work in Startups Then?

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 nowadays practically no way around 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 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 start 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 hands: 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 exactly in this way.

There are only two means how to avoid 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.

Read more: The Big Picture of Agile.

How-to #2: Winning Hearts & Minds w/ Education

How do you teach the big agile picture, thus winning hearts and minds of the new hires? 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.

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 earned at least their respect. Both are highly valuable mindsets for an agile startup.

Read more: App Prototyping with Absolute Beginners.

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 & 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?

Read more: Peer Recruiting.

How-to #4: Team Building

You cannot overestimate the importance of team building: the team wins, the team loses. And Tuckman’s findings is 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.

Read more: Zappos’ Outrageous Record For The Longest Customer Service Phone Call Ever

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 office 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:

• Focus
• Collaborate
• Learn
• Socialize

Also, the startup-like feast and famine cycle of stuffing of 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.

Read more: Agile Workspace: The Undervalued Success Factor

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:

• DevOps
• 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, just a bit 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 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 & product, 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:

Good metrics:

• Lead time
• Cycle time
• Ratio of fixing work v. feature work
• No. of bugs on production

Bad metrics:

• Velocity

Ugly metrics:

• Story points per engineer.

Read more: Agile Transition: Agile Metrics?—?the Good, the Bad, and the Ugly

Conclusion

There is no one-size-fits-all approach to become an agile organization. There is no checklist that you can apply.

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 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 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.

Do you want to read more like this? Well:

• ?? Join 6,242 peers and sign-up for this weekly newsletter
• ?? Follow me on Twitter and subscribe to my blog Age of Product
• ?? Or, join my brand new Slack team “Hands-on Agile” for free…