Faster Than The Rest: Why Staying Agile Is The Key To Startup Success

Have you ever seen a building constructed?

It's a long series of stages. The entire building is planned by an architect, then a foundation is laid, then a frame is built. This kind of process, where one stage cannot begin until the previous one is complete, is called the waterfall methodology. It's great for buildings, but it's terrible for software.

A piece of software is a project that's never truly finished. Even after it's released, individual features and updates are constantly rolled out.

If software was built like skyscrapers, big companies would be able to pour resources into super projects and release them faster than startups with limited resources.

But it's not like that. Startups stay competitive by using their limited resources in smarter ways than big companies. One of the most powerful frameworks for doing so is the agile methodology.

Agile startups employ small teams, each focused on delivering iterations quickly. They don't wait eight months to develop and release an all-inclusive piece of software. They release a minimum viable product and improve it feature-by-feature, listening closely to their users and the market along the way.

What Does An Agile Company Look Like?

The most common agile framework, the one used by Microsoft, Amazon, Spotify, and most other large tech companies, is called Scrum.

Developers are broken up into small teams known as scrums. Each scrum takes ownership of a very specific piece of the software. The scrum then builds features in quick iteration cycles called sprints.

In its simplest form, the scrum framework has three key components.

1. The product backlog

The product backlog is where the ideas come from. It's a list of features to be implemented and is put together by the product owner, the stakeholder in the software.

The product owner differs from a product manager in that product managers are customer facing, whereas product owners interact internally with the development team.

The product owner decides which features take priority in the product backlog. The features are usually listed as user stories. User stories are hypothetical scenarios that follow this format:

• “As a Facebook user, I would like Social Authentication in order to simplify my login.”
• “As a FinTech developer, I'd like two-factor authentication to keep my customers safe.”

source: Microsoft

User stories are left intentionally vague in order to give the scrum greater freedom in developing the feature.

Ideas are taken from the product backlog and turned into a list of objectives called the sprint backlog, which the scrum then executes on with a process called the sprint.

2. The Sprint

Being agile means accomplishing small, focused goals at light speed. A sprint is a short iteration cycle, typically no more than a few weeks, in which the scrum develops and deploys a particular feature. The scrum is supported and coached throughout the sprint by a member of the team called the scrum master.

Despite their imperial sounding title, scrum masters are not project leaders. Their role is purely supportive. A scrum master should always be a member of the team who is a great facilitator, not a manager. They have to be on the ground with the team, not higher up the food chain.

The scrum sets daily goals for themselves, beginning with a daily stand-up where they answer three questions:

1. What did you do yesterday?
2. What will you do today?
3. Are there any impediments in your way?

The scrum master's job is to make sure impediments are cleared.

The product owner sets the features up, and the scrum master helps the scrum knock them down. However, the scrum master gets no say in the priority of the product backlog, and the product owner is not allowed to input changes when a sprint is in progress.

It's like a fireworks display. Once you light the fuse, you don't start messing with how the fireworks were set up.

Once a sprint is over, however, the product owner manages a wholescale reflection on how it went.

3. Sprint Retrospective

After the sprint is over, the product owner gets to decide whether or not the new features should be deployed. The scrum reflects on the sprint and makes plans to improve the next one. The results of the sprint are recorded in the sprint burn down chart.

The sprint burn down chart maps the number of sprints completed against the amount of work left in the product backlog. Each new feature has its difficulty measured in story points.

It might seem arbitrary, but measuring the difficulty of implementing features is critical to measuring your team's progress. It's a way to make sure each sprint gets more efficient, while keeping the greater project in perspective.

The scrum's greatest asset is its fluidity. Any member can take on any task, and the entire team can react and reorganize themselves depending on what obstacles arise in the sprint. A key aspect of this is the sprint retrospective, wherein they can make the changes necessary to improve the next sprint before it even starts.

Agile Will Fail Your Team At First, And That's Good

As organization coach Matt LeMay says, “There is no perfect product development process for any company — let alone for every company. But to find a process that works well, an organization must take two seemingly contradictory steps: follow the rules to the letter, and change the rules without fear.”

When you're first implementing agile, you cannot afford to fiddle with the process.

One of the great strengths of agile is its ability to engage every member of the team and keep them accountable. The entire structure of the scrum gives team members ownership of their piece of the project, and holds them accountable for the results.

In order for the scrum to work, you need to first implement every rule and process without alteration. This is something a lot of companies get wrong. They try to tailor it to their teams by changing things right away. But it's only by experiencing the raw, default processes that you can start to really bend Agile to your will.

The Struggles of Time Boxing

For example, in the scrum framework, everything happens according to definite timelines. A sprint has a start and end date, daily stand-ups are rigidly structured, and all meetings have hard time limits.

This concept is called time boxing, and it is fundamental to the scrum framework. However, when you first transition to time boxing, there will be struggles. Some team members will dominate too much meeting time, and things that need to be addressed won't be brought up. It will be frustrating, and then, it will get better.

Team members will understand the need for reorganizing the meeting structure, and they will be bought into the new process. Even if you can see this pain-point coming, the team needs to experience it to know why they're restructuring their meetings.

Finding a Definition of Done

Another key agile value is transparency. The scrum system depends on everyone being self-motivated and autonomous, and so it is a massive disadvantage if individual team members don't have a complete picture of what work is left to be done.

Before every sprint, the scrum needs to come together and define what “done” looks like for this sprint. This sounds simple, but it is one of the most common pain points for companies new to agile.

If a new problem arises that falls outside of your sprint goals, you cannot switch gears and work on it. Nothing outside the sprint gets worked on during the sprint. Seeing fires and not being able to put them out is a living nightmare to developers.

Before you start employing a system for handling these fires, you have to let your team suffer through them. They have to fully understand the value of the sprint by executing it over and over again before you tweak the system to fit your needs.

How Agile Lets You Compete With Google

Your only chance as a startup is to be too fast for your competition. Mega-companies like Google will always have more resources than you. The only way to win is to stay a step ahead.

“Mega-companies like Google will always have more resources than you. The only way to win is to stay a step ahead.”

Tweet This

Spotify is probably the best example of this. The music streaming service posted revenues in excess of $2 billion between 2009 and 2015, which by any standard constitutes a success. However, their competition includes Google Play Music, Amazon's Prime Music, and Apple's iTunes Radio—meaning they're fighting three of the most profitable companies in the world.

All three of these companies have seemingly infinite resources. Google, for example, has 15,000 developers developing one single branch of code. Spotify only has around 1,600 employees total.

Spotify breaks their employees up into squads, and each is given ownership of a particular long-term project like “Make Spotify the best place to find new music.” or “Create the best a/b testing system for Spotify.”

Each squad has what is called an agile mentor. The agile mentor decides what system is best for the squad to implement. Maybe it's a scrum sprint, but maybe it's a different agile framework all together.

In practice this means that there is very little standardization when it comes to tools and processes. While Google might deploy thousands of developers to improve a product, every single feature of Spotify is constantly being improved by a lightweight squad using the fastest tools and processes for the job.

The analogy Spotify uses to describe this is that of a jazz band. Every team is like a musician—focused on their own parts and playing different instruments, but always aware of the greater song.

source: Spotify

Spotify's success has catapulted them to the same Goliath-like status as many of the companies they used to compete with. Now it's up to new companies to disrupt the market and move faster than Spotify.

Spotify isn't making it easy, as they've recently upped their speed, deploying code multiple times per sprint. But if a startup is going to do it, they're going to have to be agile.

Want To Disrupt An Industry? Disrupt Yourself First

The outstanding speed of development in the tech world is what makes disruption possible. New technologies are constantly emerging that let companies access new markets and serve existing customers better.

But for startups, disruption is a double-edged sword. We're always on the brink of a new technology, and the same technology that was cutting edge when you first launched might be antiquated in a year.

To sustain your growth, you need to constantly be starting from scratch, introducing new tools and processes that disrupt your existing setup. This is what agile is all about. At the end of each sprint, you get to reflect and hit the reset button on your entire process to make it better.

It's not just about iterating new features, it's about creating new procedures so that your product and team are constantly improving—keeping you one step ahead of the rest of the world.