Standups
We utilize a service called Standuply.
Standuply is a program that runs text-formatted stand-up meetings in Slack. It helps our distributed teams organize and run stand-ups no matter the distance, and posts the results to the #dev Slack channel.
These standups are utilized in many ways. The most important one being directed at the engineer.
Enforcing Structure
The daily Standup forces one to come up with a daily plan. In the vein of Aim => Fire => Check Target.
Without this the engineer's day becomes a mixed slurry of bug-fixes and random PRs. This is absolutely the main thing to avoid. On the other, more common, side the standups function as a way for managers to see the results of how an engineer planned their tasks and executed them. If there were plans to create a large feature but were not attained during the specified timeframe, this is cause to bring up in a Check-In.
Devs should be able to make daily visible; measurable changes. Publish, ship, and work in the open. Work without output has no value.
Distributed devs must take ownership and learn to have self-discipline. If they can't plan a single day that is a huge problem.
There are three Standuply Reports. The first takes form as a weekly stand-up where each dev writes down their contributions to $GVNG and inputs them into a report.
The second is a daily standup that is filled out individually by them every day.
The third is a weekly standup asked at the end of the week that collects the engineer's hours spent on projects assigned to them, tasks related to bugs/misc, and their total logged hours on Upwork.
Examples of all are available to view.
Filling out Stand-ups
These reports provide critical information and updates from engineers that helps better improve engineering's context for overall work and progress throughout the organization. Therefore, it is of utmost importance the answers received from both both standups are as clear and precise as possible.
Daily Standup Questions 1 & 2:
How many PRs have you approved since the last standup?
How many PRs have you rejected since the last standup?
PR Aprovals & Rejections
Engineers should actively approve and reject PRs throughout the week. If they have not approved or rejected PRs, they should note as to why on their daily Standuply Report. This explanation should be added to the daily standup's 5th question by selecting "No" and adding their reason there.
Examples:
Response:
Research x = BAD
Response:
Create Research Summary Doc = Good
Response:
Create RSD comparing 3. popular tools w/ recommendation = Better
Response:
'Will work on X” = NEVER
Daily Standup Questions 4 & 5:
Keeping the above in mind, what do you plan to accomplish before the next standup? Do not include reviewing PRs as part of your answer.
Look at your plan from the previous standup. Did you successfully complete it?
Specific and Measurable Responses
When responding to the questions from Standuply it is imperative to be descriptive and avoid vague statements. The response needs to be a measurable, durable change to the repository. Thinking and planning is acceptable as long as there is actual verifiable output.
For example:
What do you plan to accomplish before the next Standup?
“I wrote up a doc researching and comparing the different ways to fix
<issue>and it is available in a PR/issue/slack post”"By EOD, the
<component>will change to teal when :hover is triggered."
are the correct responses, not:
What do you plan to accomplish before the next Standup?
“I thought a lot about how to fix
<issue>”"Will work on
<component>."