Business development

Building an Agile Startup 01 — Mindsets and Methodologies

by Alex Iftode

Founding a company is a magical experience. It’s a flurry of important decisions that don’t seem to really matter at the time and earth-shattering tasks that make no difference in the long run. And in the middle of the decisional cyclone is the founder, you, trying to shape an agile startup.

It’s normal for any entrepreneur to worry about how lean or agile their startup is. After all, resources are limited and time is critical, so getting the most bang for your buck isn’t just ideal, it’s necessary.

But before we get to the advice, let’s go over what an agile startup actually means.

I’m going to go out on a limb here and say that what actually matters to you is building a stable company that can grow without you stressing at all times. Sure, it’s nice to say you have an agile company, but the core objective should be to have a successful company.

There is much to be said about startup management and the agile methodology so we’ll break this informal lesson into several articles.

Step no. 1 is to understand what agile is and in what flavors it comes, all through the lens of a startup.

What defines an agile startup?

Agile can mean plenty of things, depending on what you’re referring to. At its most basic level, it’s the mindset of prioritizing tangible results, continual improvement, and adapting to the situation at hand.

The name comes from the ideas of fast product development and fast reactions to change.

The Agile methodology was thought up in 2001, with software development in mind. It has evolved much since then, applying to more and more subjects, general management as a chief example. But that first draft was built on four values that still hold true today:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Based on these values are the twelve principles of Agile and those further define the mindset. The Agile Manifesto is a very interesting read, so if you’d like to know more about the methodology, you should definitely check it out.

But agile is more of a mindset, it encompasses several frameworks. We will cover the two most popular ones but a first a crucial piece of advice:

The methodology you use should fit the team, the company, and the project. Take an existing framework but change it to better work for your startup. There’s no agile police to judge you for not sticking 100% to one system.



The most basic way to describe the scrum framework is - slicing the product development “To Do” list into smaller lists, each one pertaining to a building block of the final product.

The big list is the project backlog, the smaller lists are sprint backlogs, the time period in which the devs are working on a sprint backlog is the sprint itself and the building block they produce is called an increment.

That’s a lot of compacted info. Let’s break it into steps:

Step 1 - Organize the project backlog

In agile development, the scope is variable but it shouldn’t be undefined.

The project backlog contains all the tasks that are needed to finish the project. The backlog constantly updates to cross out built features and add bug fixes or new ideas.

To keep all these organized, the backlog has to include two dimensions: importance and time.

Importance determines which tasks go to the top of the backlog, so the team knows to prioritize those. Time dictates the level of detail in every task - short-term tasks need clear requirements, guidelines, and responsibilities; tasks that are scheduled further down the road can have fewer details since that information won’t be relevant for some time.

Step 2 - Plan the sprint

The product owner and development team decides the scope and goal of every sprint, ideally under the guidance of a scrum master.

To achieve the goal, user stories are chosen and added to the sprint backlog. Sometimes leftovers from the previous sprint or bug fixes are added in as well.


The length of a sprint varies but it should never take more than a month. The general consensus is that shorter sprints are better, as they promote better communication and project understanding.

The planning phase may seem unimportant or obvious at first but it serves a very important purpose - it gives the team the perfect environment to swap information and opinions. This raises the quality of the sprint and ensures that everyone knows their part to play.

Step 3 - The sprint

This is the time period in which the developers work on finishing the tasks in the sprint backlog.

In theory, everyone already knows everything they need to know and they’re focused on their user stories. Of course, theory and practice rarely meet.

To keep the team on track, the scrum methodology uses daily short meetings. These should take no more than 15 minutes and ideally happen at the same time every day. In these meetings, the devs each set goals for the day and check if they’ve met the previous goals.

Step 4 - The review

After each sprint, the team meets up to assess the results - the increment.

This meeting can include stakeholders, investors, and people from outside the team. It’s a common occurrence when the increment is especially important to the overall development process.


This is when the devs present the work they’ve done and discuss the challenges and opportunities they’ve met along the way.

These four steps repeat until the project is done. Since steps 1, 2, and 4 take just a few hours each and the sprint takes less than a month, the system keeps the team agile. They have the flexibility to change focus and even previous work as they get more feedback and insight.


So, the Kanban system has quite a bit of history. The gist of it is that software developers took the idea from Toyota’s manufacturing line and Toyota took the idea from how supermarkets manage inventory.

Unlike the sprints featured in Scrum, Kanban uses a continuous workflow approach, where the top task in the backlog is being worked on by the team.

The tasks are featured in the backlog as cards, which hold all the useful data developers might need. These cards are visible to all team members, transparency being one of the core tenets of Kanban.


Another basic principle is diversifying the skills within the team. Senior developers are encouraged to help and mentor juniors so that every colleague can handle a wide variety of challenges.

The whole team is always working on one task - the one at the top of the backlog. While some are writing code, others are reviewing it or testing functionalities. It’s a team effort and it’s an excellent way of cultivating teamwork.

Some colleagues might finish their work on the task and have nothing to do. That’s the exception when it’s fine to start working on a different task. So some people might be ahead on work but the team as a unit focused on the top of the backlog only.

With Scrum, new releases might come after every sprint. But Kanban often delivers features as soon as they’re done. That means that products often go through several versions each day, gaining new functionalities as they’re developed.

So, in essence, the Kanban methodology is a lot like the four steps of Scrum happening at the same time.

All this sounds wonderful but a word of caution - the project manager has to stay vigilant for any kind of bottlenecks or downward trends. Keeping the Kanban engine well-oiled means a lot of monitoring and statistics.

Which Agile methodology should you choose?

This question can be the bane of a company with an already rigid waterfall structure. The good news - that’s not the case for startups.

The actual hard part is adopting the agile mindset, not one of the many methodologies that stem from it.

That being said, there are a few factors to take into account - as Kanban has a continuous development cycle, the devs don’t have set intervals to talk about the direction of the project. So Kanban requires more experienced developers that can stay on target without regular meetings like Scrum. The up-side is that the plan is easier to change in Kanban since the devs focus only on the current card, and the other ones can be reorganized without confusion.

Ultimately, you should look at these methodologies as guidelines, not rigid structures to adopt. Take ideas from all sources, discuss them with the team, try the promising ones, and adapt the structure as you go.

The whole point of agile is doing what works best for you. The sky’s the limit.

Next in the Agile Startup series - our advice on setting goals and following through.