As expected in a startup like ours, we do have a Tech team. 🤓
Because "software is eating the world" as they say, Tech has an important role here at OpenClassrooms. However, crafting good software is difficult (we've learnt this the hard way over the years). It is as much a science as it is an art.
What does the Tech team look like? Are they a bunch of Red Bull swigging geeks who used to program rocket software during a school assembly and hack NSA servers in under an hour? Which software do they use and what are their habits? Let's find out... 🕵
"Our mission is to provide the user with a learning experience that makes education accessible.
We aim to produce efficient, high-quality work using lean, agile, and continuous improvement."
There are several important words here. Let's define them.
User: The user is the focus. We can always learn from them.
Learning experience: We serve the higher purpose of learning, which happens best through knowledge dissemination and skill acquisition.
Quality: Quality underlies all our work, whether it's visible in the product or invisible in the methodologies, design, or code used to build it.
Efficiency: Efficiency requires being lean and on time.
Agility: Agility is iterative, incremental, and adaptative.
Continuous improvement: To achieve our mission, we must constantly strive to improve all of the above elements.
We also have a vision that guides this mission, which is to focus on core business. It means that we don't try to do everything, because it would be expensive and exhausting. We focus our efforts on the very core of our business if there is no available offer to meet our needs. If a solution already exists, we look for the best service, matching criteria like scalability and cost.
What does focusing on core business mean? Take a search engine, for instance. We could have built our own for courses, using a customized Solr. Instead, we opted to use Algolia, which is a very good ready-to-use almost plug-and-play solution.
The same goes for chat channels. We could have developed our own chat system, using bricks like WebSockets with Socket.io. It would have been fun, sure, but we decided to use Layer which offers a more complete and ready-to-use solution.
However, as far as we know, no one has created a real-time peer assessment solution, so we built it. 🔨
The Tech team focuses on real business problems like, "Our learners get stuck on MCQs because they don't know how to validate them, we should do something." They help the whole company to deliver a great education experience.
This is important because technical teams sometimes tend to focus on technical problems just because they look exciting. This is not what we do (but don't worry, we have our fair share of interesting challenges 😁).
Organization and Roles
Approximately 30 people work on the Tech team. It is organized following Squad / Feature team model, inspired by Spotify (more data about that here and here). Each squad is autonomous to deliver a feature, meaning it shouldn’t have any dependency on another squad’s tasks. The squad as a whole commits on features, their specifications, designs, and estimations.
A Squad is usually composed of:
1 Product Manager (cf Product team chapter)
1 UX designer
1 UI designer
2 Backend Developers
2 Frontend Developers
1 iOS Developer
These roles should not come as a surprise those who've met tech teams before. 😉Here is a small explanation of each position:
Backend developers: They work on the backend code, crafting PHP code on top of the Symfony framework. They create the inner workings of our systems, which are crucial to delivering the software. They regularly mumble things about "code coverage," "design patterns," and "broken builds."
Frontend developers: They craft HTML, CSS, and JS code to build the frontend pages. They constantly optimize page size and speed. Some say a kitten dies each time someone uploads an unoptimized JPEG file to the servers. 🙀
Mobile developers: At the time of writing, we're just starting to build our mobile apps, starting with iOS.
QA: Their mission is to ensure the project's quality by testing it through every angle from a user point of view. They write tests that can be automatically repeated. Our co-founder, Pierre, previously had this position, but he has turned it over to more specialized people.
Designers: Our UI and UX designers work upstream on each tech project to refine our needs, provide mockups, test them with users, and then design the page before handing it to developers. You can hear them talk about "personas," "alignment," and "golden ratios" while wondering why everyone talks about flat design when we can easily use rounded corners and shadows with CSS.
To ensure consistency of practices, architecture, and design across squads, roles are grouped into chapters: backend, frontend, QA, etc. They have their own meetings, goals, and vision for improvements.
Culturally, the team is very open. Yes, we emphasize excellence, but that shouldn't discourage you from talking to or joining them! You don't need to prove that you've been geeking around since you were a kid. 🤓
In fact, that's quite the opposite. We like to be around people with potential. Several developers come from different backgrounds, like creative arts or sound engineering.
The Tech Team has a CTO (Chief Technical Officer), Romain, who happens to be one of our developers and has been with the company for many years. The CTO drives the platform's technical architecture and design, making sure the team follows his guidelines and ensures everything runs smoothly. He also works closely with the product team, alerting them to potential tech issues, and giving his point of view on every aspect of the product.
The Tech team has developed its own cultural habits when it comes to team collaboration, emphasizing trust, and responsibility. Their experience in agile project management makes them an influential part of the OpenClassrooms organization.
As soon as the product manager builds the strategy and phases documents, the Tech team begins work on a phase. UX starts working on the feature by imagining what it could look like, asking for user feedback, and creating the first rough mockups. This is crucial because they must decide what's going in the feature.
Once they know, they can create the UI. Then the feature is created as a JIRA ticket to be handled by developers. It enters the famous backlog (the never-ending pile of stuff to do). As soon as there are available developers, it enters the next two weeks sprint and follows these steps:
What do these steps mean?
Todo: The task has to be done this sprint. Someone will pick it up.
In progress: The task is being developed (picture someone with a screwdriver 🛠 ).
To review: At least two developers have to check the code to validate it.
To review by UX/UI: Second validation here by the UX and UI designers.
To verify: QA has to check the whole feature from a user point of view. Does it react as expected?
To fix: QA identified issues. Developers have to fix all of them before submitting again to QA.
Verified: The feature is fully validated and is ready to go live.
Done: The feature is live in production! Hooray, it made it! 🙌
We emphasize the meaning of done. To us, done means that it's online on the production servers and that we can use the feature. Before, we had "done stuff" that wasn't in production, so we sometimes forgot it, and it led to an accumulation of features that never saw the light of the day.
What Agility Means to Us
The Tech Team is inspired by the agile manifesto. We used to follow a stricter SCRUM methodology in the past, but we have learned to develop our own methodology, which suits us better. This way, we're closer to the agile principles (SCRUM is just an implementation of agile principles anyway).
What does it mean to be agile? It's a spirit. We prioritize individuals and interactions over processes and tools; working software over comprehensive documentation. We continuously respond to change, because building a three-year plan doesn't work in our environment: there's too much uncertainty and evolution.
Technically, the code should facilitate change, because specs will evolve over time (we use to say that change is the only constant!).
The Tech Team is a bit like a clock when it comes to meetings: they are well defined, regular, and as short and efficient as possible.
They work in a two-week sprint framework: it's a well-defined period in which the team delivers one small iteration of the product.
So, what are those meetings?
Sprint kick off: Every two weeks, the team looks at the backlog, analyzes priorities, and decides what needs to be done for the next two weeks.
Stand up: Every day at 9:45 am sharp, squads meet in the kitchen. Members of the team state what they did yesterday, what they're going to do today, whether they're stuck, and if they need help. This helps everyone stay in touch with what's happening. We've found these meetings useful for making small adjustments throughout the development process. Our former intern Erik wrote about stand up meetings at OpenClassrooms if you want to know more.
Backlog refinement: The team reviews the backlog to improve stories and task accuracy. Each task is analyzed: We estimate how long it will take, and if something needs to be done beforehand. If a task takes more than two days, it is considered too big, and the team will break it into smaller tasks.
Squad’s retros: Every two weeks, team members write down what they've found helpful or not for doing their job and what issues they expect. The squad focuses on how it interacts with each other and works together. This is how they continuously enhance how they work. They share their feelings and look for solutions they can implement over the next two weeks. People keep their egos aside to avoid tensions - and it works! Consider this conversation that happened during one of those meetings:
- "Hey X, you've been impossible to live with. You keep interrupting my work to check on what I'm doing."
- "OK. I'll try not to interrupt you from now on. I'll regroup my remarks on your code at the end of each day if that works for you."
Chapter retros: We must maintain communication and improvement across squads. In chapter retros, a specific chapter focuses on internal improvements. It’s often more technical than the squad’s retro, and it is a way to maintain consistency and community of practices.
Squad commitment: This meeting is critical to our workflow. The whole team reviews the work after each step of the process and gives its “commitment.” Since we all agree on what needs to be done, it keeps us from going back at the end of the process and trying to modify something.
1to1: Each team member has recurrent 1to1 with his/her manager. It is a time dedicated to talking about anything that could help the team or work environment to flourish. It is not a reporting meeting.
The Tech Team usually doesn't have impromptu meetings during the day. When they have other meetings, it's because they need to talk with a developer from another company to build an integration, or because they're interviewing someone who applied for a job in the team.
Our Development Practices
We have implemented many development best practices, including:
Automatic staging deployment
100% test code coverage
We deploy several times a day; sometimes several times an hour. As soon as some code is ready and has been validated (by another developer for code review and a QA for user testing), it's launched into production. 🚀
This helps us add features bit by bit, instead of rolling out enormous changes that can have a big impact. The more lines of code you deploy at the same time, the riskier it is!
We're inspired by the work of Robert C. "Uncle Bob" Martin (check out his Clean Code videos!), Martin Fowler, Kent Beck, and many others.
We have set up a complete clean architecture, which is a bit complicated, but rewarding; it helps us ship high-quality code. While we're not competing to be the best, we do look for excellence as we've said (which looks similar, but with a subtle difference). We were happy to hear from an external auditor that ours was one of the best codes he has seen in all the companies he has audited (not bragging, but we'll put our sunglasses smiley here anyway 😎 ).
We are often asked: "What's your tech stack? Do you use the latest languages? Did you try X.io and Y.js?"
While we're open to using new tech, we try not to use the "latest hot stuff" just because it's hot. Why? Because everything moves very fast and could become obsolete quickly, especially in the front-end world. We need a good reason to add another language to the tech stack.
That said, we use:
PHP: One of the most used web programming languages in the world, powering the likes of Wikipedia and Facebook, to name just two.
Symfony framework: It would be crazy not to use a strong framework like Symfony on top of PHP these days. It facilitates a lot of work: we don't have to reinvent the wheel every time.
PostgreSQL: This has been our database of choice to store our data for many years.
React.js: To provide a more cohesive code and a better front-end user experience.
Amazon Web Services: We're hosted on AWS. We use EC2 instances that we spawn automatically depending on traffic (we have some in-house code for this), S3 for object storage, RDS for databases, etc.
Stand-up meetings are part of the daily routine. The team has developed a curious habit: because these meetings only work when everyone is present, we ask people to be available at 9:45 am sharp. Every time someone shows up late, they get a cross. Three crosses and you have to bring breakfast (we like chouquettes) for the rest of the team. 😋
Does it seem stressful? It really shouldn't be! It's just a cohesive way the team has found to start the day. Everyone participates, and sometimes the CTO even gets a cross. 😉
Chouquettes. More Chouquettes.
Originally, people brought chouquettes when they were late for stand-up meetings. But now, people on the tech team often bring them to the office for breakfast even if no one has shown up late.
If you don't know what chouquettes are, they're sugar-coated French pastries. They're also very addictive.