How we release new features each week
Or How to reply to your CEO : — Good idea! It will be released next week. — Awesome, I love that 💕!
This is not a SCRUM story 🙃, but only how the product team is organized at Weet.co to deliver the value for our clients as quickly as we can! Feel free to pick up what you like, and apply it (or not) with your team!
Let’s Go !
When you want to deliver features every week, you have to produce the ideation in 1 week, the design, the quality code, the Quality control, and deployment. Unfortunately, these steps cannot be produced at the same time but we can try to improve!
Perfect communication in your product team
At Weet, we are a fully remote team, and we have different TimeZones (US and EU). I will not talk about the advantages and drawbacks of a fully remote organization but if you’re interested, you can check the gitlab manifesto.
The main key for a fully remote team, especially when you are in a 1-week release delivery, is communication. Each member has to keep in mind that a designer, a developer, QA, CEO, PO, PM, and Marketing… all have to know what happens on different parts of the app to get the maximum amount of feedback as soon as possible.
We communicate most often with video (Weet) (asynchronous messaging). It allows everyone to send complex messages in only a few minutes.
— If you use backspace to rewrite your message (email, or slack)… let’s record a Weet
To have better communication we have to know each other, so we remove the traditional daily stand up with “Croissants and Donuts”. This daily get-together is like a chat by the coffee machine; We can talk about our weekend, our children and sometimes about work 😃. This chat is not on a strict schedule and often becomes a brainstorming session.
Only 2 environments: Production and Production-Ready!
At Weet, we removed integration, dev, or QA environments. We only have a Production environment 😃 and a Production-ready environment. The whole company uses the Production-Ready environment of our product, and reports bugs and feedback 🧑💻… This is an amazing source of beta users 👨👩👦👦 !
Why only 2 environments ?
Multiple environments are costly💰, need maintenance🛠 and take a lot of time to build/deploy. Some non-IT users don’t understand the difference between dev/QA or a beta version, so they simply stop using the unstable version as opposed to the production version.
Another point; When a dev has to push code on a QA/test environment, he can consider it “normal” to break the environment or create downtime. He can choose to ignore data migration or only release major bugs… We don’t need that. That takes up a lot of time for the company.
So we remove each test environment and have only Production environments. Each part of the code pushed has to be ready for production without known bugs.
Another benefit is the QA Team has to check only the corner case of a feature, so they have time to develop each E2E test (end to end) during the sprint (I recommend cypress.io).
Reviewing everything!
It’s not an original idea, but each part of the code is reviewed and documented (with Weet 😀) before being pushed to the Production-ready environment. It’s really important. Remember, we have to optimize our QA time. The code review can remove a big part of a potential bug. It allows the detection of some bugs, a wrong model conception, or algorithm errors.
Better Code, fewer bugs, easier to maintain and evolve.
We also work with design review, during the dev process and the Production-ready environment.
To review our code, we use upsource, an amazing software by Jetbrains. It allows everyone to be a reviewer and adds the possibility to review code during the dev process. We also use weet videos to present new features/evolutions in development, explain code, ask questions, etc… I’m also a big fan of the rubber duck debugging🐥. Often, recording an explanation of an issue is enough to find a solution 🐥.
Thinking about the future of the feature, not the MVP, even if it’s more complicated to dev…
When you release quickly you have to deploy your MVP, but don’t forget this feature is not finished and has to be updated (certainly next week 😁). To gain time and avoid data migration, you have to design your features with the final model, final code architecture, and final design (if it’s possible). I know it’s easy to say
In our organization, we call that a Deep feature. A development that cannot be released step by step and cannot be developed in 1 sprint.
Having an efficient pipeline!
If you have to deliver frequently in your Production-ready environment, you can’t waste your time on building steps. Your pipeline has to be fully automated and really efficient. Fortunately, we have a strong DevOps team that deployed a fully scalable runner (Gitlab runner). (Thanks again for Guillaume and Farid)
Optimizing the delivery process
- Building only what it needs to release and not the entire stack.
- Executing tests when they need to be executed.
- Allowing some shortcuts on the pipeline for a manual launch…
We also integrate other features in our pipelines like localization (thanks to lokalise) or an E2E test with cypress. Everything is automated!
We also allow a lot of shortcuts in our pipeline. Every developer or QA member can release in a production-ready environment. No need to ask for authorization, but they have the responsibility not to crash the environment (this is a production environment). The only rule is to communicate if you release something. Another point is each microservice has its own pipeline. We can deliver only some parts of the stack. Thus gaining a lot of time :-)
A to Z to increase responsibility!
To increase responsibility, a developer has to own a feature. That means the feature is coded from A to Z by the same developer. It avoids a lot of conception meetings and code questions. With daily and async communication we can review the architecture, the code, the design, give feedback, etc without spending the whole day in a meeting.
What’s a typical week in a “1-week release” organization
It’s complicated to say “how the day starts” because we have different time zones in the team. I will explain what “my” typical week is like instead. I live in San Francisco.
My daily routine
Each day starts with a Weet check. I watch some news about bugs, issues, deliveries, advancements, design reviews, and ideation. After, it’s time for 🥐 Croissants and Donuts 🍩. We can drink some coffee, tea, and can talk about the weekend or other topics. The conversation always finishes with a moment about issues or new ideas. This meeting is not limited by time and can go longer than 30 minutes. Then, my workday starts and I can begin to develop (I’m a developer too :-) ). During the day I never hesitate to record a quick Weet, to explain some choices or issues to the teams. I record around 5 to 10 Weets per day. At the end of my journey, I release my work (if it’s possible) and I record a release note where I show each new feature and each bug fix deployed on the Production-ready environment. It’s really important to send a Weet instead of traditional bullet point release notes for these reasons:
- Explaining a bug is sometimes complicated in bullet points, especially when it’s a graphic/design bug.
- Recording the bug fix allows you to check if it’s really fixed on the Production-ready environment. (🐥 Rubber Duck debugging).
- It shows the right scenario to the teams. That avoids the typical discussion (see below)
We can have :
QA: In this case, it doesn’t work. — Dev: Oh, let me check that! Thank you !
Instead of :
QA: That doesn’t work, — Dev : That works for me
My weekly routine
On Monday, we continue Croissants and Donuts with a backlog meeting. In the meeting, we define an objective that is extremely clear for the week. This objective is worked directly on the master code. Example of an objective: On Friday we’ll release recording at 1080p!
At the same time, we prepare the other releases in different branches of the code. Remember a feature is owned by a developer, so he can work on his branch during the entire week.
We continue with the weekly Weeting :-) this meeting is the only one with the whole company, (Marketing, CSM, etc… ) The product team can receive feedback from clients (negatives or positives) and can see the KPIs of the company. The Product team informs me that it will be ready at the end of the week :-) This meeting allows the Product team to receive information about client feedback and issues to fix!
Let’s jump to Friday now. During the day, we have another weekly with another Product team (for a different project and organization). We can exchange about some technical issues or about the organization. Friday evening is dedicated to preparing the release for production, and to prepare the internal communication. We finally release it at the end of the day and launch the internal communication.
Staying fun in the internal communication
To encourage the whole company as beta testers👨👩👦👦, the product, and the internal communication has to be fun and attractive🎁. This is a key to get tests and feedback on new features! Don’t be shy and engage the team.
What about Deep features?
As explained in this article, a feature is not developed and released in one week, but there is a new feature delivered for the client each Friday evening. Some features can take 2 weeks to dev, 3 or 4 weeks. It depends on the complexity of the feature. But each week there is a new branch merged on the master code and each Friday this code is released in production.
I already said it, but this deep feature is the MVP, and has no issue evolving. The evolution of this MVP can certainly be developed in one week 😀🕺
Do not to be afraid to block a release
Sometimes a feature can have some issues… or just needs to be reworked and the release must be stopped. The Production-ready environment can receive some beta features, but the production has to be as perfect as possible. Delay the release if a rework is necessary, or if the MVP has to be increased.
Feature flipping
When we want to test a concept or advanced feature, but we don’t want to release it, we use some flags to activate the feature only in our production-ready environment. Our team can validate that the MVP is enough to be released to our client. Currently, when I wrote this line, we have two amazing features activated on our Production-ready environment, but not in Production. We want to validate that those features are really useful before releasing them.
Pro and cons
Pro
This methodology allows for speediness. You can change your release plan week by week. You can include a feature request or “quick win” in one week. Your product is never stuck in a deep release! Even if it is a major version. Your devs code with responsibility, and create better code. Your company loves your product and sends you a lot of feedback. Sales and CSMs know exactly how the features work because they take part in the conception. Short sprints allow you to reply quickly to user feedback, and they love that!
Cons
Short sprints can be tiring at some moments and can seem hurried. It can be really stressful. The release plan can change each week and can be difficult to follow for some developers. To apply the one-week release, you need an extremely positive, resilient and awesome team!! This organization is perfect for a small team, but I think it can be difficult to scale (Maybe one day, I will write another article on “How to scale a one-week-release organization”)
Last Word from the product team
I’m always impressed by this capability to release new features weekly! I really appreciate the fact that we can discuss new ideas and see the implementation quickly. I really feel lucky to have this awesome team!
— Najette Fellache CEO
Our new work environment and its constraints (full-remote work, different time zones) have forced us to redefine our working and communication methods. Rather than applying a framework, we started from scratch. Then, we tested, modified, and iterated, always prioritizing voice communication over everything else. Today when I take stock of the progress I am surprised, with our homegrown method, we have never been so close to the fundamentals of agility (the manifesto and its underlying principles).
— Frederic Letellier Data analyst / PO / Lead QA
