Our developer Way of Working: a project at Elements

As a Developer at Elements, whether it’s mobile or web, you work on one or two different projects at the same time. This way you have focus on your codebases, but also some variety in your work. To run every project as smoothly as possible we defined a Way of Working in our team for every project. Who is responsible for what? How do we document and communicate? What is our Definition of Done? It’s very important to define such things so everyone knows what to expect. Especially the new developers in our team. Read all about what it’s like to work for clients like KPN, AVROTROS and Campercontact. 

Choosing the team and tech

At the start of every project it’s time for putting together the right team for the project. Of course we have to check who is available, but more important who is a match with the client and the expected techniques that we will use. A project always consists of a Project Manager/Scrum Master, Product Owner, Security Lead and 1-5 Developers, depending on the size of the project. Sometimes it’s an all mobile project but it can also be a mix of developers when we need both mobile and web. Also it’s a possibility that you will work together with developers from the client. 

Once the team is composed we will define, together with the client, what exact techniques and tools the team will use. Sometimes the client already has a product we need to upgrade or connect, sometimes they need a totally new product. Developers are definitely included in this so everyone knows what we will use and also why we made these decisions. If needed they can consult one of our experienced Tech Guides. Especially if we are working with Developers (and/or Designers) from the clients team, the Developers are included very early in the process. As you may know Elements is part of MakerStreet, so we also team up with Developers from other labels within our community.

‍

The Agile Way of Working

What is our development flow? This can be different within each project, but most of the time our general Way of Working looks like this:

1. The Project Manager/Scrum Master, together with the Product Owner, makes sure the user stories are created and contain the necessary information to be picked up by a Developer.
2. The development team refines these stories when needed, usually with input from the Product Owner.
3. Developers implement the features or changes and create merge requests.
4. Merge requests are peer-reviewed by another developer before being merged into main.
5. Once merged, the code needs to be tested. Soon we will tell you more about this in another blogpost. 

Prior to this flow, we alway define the Definition of Done criteria for tasks in each project. These can include tests, quality checks or security checks.  

Most of the time the Scrum Master/Project Manager or Product Owner is responsible for the overall planning and priorities in user stories, so our developers can focus on writing code. For all the user stories we use templates, to make sure the right information is added to the ticket and the developer can handle it right away. In most of our projects we work Agile/Scrum, so you can expect a daily standup, sprints of 1-3 weeks and a retrospective to evaluate the project. We not only focus on the work being done, but more importantly we focus on the team. How is every developer doing, how is the teamwork going, is there a healthy workload, does everyone get the help they need? Every developer needs to be able to grow in their role, feedback and knowledge sharing means a great deal in this.    

‍

Communication and documentation

Communication is key within the team, just as important is the communication between the team and the client. The outline and deadline of the project is handled by sales and the Project Manager. After that there is a detailed plan made together with the team. The small questions around this plan need to be communicated quickly by the developers. That’s why we use channels like Slack to communicate with the client. There are decisions made about who is communicating what to whom and also the frequency. All depending on the team and the client.

Every time we make a decision we document these. This way, the client, team and other developers in the company can find all the information. During the project you have a reference to go to, but this knowledge can also be used during next projects. What went well, can we use this in other projects? What could we do differently? Not only in the retrospective, but also in monthly All Hands meetings, we share those best practices with the rest of our colleagues.

Finalizing the Product 

As you can read we are working on projects from A to Z, as a developer you are connected early in the process and stay until the product is live, or even after. You can see the whole process and how the product is used by the client. After the project is live, most of the time, our work is not done. We have to maintain and update the product and we can add new features to it. This is all marked in the Roadmap of the project and often decided before the product is live. Last but not least, we celebrate the finish of a project and have one last feedback round. Not only the developers are getting feedback, also the project manager and tech guide. This way we all benefit and can do some self reflection about the work and teamwork that’s been done.

We can talk all day about our projects but we think we gave you a general idea of what it’s like to work on an Elements project. Do you want to know more about working at Elements? Check our careerpage or ask your questions at careers@elements.nl 

‍