Apart from the hard skills that I have deepened throughout the project weeks at Le Wagon I learned a lot on how to develop a product as a team.
How did we organize as a team & develop the product?
- We started out by writing down relevant user stories, decided on which ones are in scope & ordered them by priority in our backlog.
- We drew the user journey as a process for a doctor & for a patient.
- We created wireframes using Figma and presented an interactive prototype version of it in front of the class.
- Based on the feedback we refined our Figma design to more visual mockups.
- We created a database schema with all relevant data fields, joining tables and foreign/ primary keys.
- Only then we started coding: Each team member chose a user story and implemented it from start to end. We did not divide the team into frontend and backend. Instead, I was responsible for my feature from routes, controller actions, user permissions, database migrations to views to make it work and look consistent. Working progress was committed & when I thought the feature was implemented as expected and the functionalities tested, I would push my branch to GitHub and create a new pull request.
- To verify our product concept, we spoke to doctors and patients about the problem and our proposed solution. Throughout the implementation we conducted user testing to improve the UX workflow & ensure a good user experience.
- We had at least one standup a day to check who is doing what, if we can help each other etc. We did some code pairing when one of us was stuck. We stopped coding once or twice a day to discuss design, workflow & implementation questions.
What are my key learnings?
- Agree on one design and create CSS components. Even though the four of us spend quite some time on creating mock-ups using Figma for the second project, the mock-ups for the different views were not very consistent. Thus, I decided to create standard CSS components for buttons, cards, input fields, etc. of the project, before the team starts coding. By using CSS variables, we always had the opportunity to change the design across the app easily & consistently.
- Let users try your app. Letting a user - without the knowledge of the whole concept - click through one’s app, is eye-opening in terms of what is an intuitive workflow and what not. Based on user feedback we e.g. changed the doctor’s profile view drastically in the the middle of the project. This was costing time, and we might have been able to implement another feature instead, but I learned to rather make the few things good than shipping half-thought-through features.
- Embrace democratic decisions. We decided not have a lead person in the team. Instead, ideas and feedback were discussed in the team. For sure, the downside of not having a lead person was, that all having different opinions lead sometimes to long discussions. However, we managed to always come up with compromises contributing to our project goals with a suitable solution. This way we shipped a product that we all can now be proud of.
- Do real code reviews. We definitely did not use the full potential of git & reviews. Functionality was tested, but comments on pull requests contained rarely suggestions for code improvements and even if we are juniors we all have strength that we can use to help others improve their skills. In the next project I would also agree on coding best practices & standards, to create a more consistent code base.
- Be truly agile. All in all, it was incredible what we achieved in two weeks. You do not need weeks or month of preparation time for planning a product. If you work hard for a day on the value proposition, user stories and some mockups, you have a great project starting point to get coding. Once started, you can still discuss open points with your team members and adapt concept flaws.
- Don’t get stuck in a feature for too long. With five or 10 days of implementation time, you cannot afford loosing a day or more of one full developer’s resources, because he is stuck in an issue. Research on the internet, ask your team members for help. If you don’t find a solution, discuss in your team if you can find a work-around or - if not a core feature - decide not to ship this feature for the MVP.
- Bootstrap can be handy. When you have little time to ship a product, it can help you make your MVP’s design look clean. We used Bootstrap for the first project, but avoided to use it for the second. The advantage: Add proven styling to your app in a fast manner without needing to think about organizing your css. Personally, I would only use it for projects with a time frame of less than a week. For everything longer I prefer to create own css components for flexibility and individuality reason.