How our development team works
Standing Meetings
Daily meeting at 830a Eastern time USA Monday Through Thursday. Attendance is "flex" mandatory.
Weekly All Hands meeting at 10am Eastern time USA on Friday. Attendance is "flex" mandatory.
Meeting rules
If you can't make it beforehand, try to give a summary to the team in slack on what you're working on. Send to your manager, and to the #engineering channel.
Meetings begin promptly at their scheduled time. If you can't make it, people won't wait on you.
Meetings follow a standard agenda if they are a standing meeting. Our goal is to make these meetings as short as possible.
Daily Agenda
Each member of the team goes around and states: 1) What they got done yesterday, 2) What they're going to get done today, and 3) Anything blocking them to get done.
Coordinate other meetings that need to happen for the day
Sign off
Weekly Agenda
This is stored in Google Docs. It is available here.
Culture
Ask for help when you’re lost. Not asking questions is considered a failure. You know you’re on your own and you need to take an initiative, and when no one can help you move forward. At that point still ask for opinions that might help you understanding the problem and make a decision.
Not providing help when asked to is also considered a failure.
Build good work, strive for good quality, but not perfect quality. Perfect takes 5 times as long.
Write as LITTLE code as possible, as the easiest code to maintain is the code we don't write.
Don't build capabilities we don't need yet. Don't over-engineer the solution.
Write unit tests while developing, but then write a "real" test that is more integration like for your actual check in/pull request. Comment out your unit tests as they burn time in the CI suite, but leave them in for documentation and dev testing purposes.
Product owner
Product owner will organize tickets into a weekly iteration
Other people can create tickets, and they will be prioritized
Product owner owns building the iteration in a way that it's achievable
Development process
We will not scope tickets to larger than 1 week timeframe. Each week, all the tickets should be able to be done. If it can’t be closed in a week, it’s not a ticket, it’s a project.
If you have a question, you have the task to get to the person and get your question answered. You are still responsible for your delivery of the ticket in its iteration.
If you can’t get something done in the estimate supplied, you have the responsibility to provide feedback and update the estimate. It is not the estimator’s job to come to you and ask.
When a pull request gets issued, its your job to get it into production. It will create a card on the board.
General
Every Monday we decide what to work on that week (iteration) and commit to deliver it by Friday, when we report it in front of the other company members at the all hands meeting. Complete delivery is not obligatory, but we tend to do our best. If we finish everything we planned, we can take more stuff in.
Commits (good practice)
write ticket numbers into commit messages
be descriptive, but keep it short
Deploying to production
When someone gets something ready for code review, another developer will review it
When approved, it will get merged into master
We push the front end every Monday AM CET, and more often as needed. Once this is done, everything in the DONE column is archived/closed
Tickets
Bug reports
Tickets about bug reports should be defined in the IS/SHOULD structure with mandatory screenshots, links or even screen recordings.
Enhancements/Feature
should be defined at the most
should be descriptive
give examples, designs, etc
Last updated