Create an environment where the Dev team can consistently get new features shipped and issues resolved while regularly communicating their progress and blockers.
♻️ Cycle & Cool Down
Our process is inspired by Shape Up. We don't follow every aspect of Shape Up, but instead view it as a toolbox to draw from to fit our specific needs as a team. Here's a nice overview:
We work in a Cycle of 6 weeks of development followed by Cool Down for 2 weeks:
Before starting a cycle, the Leadership Team (LT) will be framing the next idea and shaping a package for the Dev team. There will then be a Handoff Process with the Dev team before starting the cycle to begin scoping and review for time bombs (i.e. assumptions that may lead to unexpected work).
When a cycle begins, weeks 1, 2, 3, and 4 the Dev team will be coding. Here's how we communicate and stay organized during the 4 weeks of coding development.
Weeks 5 and 6 of the cycle will be for QA testing via the Support Team.
After go live at the start of week 7, we begin Cool Down where we work on nice-to-haves from the cycle and various tasks from dev tasks board (see below).
☀️ Daily Workflow
Every morning - please look over any pending PR reviews first thing when you start working so we're not blocking code getting into Staging or Production.
Regardless of whether we're in a cycle or Cool Down, we meet as a team every Monday and Wednesday to discuss any blockers/questions and review the Dev Tasks board. NOTE: During a Cycle we'll have very few tasks to work on since the team should be primarily focused on cycle work (which lives outside of the task board).
When reviewing the task board we'll look at the 💡 Backlog to see if the team has capacity to move any of those ideas into 🏁 Up Next which is a running list of tasks we're planning to accomplish over the next week.
When you start working on a task move it to 🧑💻 In Progress and assign yourself to it.
Once you merge a PR for the task into Staging, move the task to 🎉 FYI Done so the rest of the company is notified about this change. If the change is purely technical in nature and the whole company doesn't need to know, move it to regular Done.
🚨 Issues
When Support notices an issue/bug, Roger (Head of Support) will add it to 🚨 Issues in the task board and assign it an urgency:
Low (we'll fix to it one day, it can wait indefinitely)
Med (we should fix it within 30 days)
High (we should get to it within 7 days)
Critical (we should stop everything and fix this, all hands on deck)
Issue follow the same workflow as other tasks, so when you start working on one move it to 🧑💻 In Progress.
⤴️ Pull Requests
Request a PR review from msupdatebot – this will automatically trigger a ping in the Development Team campfire to get reviews from the team.
If you want Support Team to QA test something, after you've moved the task to 🎉 FYI Done ping "@support" in the task comments asking them to test it in Staging. Generally you should be testing your changes in Staging first though.
When you're ready, merge Staging into Production. Do not merge into Production after 2pm ET OR on Fridays at all unless it's an urgent bug fix.
You should be submitting a PR every 1-2 days even if you're work is still in progress. The point is to get feedback from other team members and get in the habit of pushing small chunks of work instead of waiting for every part of the task to be completed.
@2x.png)
@2x.png?attachment=true){kind=link}