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

A month ago, I was in a mission in the food delivery area. To give you a bit of context:

• a team of 4 developers (2 backends, 2 frontends), a UX designer and a Product Owner (which is the CEO BTW)
• webapp & mobile app
• the ambition to be the number one in the french market
• the product needs to be stable because of the huge competition

So, here is the framework that I proposed:

• cycle management by feature (no duration defined for a given cycle)
• always propose a minimalist version of a feature that can be developed in less than 48 hours by the team
• the PO decides what’s the current feature
• the PO must collect feedbacks for the given feature ASAP
• the PO propose feature evolutions according to the collected feedback
• Backend developers must propose a mock of the expected API calls in order to avoid bottlenecks with frontend developers
• the frontend developers directly work with the PO and the UX designer during views elaboration — when required
• daily summary of their achievements and the encountered issues on a dedicated Slack channel.
• bugs are high-priority. This means that when a bug is reported (depending on the criticity) then it must be assigned to the most relevant person in the team
• the bug description must be complete (bug, use case, screenshots, etc..)
• developers notify the PO when their current task is done to request their next task.
• the PO is always available for feature testing in order to give a quick feedback.
• the productivity is measured by month and via the number of achieved tasks.

I proposed this framework because the team is small and homogeneous. In addition, the project is ambitious and requires a maximum of flexibility. Also, the product isn’t mature yet. So, the team must be able to quickly intervene in case of changes , critical bugs or pivot. In this context, we develop feature on-the-fly with clearly defined priorities (global stability over features). Like this, developers are not surprised when a change suddenly occurs (which often happens in IT business). This framework required a certain time to be assimilated by the whole team.

But don’t underestimate the human brain. After all, they quickly assimilated the SCRUM methodology. :-) Since then, the product is getting more and more close to users expectations. The team members are happy to come to work everyday. They adapt the framework when needed. And the PO is seen as someone who challenges the tech team.

Conclusion

I’m not sure that this framework can be applied to another team or project.. That’s why I strongly believe that each team should craft their own framework and make it evolve through time. I’d love to know If you ever encountered issues with the SCRUM framework.

So, feel free to let a comment to share your story with us !

Voilà!

RubyCademy is now available on Youtube! ▶️ 🚀 🤩 💎

We publish short videos (maximum 5 minutes) that talk about technical notions, quick wins and tools (..and a couple of geek stuffs 😅).

Feel free to click on the image below to access our Youtube channel