You are already agile, aren’t you? You do not have meetings, just stand-ups. The to-do list is called a backlog. Everything is captured either on yellow (green, red, blue) stickers, in Jira (already a bit old school), or in shared Google Docs, Notion, Craft, … You do not have presentations, only demos. Your DevSecOps tech team masters CI/ CD. By the way, your teammate is a black-belt scrum monster.
Agile, unfortunately, became an overused buzzword in the past few years; still, I am a true believer. You do not need to follow or fake all ceremonies and use every artifact to make it work. It is enough to embrace the core principles (https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/)
We ran most of our projects in an agile way in the last decade, even when we did not label it as such. It is usable in many setups, not just in software development. Based on my experience, for an early stage start-up, I would recommend to focus on the followings first:
Develop iteratively with frequent customer feedback
Create a draft. Test with the audience. Refine. Restart the cycle.
The beauty of this approach is that even the first version is valuable. Someone can hang on the wall the first carbon sketch and auction it for millions three-four centuries later.
Plus, this is the way to move from MVP to a Maximum Likable Product. Very few companies became successful sticking with their MVP. While you can iteratively improve on your own, making changes based on direct customer feedback definitely increases the product’s value.
And it is true not for your end-product only, but also for the pitch deck, the financial plan, the marketing strategy, etc. Time-box all delivery
There is something magical in deadlines. Productivity skyrockets as they are getting closer. Combine it with the iterative approach described above, and you can set your rhythm to maximize output. 2-weeks cycle works for most organizations, but in stretch situations, weekly might as well. (If you are developing a new type of moon-rocket, let us discuss what fits best.) The purpose of the sprint demo is to showcase the next usable iteration (vs. the classical status meeting where you can talk a lot about work done, but might achieve nothing over months).
Prioritize and prune the backlog
There are two characteristics of modern backlog management, I like to emphasize. First is the differentiated activity breakdown: a more detailed list of tasks for the short-run, bigger blocks for the longer term. You can avoid wasteful detailed planning for unpredictable future stages, but still have the full scope and priorities captured.
Second is the frequent re-prioritization of the tasks. On one hand, discussing and setting the priorities helps the team members to work on important tasks. On the other hand, you must throw away obsolete or low-prio tasks. “Simplicity –the art of maximizing the amount of work not done– is essential” is one of my favorite statement from the agile manifesto.
Self-reflect to improve efficiency
Retrospectives are one of those agile ceremonies, which seems easy to skip, in the turbulence of the million to-dos. Still, for my teams it was always beneficial to spend time 20-30 minutes every second week to discuss the issues, deficiencies but also best practices, great shortcuts, novel approaches. Good for both the productivity and the team morale. A simple Start-Stop-Continue classification would be enough.
You can disagree with any of my thoughts and still be 100% right. Whatever works for you to make your startup successful is great. Agile is not a dogma, and I am not its monk. But, if what I wrote above partially resonates, I am happy to discuss further and tailor to your setting.
Mentor, management consultant