Alignment meetings
We are getting very religious about it but we love our bi-weekly Alignment meetings so much that we have to share a few words about it.
Who enjoys meetings?
Once a sprint, in the first week of work we gather all our front-end developers for an hour and talk about stuff that connects all our tribes (teams): Ember and front-end codebase.
I’ve never seen developers so happy for a meeting. Well, I’ve seen them happy about a meeting but only when it was canceled 🤭.
What do we do?
We talk about new components for general use that someone introduced, we talk about problems and possible solutions, we talk about migrating from one pattern to the other, removing dependencies, useful techniques… and so on (examples below):
In general, we can divide it into three categories:
- Issues we should discuss
- New stuff we should know about
- Other cool stuff
When it comes to technicals, we do set an agenda. That’s a good rule for any meeting. If a discussion is not moderated then we might end up talking for 45 minutes about something unrelated. But there is no-one who’s approving the agenda. We just pop in cards as we go through the sprint. So everyone’s voice should be heard.
All that divided into four columns:
How it looks from the inside
It’s easier to understand the excitement when you see examples. So here is the stuff that we discussed in the past. Along with some decisions that we’ve made. In many cases these are the topics that Product Managers won’t ask you about:
1/ We use Lingohub as a repository of translations so we have to merge a pull request with them from time to time.
Here, other folks were informed we have automated that process.
2/ We discuss patterns that we should use in our codebase. In Ember’s world mut helps in setting the value of a variable (or property) straight from a template. There are a few ways of doing that with pros and cons for each. It’s important that we have a common understanding and a common approach.
3/ A new component has been introduced. With increasing customization of the product, we found a need for a Rich Text editor component that can be used everywhere. Jonny and Rafa were showing how it works in our Styleguide (we use ember-freestyle). We try to build components for general use in the Styleguide to not be biased by the specific needs for a solution we are currently working on.
4/ The other day we revisited the minimal requirements for our application. We can easily cut a few bytes by transpiling the code only for more modern browsers. After discussion, and verifying what users actually use we’ve made a decision.
5/ Our product is getting bigger and bigger. We need to understand how UI elements lay on the stack. We want to make sure that error messages are always shown at the top, or a dropdown is going to be covered by a sliding panel for example.
We came up with an idea of a single file with all z-indexes as CSS variables that we use in different places. When you look at the file, you see the whole stack.
6/ Short presentation about traits and afterCreate in ember-cli-mirage and how we are going to leverage that functionality. We all agreed it’s helpful and the way to go for us.
7/ Conclusions from the experiments with LogRocket. How it works, how we can benefit from that, what’s our estimated cost etc.
8/ We discuss techniques that we found by ourselves or we found somewhere else.
That’s just a few from dozens of topics that we discussed.
Actions
Some discussions require actions so we add Technical Tasks to our sprints as a result of the meeting. Thanks to having the first day of a sprint dedicated to technical debt or so-called “maintenance” we are confident to hit the goal of actually working on stuff that will let our product to be healthy (we will talk about it in a different post).
When something is in progress then it lands in the proper column. Some tasks may take a while, like the one where we removed 153 colors (sic!) from our product and replaced it with our own palette:
That was a real quest! ⚔️
Benefits
The obvious benefit of these meetings is spreading knowledge among the team. It also increases the quality of the product itself. I believe that great developers lead by example so when you see that others care, you care as well.
Just talking with folks that are interested in the same stuff as you can give you a lot of energy. That might sound weird that we are excited to see that someone went for an extra mile and made modals dismissible by hitting ESC key… but details count… and front-end developers love these tiny details.
At this meeting, your efforts will be very appreciated by your team-mates.
Takeaway
Make your team of front-end developers happy and organize an alignment meeting for them. Let them discuss “front-end stuff”. Keep it organized (see agenda). They will love it! 😍
PS. Give them time to actually work on stuff they’ve discussed.
PS2. Our backend developers started their own alignment meeting and they love it too.
Tomek Nieżurawski writes also on his own blog — tomekdev.com.
We are always looking to speak to amazing engineers about joining the Phorest team. You can check out open roles here.
