First 30 Days - 101

First 30 Days Best Practices

May 23, 2018 uploaded by Admios Facilitator

First 30 Days Best Practices

First 30 Days Best Practices - First 30 Days - 101

First 30 Days Best Practices

Mission

First 30 Days Mission

The first 30 days of any account are an important time period. During this early phase you not only prove the worth of the Admios team but you frequently also set the patterns for the entirety of the account. Additionally, every Admios account starts with a 30 day trial. If there are any problems with the account during this phase we frequently don’t invoice and are not paid. This is a risk we take because we believe in the quality of our developers and the best way to show we’re the best is to get working and deliver. It is very important to get used to the culture and working environment as soon as possible. Trustworthiness is key, we have trust in you and your work so don’t let the team down.

Goals

  1. Your primary goal should be to demonstrably exceed the velocity of existing internal team members within one month delivering defect free code that meets all feature requirements.

  2. Your secondary goal should be to build rapport with all client stakeholders so they want to continue to work with you

You need to meet both of these goals if expect for us to keep the account longer than 30 days.

DO NOT ASSUME YOUR NEW CLIENT WILL JUDGE YOUR WORK ON THE SAME BASIS AS YOUR PRIOR CLIENT

Introduction

Best Practices

What follow are the best practices that should be followed during these first 30 days (and after) to help achieve the goals above.

We are categorizing this in 2 main topics:

  • Communication
  • Development/QA

Communication

  • Make sure there is a daily meeting and you are included.

    • Make sure you are ready 5 minutes prior to the meeting in a quiet environment

    • Practice your update prior to the meeting so you don’t stumble

    • Be clear and concise

    • Ask any questions

      • Always remember that there are not wrong questions. It is better to ask early than spend time trying to reinvent the wheel

  • Make sure you know where to send an end of day email (both at the client and internally at Admios)

    • Provide feedback regarding grasping and understanding of the code

    • Make sure your report has this information on every task if you get assigned to any on this period

      • Task id

      • Task Name

      • Task Status

        • In Progress

        • Done

      • Short description of your current approach

  • Make sure you know where the requirements system is

    • Make sure you know how/when to update your stories

    • Make sure you actually do update them

  • Make sure there is a system that is open all day where you can ping on client stakeholders

    • Make sure you identify who you ask for feature level questions

    • Make sure who you can ask for technical coding questions

    • Make sure you know who is handling QA

    • Make sure you are available on this system all day

      • If you leave for lunch/bathroom then update your status

  • Make sure you know how velocity is measured and what the velocity of an existing developer looks like

  • What are the working hours at the client? Can you match them?

  • Make sure you have a weekly meeting set up with Kelly and Peter

  • Log your time daily in less than 2 hour increments.

    • Round to the nearest 1/4 hour. No ten minute time entries. 1 hour 5 minutes is 1 hour, 1 hour 10 minutes is 1 hour 15 minutes.

    • Make sure vacations, team meetings, etc. are represented so your week adds up to at least 40 hours. Bill training, personal time, etc. to the appropriate Admios category.

  • Make sure you respect the communication policies using any required IM client from the client

    • More commons are Skype and Slack

Development/QA

  • Ask for any coding standards docs

  • Always follow the coding standards that exist in the code already. If you think there’s a better way, suggest it before you code it.

  • Ask for any existence (project structure/features) documentation to start understanding the main functionalities of the application.

    • Make sure to setup the environment correctly

    • If there is no documentation of the project itself or any feature you are signed in to work on or continuing working on then a good approach is to read the existing software tests developed of the application, this could provide you a good perception of the main goals of the existing code.

  • If there is the possibility to do some pair-programing with an existing developer in the account and work on task together could be very valuable for a quick and successful ramp up.

  • Get sign off on your engineering plan BEFORE you start coding.

  • Make sure you understand how your story will be judged

  • Make sure you understand how long your story is expected to take. Update the client daily.

  • TEST TEST TEST - It is your sole responsibility to develop defect free code. This is not QA or the PM’s responsibility. It is your responsibility to make sure that your features get to production defect free. Reread this sentence. It is your responsibility to make sure they get all the way to production - not GIT, not staging but production. Own your work.

  • Use source control intelligently, if you have a problem, ask someone else before submitting your changes. Is important to NEVER SUBMIT BROKEN CODE, not even if you’ll fix it right away. If you need to save intermediate changes, make a separate branch.

  • Make sure someone reviews your code prior to your first PR (this could be a teammate on the account, another senior member of the team at Admios or a partner like Georges)

  • Ask for feedback on your first PR. Document and share any feedback so that NO ONE ON THE TEAM makes the same mistake ever again.

  • Even with all the be careful steps above, always be eager to learn and tech, this attitude is always welcome and positive in any team. Have fun!

Scenarios

This Table provides a valuable guidance through the most common scenarios a developer could face at on his first 30 days in an account.

Symptom Problem Solution
You haven’t spoken with the client in over 24 hours. This may happen later in the account but it’s a bad sign in the first 30 days. You could be drifting out of sync with the client. Reach out and set up a daily meeting and make sure it happens
You got no feedback on your first PR. You have no idea how well/poorly you are doing. Ask for feedback.
You (or one of the devs if you’re a manager) sent your EOD email at a time different from the end of the day (next morning, earlier, later, etc). It doesn’t appear that you are working. Talk to the dev and make sure it happens even if you have to watch them write it
You got incomplete requirements. You have no idea what to build and test. Develop a concise list of questions and reach out until you get answers
Communication from the client is more complex than expected. Not enough technical skills. Inform this, as soon as possible, to the Director of training at Admios to get the appropriate training material.