diff --git a/2_Operations/apps.md b/2_Operations/apps.md index a056215..0a79ff0 100644 --- a/2_Operations/apps.md +++ b/2_Operations/apps.md @@ -8,26 +8,14 @@ We found that a lot of discussions, even work-related, naturally flow into priva If you are on the receiving end of a question or message that should really be posted on a public channel, reply with the following: `Hey! Let's take this to one of our public channels so that others can learn or chip in. I'll re-post and reply there.`. -Here is how we set reminders for daily standups in Slack: +Here is how we set reminders for meetings in Slack: ``` Set up reminders on the week they should be posted before reminder post time. -Sprint planning / sprint retro week: -/remind #operations every two weeks on Tuesday at 8:00 UTC "@here Reminder that stories need to be closed an hour before retro starts." -/remind #operations every two weeks on Tuesday at 11:50 UTC "Sprint retrospective in 10 minutes!" -/remind #operations every two weeks on Tuesday at 11:59 UTC "@here Sprint retrospective starting now!" -/remind #operations every two weeks on Wednesday at 10:50 UTC "@here Add your stories to the To Do pipeline." -/remind #operations every two weeks on Wednesday at 11:50 UTC "Sprint planning in 10 minutes!" -/remind #operations every two weeks on Wednesday at 11:59 UTC "@here Sprint planning starting now!" - -Second week of the sprint: -/remind #operations every two weeks on Thursday at 11:50 UTC “Standup in 10 minutes! Join the appropriate Zoom room or write an #out-of-office message if not attending” -/remind #operations every two weeks on Thursday at 11:59 UTC “@here Standup starting now!” - Weekly: -/remind #operations every Monday at 11:50 UTC “Standup in 10 minutes! Join the appropriate Zoom room or write an #out-of-office message if not attending” -/remind #operations every Monday at 11:59 UTC “@here Standup starting now!” +/remind #operations every Monday at 11:50 UTC “Meeting in 10 minutes! Join the appropriate Zoom room or write an #out-of-office message if not attending” +/remind #operations every Monday at 11:59 UTC “@here Meeting starting now!” ``` #### Channels @@ -40,14 +28,14 @@ How to know which channel to write to? Write to the most specific channel. If yo #### Decreasing Distractions -Slack can be a [big distraction](https://m.signalvnoise.com/is-group-chat-making-you-sweat-744659addf7d), especially if you're constantly receiving notifications or checking for replies. +Slack can be a [big distraction](https://m.signalvnoise.com/is-group-chat-making-you-sweat-744659addf7d), especially if you're constantly receiving notifications or checking for replies. There are settings you can change to decrease distractions. In the Slack app, click on Niteo on top and go to Preferences. Notifications settings will open, and these are the recommended settings: -- **Notify me about**: choose `Direct messages, mentions & keywords`. Uncheck `Notify me about replies to threads I'm following`. If you still get too many pings, try using `Nothing`. -- **Sound & appearance**: check `Mute all sounds from Slack`, audio pings are extremely distracting. Uncheck `Bounce Slack's icon when receiving a notification`, another really annoying distraction. Unchecking `Include a preview of the message in each notification` will help you keep focus by notifying you of the message but not what it's about (where your brain automatically starts thinking about it). If you always need Slack empty of the red icon and click through everything to "clean it", uncheck `Show a badge on Mac on Slack's icon to indicate new activity`. +- **Notify me about**: choose `Direct messages, mentions & keywords`. Uncheck `Notify me about replies to threads I'm following`. If you still get too many pings, try using `Nothing`. +- **Sound & appearance**: check `Mute all sounds from Slack`, audio pings are extremely distracting. Uncheck `Bounce Slack's icon when receiving a notification`, another really annoying distraction. Unchecking `Include a preview of the message in each notification` will help you keep focus by notifying you of the message but not what it's about (where your brain automatically starts thinking about it). If you always need Slack empty of the red icon and click through everything to "clean it", uncheck `Show a badge on Mac on Slack's icon to indicate new activity`. -We encourage you to **quit Slack** when you need time for undistracted work. Make sure that other Niteans that depend on your feedback know that you're away. But unless there's a fire, a few hours of uninterrupted work will only benefit everyone. +We encourage you to **quit Slack** when you need time for undistracted work. Make sure that other Niteans that depend on your feedback know that you're away. But unless there's a fire, a few hours of uninterrupted work will only benefit everyone. You can also use the **bell icon** (Notifications) to disable all notifications for a specific time period. However, this still shows the number of received messages in the Slack app icon (which is a distraction in itself). @@ -98,9 +86,6 @@ Nitean: Dropbox is one of the best file sharing services out there. We have a Business account that gives us terabytes of data. -On top of Dropbox we use Boxcryptor, to give us end-to-end encryption of our files. - For nicer search experience using Alfred on macOS: - * Add `~/Library/CloudStorage/Boxcryptor-Dropbox/Niteans` to `Search Scope` under `Default Results` configuration pane. + * Add `~/Library/CloudStorage/Boxcryptor-Dropbox/Niteans` to `Search Scope` under `Default Results` configuration pane. * Add `~/home//Niteo Dropbox/Niteans` to `Prevent Spotlight from searching these locations:`. - diff --git a/2_Operations/how-we-work.md b/2_Operations/how-we-work.md index 6d48b93..4d2c7ab 100644 --- a/2_Operations/how-we-work.md +++ b/2_Operations/how-we-work.md @@ -20,7 +20,7 @@ In addition there are ad-hoc in-person meetups that happen about once or twice a ## Project And Company Management -We work in 2-week Scrum Sprints described in detail in the [work process](work-process.md) document. +We organize our work using a Kanban board which is described in detail in the [work process](work-process.md) and [kanban](kanban.md) documents. Project and task management is currently done with [GitHub and ZenHub](/2_Operations/apps.md). Support handles tickets through Help Scout. diff --git a/2_Operations/kanban.md b/2_Operations/kanban.md new file mode 100644 index 0000000..a6383e8 --- /dev/null +++ b/2_Operations/kanban.md @@ -0,0 +1,37 @@ +# Kanban + +Our work process is based on [Kanban](https://en.wikipedia.org/wiki/Kanban) with some elements from [Scrum](https://en.wikipedia.org/wiki/Scrum_(software_development)): + + * We are our own *product owners*, as we have no customer projects. + * We work asynchronously, so keep scheduled meetings to a bare minimum. + * We organize our work using a Kanban board. + +Read about [writing User Stories and issues](user-stories.md). + +User Stories that are dependent on each other should be merged into one bigger user story. This kind of User Stories can have 2 assignees. + +## Monday Meetings + +Each Monday we have a meeting to review the Kanban board and check in with our [OKR's](https://en.wikipedia.org/wiki/Objectives_and_key_results). We typically have one meeting per project starting with Operations. + +Turn on your camera during the meeting. Try to refrain from doing other things (browsing, doing support, etc.) during the meeting -- we only have this meeting and it doesn't take a lot of time so we should all pay attention to everyone else for this period. + +## Urgent Production Fixes + +If we need to fix an urgent bug, we use the Scrum *priority lane* approach: the user story gets written and then if the product owner decides it really is urgent, the user story is added to the 'In Progress' pipeline and labeled with Priority Lane so that everyone knows it is an exceptional and urgent issue and the whole team needs to focus on getting it completed as soon as possible. + +## Recurring Tasks + +There are a bunch of tasks we have to do every month/quarter/year. To make sure they get assigned enough time for proper execution, we include them in the Kanban board as user stories. The only difference is, they don't need user story demo recordings since they happen so often and are repetitive. + +For every month/quarter that a recurring task is required we (re)open the issue and create a comment for the new month/quarter. + +## On-Calls + +Sometimes, things break in the middle of the night or on weekends. The great thing about being a remote-first team is that we cover different time zones so there is almost always someone available. The solution for the weekend is to have Niteans on-call. + +Being on-call means being available for any critical, urgent issues that may arise. Some examples of this are servers offline or the product app is down. Each on-call day (Saturday and Sunday) counts as a 2-hour workday, even if there were no emergencies. Any work more than two hours counts as regular work. + +Niteans can be on-call only if they already pass basic support training or has already reported for [Everyone on Support](https://github.com/teamniteo/handbook/blob/master/4_Marketing-Support/everyone-on-support.md). + +Every [Monday Meeting](https://github.com/teamniteo/handbook/blob/master/2_Operations/kanban.md#monday-meetings), we assign who will be on-call for the next weekend and note it in the [Monday Meeting issue](https://github.com/teamniteo/operations/blob/master/.github/ISSUE_TEMPLATE/monday_meeting.md). diff --git a/2_Operations/next-task.md b/2_Operations/next-task.md index 456b7b4..d1bda82 100644 --- a/2_Operations/next-task.md +++ b/2_Operations/next-task.md @@ -1,19 +1,18 @@ # Find Your Next Task -We do most of our work through sprints so if you are in one, make sure you are completing those tasks first since they are our current focus. If for some reason you are not in the sprint, because of onboarding or finished your tasks, follow the steps below. +Make sure you are completing your assigned tasks first since they are our current focus. If for some reason you don't have any assigned tasks, because of onboarding or you've finished them, follow the steps below. If all else is completed, you can always read a book, take an online course or just think about how we could make the company better. ## Developers - - Go through issues in our [backlog]. Choose a task that you like and if is not on a sprint then ask the Scrum master if you can start working on it. + - Go through issues in our [backlog]. Choose a task that you like and start working on it. - Search the codebase and documentation for "TODO", "XXX" and similar strings. Try to understand why it's there and create an issue for it. If you like the task, you can start working on it immediately. ## DevOps and Support - First focus on whether our systems are running smoothly and that all our customers' issues have been resolved and answered. - Review our [handbook] documents, updating as necessary. - - If you are DevOps and have had no tasks for some time, you can join the next sprint. - If you are support and have had a slow few days, start reading on how we could improve our support. This may include improving our processes or rewriting our responses. ## Marketing diff --git a/2_Operations/scrum.md b/2_Operations/scrum.md deleted file mode 100644 index bcee465..0000000 --- a/2_Operations/scrum.md +++ /dev/null @@ -1,66 +0,0 @@ -# Scrum - -Our work process is based on [Scrum](https://en.wikipedia.org/wiki/Scrum_(software_development)), but modified to suit to our specific needs: - - * We are our own *product owners*, as we have no customer projects. - * We work asynchronously, so keep scheduled meetings to the bare minimum. - * We schedule our work into two week long *sprints*. - * We manage our sprints with GitHub and ZenHub. - -To put it in simple terms: **product owner defends the users, scrum master defends the team**. Ideally, this relationship brings the best results for users while not overworking the developers. - -Read about [writing User Stories and issues](user-stories.md). - -User Stories with the highest story points are assigned and started first. That way simpler User Stories without champions can be worked on in the last days of the sprint by anyone who finished their own early. - -User Stories that are dependent on each other should be merged into one bigger user story. This kind of User Stories can have 2 champions. - -Support tasks take priority over sprint for support and DevOps team. - -For each sprint, a new milestone is created with the name `Sprint #X` where `X` is the number of the sprint (e.g. `Sprint #4`). On Scrum sprint planning each user story that is added to the planning sprint must be also added to the new milestone. With this ZenHub will automatically generate a burndown chart and we avoid having an additional label (`Sprint #X` label). - -## Standup Meetings - -Standup meetings are short meetings every Monday and Thursday where we go over the work done and what still needs to be done. It is also where we discuss any blockers and where project managers can keep a tab on workload. Company discussions, announcements and updates are also done on these meetings. The order for Niteans on standups is alphabetical on Nitean's first name. Every project has its own standup time. - -Turn on your camera during the standup. Try to refrain from doing other things (browsing, doing support, etc.) during the meeting -- it rarely takes more than 15 minutes and we should all pay attention to everyone else for this period. - -## Sprint Planning - -Each sprint starts with planning. This is where we choose well-defined User Stories to put in the sprint. We always keep in mind our quarterly goals to make sure we're doing the tasks that are moving us in the right direction. - -The Scrum master creates a new [Sprint issue](https://github.com/teamniteo/sprint/issues/new?template=planning.md&title=Planning%20for%20Sprint%20#) before each planning. - -## Sprint Retrospective - -After each sprint, we have a retrospective, where we think about what went well during the sprint, what went wrong and what improvements could we make. - -This is also the time to bring up any other comments about the work process in general. - -We look at how many story points we assigned, how many were done and the distribution between the departments and types of User Stories. - -The Scrum master adds the Sprint Retrospective comment into the Sprint issue. It serves as a checklist for the meeting and helps the Scrum master write up a brief report afterward. - -## Urgent Production Fixes - -If we need to fix an urgent bug, we use the Scrum *priority lane* approach: the user story gets written and then if the product owner decides it really is urgent, the user story is added to the top of 'In Progress' pipeline and labeled with Priority Lane so that everyone knows it is an exceptional and urgent issue and the whole team needs to focus on getting it completed as soon as possible. - -## Ongoing Tasks - -Sometimes the result of a user story is an agreement that we should do a certain task periodically, over a longer period of time. Such tasks are created in whichever repo is the most appropriate and labeled with Ongoing label. - -## Recurring Tasks - -There are a bunch of tasks we have to do every month/quarter/year. To make sure they get assigned enough time for proper execution, we include them in sprints as user stories. The only difference is, they don't need user story demo recordings since they happen so often and are repetitive. - -For every month/quarter that a recurring task is required we (re)open the issue and create a comment for the new month/quarter. - -## On-Calls - -Sometimes, things break in the middle of the night or on weekends. The great thing about being a remote-first team is that we cover different time zones so there is almost always someone available. The solution for the weekend is to have Niteans on-call. - -Being on-call means being available for any critical, urgent issues that may arise. Some examples of this are servers offline or the product app is down. Each on-call day (Saturday and Sunday) counts as a 2-hour workday, even if there were no emergencies. Any work more than two hours counts as regular work. - -Niteans can be on-call only if they already pass basic support training or has already reported for [Everyone on Support](https://github.com/teamniteo/handbook/blob/master/4_Marketing-Support/everyone-on-support.md). - -Every [sprint planning](https://github.com/teamniteo/handbook/blob/master/2_Operations/scrum.md#sprint-planning), the Niteans on-call for the two weekends will be assigned and noted on the Sprint issue. diff --git a/2_Operations/user-stories.md b/2_Operations/user-stories.md index ff302ae..f11c250 100644 --- a/2_Operations/user-stories.md +++ b/2_Operations/user-stories.md @@ -1,11 +1,12 @@ # User Stories -User Stories are well-defined tasks to be done by a Nitean that have a specific, measurable goal and impact. The vast majority of issues are written as User Stories, and only issues created by support that are reactionary and straightforward are not. Support issues are also not included in sprints. +User Stories are well-defined tasks to be done by a Nitean that have a specific, measurable goal and impact. The vast majority of issues are written as User Stories, and only issues created by support that are reactionary and straightforward are not. All User Stories are located in their project repositories: - EBN project: [`teamniteo/easyblognetworks`](https://github.com/teamniteo/easyblognetworks/) -- KAI project: [`teamniteo/kai`](https://github.com/teamniteo/kai) -- WooCart project: [`teamniteo/woocart`](https://github.com/teamniteo/woocart) +- Pareto project: [`teamniteo/pareto`](https://github.com/teamniteo/pareto/) +- Rankalyzer project: [`teamniteo/rankalyzer`](https://github.com/teamniteo/rankalyzer/) +- SEO Domain Finder project: [`teamniteo/sdf`](https://github.com/teamniteo/sdf/) - Company issues: [`teamniteo/operations`](https://github.com/teamniteo/operations/) We have many repositories for each project but we write all User Stories in the main repository. @@ -36,7 +37,7 @@ Finally, take a bit of time to consider at least one pitfall (downside) to imple The Best Practices are a list of items that should relate to the Story and guide the writing of the Expectations for completion of the Story. -All major features should have a blog post written. If you are not sure if it should be written or not, ask the Scrum master or product owner. The marketing team writes and reviews the details of the actual blog post. +All major features should have a blog post written. If you are not sure if it should be written or not, ask the project lead or product owner. The marketing team writes and reviews the details of the actual blog post. ### Expectations (Acceptance Criteria) @@ -44,29 +45,28 @@ The expected outcomes of the User Story which is a list of items stating how the ## Story Points -A [Story Point](https://agilefaq.wordpress.com/2007/11/13/what-is-a-story-point/) is an arbitrary measure used by Scrum teams to indicate the effort required to implement a User Story. One full-time member on sprint should be able to do 10 Story Points. That said, there should be 2 Story Points reserved for code reviews, cleanup, writing new User Stories, catchups, mentoring, and pair programming. +A [Story Point](https://agilefaq.wordpress.com/2007/11/13/what-is-a-story-point/) is an arbitrary measure used by Scrum teams to indicate the effort required to implement a User Story. Story points are not a representation of time, but rather a combination of Risk, Repetition, and Complexity. However, we typically think of one story point as the amount of work a person can do in one day. ## Pipelines -From initial creation to being worked upon and finally closed, a User Story will be moved to different pipelines as it progresses through a sprint. This is a summary of the workflow of a User Story: +From initial creation to being worked upon and finally closed, a User Story will be moved to different pipelines as it progresses through the Kanban board. This is a summary of the workflow of a User Story: 1. **New Issues** - New work-in-progress (WIP) User Stories, also includes bugs or issues. 1. **Estimation** - Defined User Stories, ready for verifying and Story point estimation. -1. **Backlog** - Waiting for inclusion in a sprint. They are adequately defined with assigned Story points. -1. **To Do** - In the current sprint with a champion assigned to work on it. -1. **In Progress** - Being worked upon by the champion during the current sprint. +1. **Backlog** - Waiting to be started. They are adequately defined with assigned Story points, and is typically also assigned to a Nitean. +1. **In Progress** - Currently being worked upon by the assignee. 1. **Review** - Completed with a demo uploaded and awaiting final review. 1. **Closed** - All defined expectations have been met. ### Estimation -For the User Story to be included in a sprint, it must be verified and voted upon. To start this process put the User Story in the `Estimation` pipeline. +For the User Story to be moved to the **Backlog**, it must be verified and voted upon. To start this process put the User Story in the **Estimation** pipeline. -The Scrum master and product owner will verify that the User Story is well defined. If required they will assign people from whom they want to receive feedback for better definition of the User Story. Once these assignees post their feedback, they remove their assignment from the User Story. +The project lead and product owner will verify that the User Story is well defined. If required they will assign people from whom they want to receive feedback for better definition of the User Story. Once these assignees post their feedback, they remove their assignment from the User Story. #### Voting -Once the User Story is verified the Scrum master assigns team members from whom they want to receive Story point estimations. Team members vote on a Story by adding a comment with their Story point estimation to the User Story, then remove their assignment from the User Story. +Once the User Story is verified the author assigns team members from whom they want to receive Story point estimations. Team members vote on a Story by adding a comment with their Story point estimation to the User Story, then remove their assignment from the User Story. To not influence anyone else's voting, we hide these estimate values in comments by using the following code snippet: @@ -81,9 +81,9 @@ To not influence anyone else's voting, we hide these estimate values in comments ### Backlog -After a User Story in `Estimation` pipeline has been voted upon, the Scrum master checks for consensus on the Story points and sets the estimation to that value then moves the User Story to the top of the `Backlog` pipeline. +After a User Story in **Estimation** pipeline has been voted upon, the project lead checks for consensus on the Story points and sets the estimation to that value then moves the User Story to the **Backlog** pipeline. -With a well-defined Story and Story points, the User Story is now ready to be included in the next sprint. +With a well-defined Story and Story points, the User Story is now ready to be worked on. ## Assignment @@ -92,9 +92,9 @@ You are assigned to a User Story or issue when something is required from you: - Provide feedback to further the User Story. - Estimate the Story Points needed to complete the User Story. -- Champion the User Story in a sprint. +- Work on the User Story to complete the expected goals. -You must keep your assignment if the User Story is included in the current sprint and is already in progress. This allows us to see who worked on what even when the sprint ends. However, if the User Story is not in the current sprint and your task is complete, you may remove your assignment and unsubscribe from notifications. +You must keep your assignment to the User Story from when you work on it until it is reviewed and closed. This allows us to see who worked on what even when the User Story is closed. ## Demos diff --git a/2_Operations/work-process.md b/2_Operations/work-process.md index c0549d2..a9e65a2 100644 --- a/2_Operations/work-process.md +++ b/2_Operations/work-process.md @@ -2,48 +2,24 @@ ## Schedule -* Every **Monday and Thursday** morning we hold a standup meeting: - * 12:00 UTC for the whole company in the Niteo Zoom room - * followed immediately by separate standups for Easy Blog Networks and Pareto, synchronously in their own Zoom rooms -* Every other **Tuesday and Wednesday** morning we have [Scrum meetings](https://github.com/teamniteo/handbook/blob/master/2_Operations/scrum.md): - * Retrospective on Tuesday, Planning on Wednesday - * 12:00 UTC for the whole company in the Niteo Zoom room - * followed immediately by separate meetings for Easy Blog Networks and Pareto, synchronously in their own Zoom rooms - -Niteans are encouraged to take Fridays off for a long weekend. Same as any other vacation off, make sure that your backup Nitean is available to handle any potential issues (see [Vacation policy](https://github.com/teamniteo/handbook/blob/master/5_People/benefits.md#vacation)). +* Every **Monday** we have a [meeting](https://github.com/teamniteo/handbook/blob/master/2_Operations/kanban.md#monday-meetings): + * 12:00 UTC for the whole company in the Niteo Zoom room followed immediately by separate meetings for the projects in their own Zoom rooms. * Every weekday Niteans should check their [GitHub notifications](https://github.com/notifications) so that they don't miss things that involve them. -Sprint meetings replace the daily standup on these days: - - * A **Wednesday** is the start of a sprint with sprint planning. - * 12:00 UTC for the whole company in the Niteo Zoom room - * followed immediately by separate plannings for Easy Blog Networks and Pareto, synchronously in their own Zoom rooms - * The **Tuesday**, two weeks later, marks the end of the sprint with a sprint retrospective. - * 12:00 UTC for Niteo - * followed immediately by retrospective for Easy Blog Networks and Pareto, synchronously in their own Zoom rooms - * The **Thursday** after sprint planning, there is no daily standups. [Developers Session](#developers-session) is scheduled immediately after a standup the following week, either Monday or Thursday, depending on everyone's availability. - -The last Monday morning of the sprint everyone should open up the Scrum board and ask themselves: "How can I help close whatever is still opened?". Repeat the same after lunch and on Tuesday morning. - -For each new sprint, the Scrum master will create a sprint release that is used to store the user story screencast demos. The template for this release is copied from [RELEASE_TEMPLATE.md](https://github.com/teamniteo/operations/raw/master/.github/RELEASE_TEMPLATE.md) in the operations repo. +* A [Developer Session](#developer-session) is scheduled when we have a fair amount of items to talk about and is typically held right after the Monday Meeting. -## Scrum - -Our work process is based on [Scrum](https://en.wikipedia.org/wiki/Scrum_(software_development)). Read in detail about [our Scrum process](scrum.md) and writing [User Stories](user-stories.md). - - * Sprint length is two weeks. - * Story points commitment: 10 for each full-time member on the sprint. The total team commitment has at least 25% reserved for bug fixes and cleanup. +Niteans are encouraged to take Fridays off for a long weekend. Same as any other vacation off, make sure that your backup Nitean is available to handle any potential issues (see [Vacation policy](https://github.com/teamniteo/handbook/blob/master/5_People/benefits.md#vacation)). ## Quarterly Review and Planning Every quarter we take time to review, reflect, and plan for the next quarter. There are three tasks for the Quarterly Review and Planning: Partners Meeting, Quarterly Review, and All Hands Meeting. -## Developers Session +## Developer Session We are a remote company and as such sharing of ideas and lessons learned is impaired by the fact that we don't have the time or space to do that effectively. -In the long term, this is hurting everyone and as such `Developers Sessions` are a way to discuss ideas and questions that might have arisen during retrospective or the sprint. Followed by a short lightning talk(s), which can be impromptu or declared beforehand so others can join. +In the long term, this is hurting everyone and as such the Developer Session is a way to discuss ideas and questions that might have arisen lately. Followed by a short lightning talk(s), which can be impromptu or declared beforehand so others can join. You can learn something from every single person in the world, no matter what their opinion on any topic is. We also believe that this is a big part of open source and our company, being able to learn and collaborate with people from all over the world who have a wide variety of different opinions on how to do things. On the other hand, a lightning talk can be a perfect way for testing how people react to a talk that you are going to have at next conference or just getting rid of that presentation fear in front of people. @@ -53,17 +29,17 @@ In order for things to not explode, the Session is limited to 60 minutes. As an attendee, ask yourself: -- Did I have a problem with understanding of implementation I saw during the sprint? +- Did I have a problem with understanding an implementation I saw recently? - Was I annoyed by a particular workflow or something that I think is wasting my time? - Did I find a handy tool/method/module that I think we should use? -- Do I have an idea about implementation we will have in the next sprint, and I want to discuss it? +- Do I have an idea about implementation we will have in the upcoming weeks, and I want to discuss it? - Have I seen a great technical talk and I want to share it so we can discuss it the next time? - Do I want to share something I learned in a short lightning talk? - Do I need help with the user story I have been assigned to? As a curator: -- Announce in #development Zoom session to join into. +- Organize which time to have the session and annoince it in #development when it's time to join and which Zoom room to use. - Prepare a joke or something funny to share. - As a curator, meet and greet everyone, especially first-time joiners. - Announce who is having the Lightning talk if one was prepared. diff --git a/4_Marketing-Support/everyone-on-support.md b/4_Marketing-Support/everyone-on-support.md index d3c74e0..18469cd 100644 --- a/4_Marketing-Support/everyone-on-support.md +++ b/4_Marketing-Support/everyone-on-support.md @@ -27,7 +27,7 @@ Report for EOS once every month. Having it as a full working day duty affords be ### III. Schedule -Everyone will set their own schedule and keep with it. Update the [recurring Sprint Story](https://github.com/teamniteo/easyblognetworks/issues/238) with your preferred date during sprint planning. +Everyone will set their own schedule and keep with it. Update the [recurring User Story](https://github.com/teamniteo/easyblognetworks/issues/238) with your preferred date during the Monday Meeting. # Further Reading: diff --git a/5_People/catchups.md b/5_People/catchups.md index c3f4dd0..86a4710 100644 --- a/5_People/catchups.md +++ b/5_People/catchups.md @@ -1,6 +1,6 @@ # Catchups -Once every sprint (i.e. two weeks) Niteans have Catchup meetings (also called One on Ones) with a senior team member in order to catch up. This feedback is important as everyone works remotely so we have less contact and less of an idea of what's going on with individuals. We want to know how we can help everyone work and feel better in the company. It's also an opportunity to discuss your career at Niteo. +Once every few weeks, Niteans have Catchup meetings (also called One on Ones) with a senior team member in order to catch up. This feedback is important as everyone works remotely so we have less contact and less of an idea of what's going on with individuals. We want to know how we can help everyone work and feel better in the company. It's also an opportunity to discuss your career at Niteo. This is your opportunity to discuss anything you want so they should be treated as more of a *beer in a coffee shop* than an *interview-style* meeting. diff --git a/Makefile b/Makefile index c740f64..e8f2f8e 100644 --- a/Makefile +++ b/Makefile @@ -1,4 +1,4 @@ -chapters := README.md $(wildcard ?_*/*.md) +chapters := README.md $(wildcard ?_*/*.md) all: dist @@ -24,7 +24,6 @@ https://github.com/teamniteo/ebn,\ https://github.com/teamniteo/woocart,\ https://github.com/teamniteo/support,\ https://github.com/teamniteo/finances,\ -https://github.com/teamniteo/sprint,\ https://github.com/teamniteo/my-niteo-career,\ https://github.com/settings/replies,\ https://github.com/notifications,\ @@ -47,7 +46,7 @@ dist: dist/niteo-handbook.epub --from gfm \ --output dist/index.html \ --metadata title="Niteo Handbook" - + dist/niteo-handbook.epub: $(chapters) @mkdir -p dist/ @cat $(chapters) \ @@ -55,4 +54,4 @@ dist/niteo-handbook.epub: $(chapters) --from gfm \ --output dist/niteo-handbook.epub \ --metadata title="Niteo Handbook" - + diff --git a/README.md b/README.md index 5e484e2..eaee59b 100644 --- a/README.md +++ b/README.md @@ -15,7 +15,7 @@ The structure of the Handbook mirrors our departments for simple organization. B * Work Process * [How We Work](/2_Operations/how-we-work.md) - * [Work Process](/2_Operations/work-process.md) and [Scrum](/2_Operations/scrum.md) + * [Work Process](/2_Operations/work-process.md) and [Kanban](/2_Operations/kanban.md) * [Find Your Next Task](/2_Operations/next-task.md) * [Investment Strategy](/2_Operations/investment-strategy.md) * Guides