There's no question that the no-code movement is gaining momentum with many communities. The benefits are clear for those folks -- both technical and non-technical -- who want to realize a new idea but don't want the typical overhead that comes with traditional software development. 

No-code tools make creating a product or business more accessible than ever. Because of this, some products gain rapid success and the founders find themselves struggling to keep up with demand and balance the need for user requests, bugs, and new features efficiently.

Scrum is a term familiar to software engineers and developers as a standard for how work gets done in the industry. But even if you're not coding your product, the principles of Scrum can still lend stability and efficiency to your process.

Let's take a look at a few of the basic principles of Scrum, and then I'll explain how I've implemented this with the Mintor team.

The Scrum framework comes from a set of larger principles, called Agile, which is based on the idea of iterative incremental development. Scrum allows the work itself to be defined and evolved through team and stakeholder collaboration. Doing so promotes rapid, flexible changes to be made in short 'Sprints'.

The Agile Manifesto (guiding ideology) is as follows:

- Individuals and interactions over processes and tools

- Working software over comprehensive documentation

- Customer collaboration over contract negotiation

- Responding to change over following a plan

Scrum is a specific process that operates within the principles of Agile by concentrating on how to manage tasks in a team-based environment. Here is how we use Scrum while building the Mintor app in Bubble.

Our team maintains a "two-week Sprint cycle", which is just a fancy way of saying that we break our app development into two-week chunks. This allows some room to be agile when it comes to adding new features, bugs, and user requests into the workload. Every two weeks, the cycle starts all over again and we plan for the next set of work items.

In each Sprint cycle, we organize, plan, and assign our work using the meetings listed below. These are specific to the Scrum process and you can find a more detailed explanation here.

🗓 When: At the beginning of the sprint (usually every two weeks on Monday)

👥 Who attends: Developers & product owners

⏱ Duration: 1 hour, max

🤔 Purpose: Sprint planning allows time for the team to sync up on what everyone is doing for the new Sprint. As CTO, I maintain a "backlog" list of items that need to be worked on at some point and will have already prioritized them before going into this meeting. A backlog list can include any bugs to be fixed, new features to be added, any user requests we want to implement, etc. From there, the team will collectively add items from the backlog into this Sprint's task board using a task management tool (we use Clickup). Then, we divide and assign the work among the team. We also estimate how long each thing should take to complete (later on this helps with putting the right amount of tasks into each Sprint board).

🗓 When: Daily (usually in the morning)

👥 Who attends: Developers & product owners

⏱ Duration: 15 minutes, max.

🤔 Purpose: Daily stand-ups help us keep a pulse on the team's progress throughout the Sprint. As the name suggests, this meeting is traditionally held with all team members standing to help keep this meeting short. The tone should be light and fun and is not meant to be a detailed status meeting. Each team member should answer only the following questions:

- What did I complete yesterday?

- What will I work on today?

- Am I blocked by anything?

Going through these specific updates each day in front of the other team members creates a culture of accountability and helps solve any ongoing challenges someone may be facing.

🗓 When: At the end of the Sprint (usually every two weeks on Friday)

👥 Who attends: Developers & product owners

⏱ Duration: 1 hour, max

🤔 Purpose: This is a chance to show off the team's work and wrap up the Sprint. For us, this is usually a more casual format, but it can be more formal if necessary. Reviews provide a space for the team to celebrate our accomplishments, get feedback from each other, and showcase our completed work. The retrospective portion allows for reflection on what things went well, what didn't go well, and what lessons were learned during the Sprint. Doing this regularly keeps the team mindful of their work habits and sustains continuous improvement.

Rinse, lather, and repeat! It's a fairly simple process and when executed well it helps your team find a rhythm while remaining flexible in the fast-changing world of a startup. As a solo founder or indie hacker, the process and task tracking can still help organize your work -- just don't get caught talking to yourself on your daily stand-ups or you might get some funny looks 👀

-----

Thanks for reading this far. If you liked this post, you can subscribe below or follow me on Twitter to keep up with my latest startup, networking, and NoCode musings. Hope to see you there 👋