How to Make Agile Work in Fast-Growing Startups

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

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’ — including Scrum as a framework — work in a fast-growing startup. Also, let me introduce you to the anti-patterns agile startups shall avoid at all costs.

Six Fallacies that Prevent Startups from Adopting Agile Successfully

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.

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:

• Becoming more efficient in software delivery,
• Delivering faster,
• Improving 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 founder motives and the 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, mimiking Steve Jobs.

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.

Fallacy #3: Everyone Loves ‘Agile’

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.

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

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.” (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?

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 still believe in applying the industrial paradigm to solve complex adaptive problems,
• 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 organization does not require a PMO as the magic key to “scaling agile” is descaling the organization.

How to Make ‘Agile’ Work in Startups Then?

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?

How-to #1: The Culture of Agile Startups

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.

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

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.

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 become an agile startup.

Sticking to the 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 a jerk 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,
• Lastly, diverse teams are more innovative, contributing to the “learning faster than the competition” ambitions of your organization.

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 teams, not just in product development,
• High-performing teams do not need to be co-located. (Learn more: Distributed Work’s Five Levels of Autonomy.)

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 Workspace in Agile Startups

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:

• Focus,
• Collaborate,
• Learn,
• Socialize.

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.

How-to #6: Sound Engineering Practices

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:

• 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 product teams, empowered to solve customers’ problems:

• Encourage a holistic product view,
• Focus on end-to-end product delivery,
• Let the team decide on the best tools,
• Lastly, there should not be any form of code ownership or roles with the teams.

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

How-to #7: Metrics in Agile Startups

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:

• Lead time,
• Cycle time,
• Ratio of fixing work v. feature work,
• The number of bugs that escaped to production.

A bad metric is, for example:

• Velocity.

Finally, an ugly metric is:

• Story points per engineer.

Agile Startups — The Conclusion

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.

Business & Finance Articles on Business 2 Community

(37)