Source: unsplash.com

SCRUM in the context of a start-up

Why should you define your own organizational framework as start-up founder?

Introduction

Agile methodologies are a set of good practices that aim to help a team during the development of any kind of projects. These methodologies are widely used in the web and mobile areas — especially in the context of a start-up.

So what’s the purpose of this article ?

Agile methodologies for developers

Agile methodologies, as perceived by developers, are a theoretical approach to the following question:

How to enhance productivity and handling evolutions (feature adding/modification/maintenance) that occur frequently for a given project?

Let’s focus on the SCRUM methodology (which is one of the most used in the start-up context) to see how agile methodologies respond to this question. As any productivity issue, the simpler solution is to define an organizational framework. This means establishing a set of processes and making the various protagonists of the project responsible of these processes.

Well.. That’s the purpose of the SCRUM methodology!

Indeed, this agile methodology establishes a certain number of processes based on a cycle of N week(s):

backlog

sprint planning

daily scrum

sprint retro

sprint review

Also, it defines a set of roles:

Scrum master

Product owner

developers & designers

Ok! In theory, this works just fine! But in fact, there are a set of factors that upset this framework.

The factors

First, there is the pressure that comes from competition, hierarchy or investors. In general, this pressure is materialised by the fact that the Product Owner wants (at all costs) to add features and modifications in the middle of the sprint. Also, it can be materialised by the fact that the PO defines a very ambitious sprint..

By essence, start-ups are in constant research of their product/market fit. This means that they need to constantly try new approaches in order to validate hypothesis about the product. This results in frequent changes in the code base and its structure. This can be felt as a back-and-forth between the PO and the tech team. The consequences of these issues are perceived as a lack of consideration by the team.

Feel free to share your story with us if you encounter another type of issues by adding a comment

Indeed, the organizational framework should protect the team. But, as we’re in a start-up context, we’re constantly challenging the business model and the product in order to find our fit with the market. As SCRUM is based on cycles of N weeks with backlog, it’s hard to match this level of flexibility. So, this treason breaks the circle of trust between all the protagonists. Also, it directly impacts the general implication of the team.

At this moment, the organizational framework (SCRUM) loses interest because it is based on empowering everyone under the guise of everyone trusting each other. So, we come to situations, sometimes puerile and ridiculous:

sprint plannings become oratorical contest

sprint retros become trials

sprint reviews become group therapies

developers become risk-averse

a simple modification can take days to months

this creates a hierarchy and breaks the concept of flat organization

So, the organizational framework, which should propose a certain number of rules and tools to:

make the team responsible of the project toward a common goal

build trust

enhance productivity and code quality

becomes an oppressing & conflictual framework where trust and group cohesion are inexistent. These situations legitimate the fact to question the relevance of this agile methodology for start-ups.

Indeed, within a so complex world where each company tend to be unique, it becomes more and more irrelevant to keep using a generalist organizational framework. Also, nowadays the level of exigency of clients and users is more and more high. They have so much choices with the competition that their level of patience or the time they can give you is very limited. So, your product needs to be stable. The UX needs to be crafted depending on client feedbacks. And new features need to be also implemented depending on users feedbacks.

This said, the organizational framework offered by SCRUM isn’t enough flexible to respond to these constraints.

Craft your own organizational framework

Nevertheless, SCRUM makes us think on important topics that you shouldn’t neglect:

roadmap prioritization

daily communication

knowledge sharing

pair programming

mid-term planification

clear documentation

measurement and enhancement of the productivity

reflection on the work accomplished over a given period

reflection on the general lines of improvement

etc..

These topics can totally be applied outside of the context of SCRUM. I would go even further. I think that each team should craft their own organizational framework. All in function of:

the team capacity (number, experiences, talents)

the ambition

the expected product quality (MVP, post product/market fit, etc..)

the company culture

Learning by doing

Nothing better than a good old example (tested in real situation). Before to detail this example, I’d like to notice you that you can enhance your organizational framework over the time to make it more and more fit to your needs. So, start even if the first version isn’t the best one – Be agile to figure out the right organizatonal framework for your project. 😎

This said..