Tag: checklist

Posted on

Tool checklist for cloud development – set your team up for productivity

What tools are required for teams that are developing software for the cloud? Verify this checklist to find out if your team has the basics for productive software development in place.

Contents

Versioning system

You know that you
(1) have one, (2) it is set up correctly and (3) and your team is using it
… if you can answer the following questions with YES (in case you’re not sure if you need a versioning system read here)

  • Each team member is able to revert source code to a former version at any time.
  • You are 100% sure that this works because you have tried and tested it
  • You are able to quickly find out what has changed between versions
  • You are treating configuration files, documentation and any other artifacts like your source code – everything is under version control
  • Team members check in modified source code at a regular basis
  • Your team has agreed on a common branching strategy
  • If your versioning system would fail completely today there would be no panic. You would just set it up again from scratch and reload yesterdays backup. You know that this would work because you have tested it at least once.
  • If yesterdays backup was not created there is a notification in your team mailbox

Issue tracking

You know that you
(1) have one, (2) it is set up correctly and (3) and your team is using it
… if you can answer the following questions with YES (in case you’re not sure if you need an issue tracking system read here)

  • The team has a complete list of all currently known bugs and issues
  • The list is accessible to each team member and everybody is be able to work on issues (e.g. add comments)
  • Each team member can see “his/her” issues with one single click, and ideally get automatically notified about status changes for “his/her” issues
  • The team has a clear policy on issue status management: what issue status values exist and who is allowed to change issue states? An example: many teams follow the principle that an issue should be verified and closed by the person who initially opened it. Your team may want to handle that differently – just ensure that everybody agrees on the same standard.
  • Each issue in the list has at least:
    • a clear title and a description that each team member can understand without need to ask whoever has written the issue
    • a status and an owner within the team
    • additional information required to tackle the issue (screenshots, steps to reproduce, logs etc.) and meta information that helps to manage the issue and understand its history (time created, component or service concerned, version, …)
  • Daily backups are created and stored on a separate system. The backup / restore procedure has been tested at least once. This is not required if you use the cloud service of some provider (see article)

Build and Deployment System

You know that you
(1) have one, (2) it is set up correctly and (3) and your team is using it
… if you can answer the following questions with YES (in case you’re not sure if you need a build / deployment system read here)

  • Each developer can create a new build with a single command or click
  • Build status is visualized and team members get notified about build problems
  • New builds can be deployed to the desired environment with a single command or click (at least for the productive environment most teams will set up rules regarding who and when this is is allowed)
  • You can always tell which version is installed on what environment
  • You have a track record of builds and deployments

Team Collaboration and Knowledge Base

You know that you have what you need if you can answer the following questions with YES (in case you’re not sure if you need tooling for team collaboration read here)

  • Each team member can access a common system and find the most relevant 5 documents via direct short link
  • Each team member can add or modify content 
  • Each team member can search for information or documents via keywords

Check out these related articles:

 

Posted on

The new developer Onboarding Checklist

Ensure a smooth and efficient start of your new team member so he/she feels comfortable and can contribute to your teams’ results as early as possible. 

4 weeks before day one

Plan for a place within your office and verify that the basics are there (desk, chair, power supply, network…)
Order required equipment:
– notebook + docking station
– keyboard & mouse
– LCD monitor
Depending on your company: order ID card(s) and organize whatever entries in your company systems may be required (company ID and directory, email, etc.)
Block time in your calendar for day one. You should have enough time to look after things, introduce the new team member and go through the onboarding plan together.
Block another hour 3 days after day one.

1 week before day one

Make sure ID card and equipment has arrived and is complete.
Depending on your company: have notebook set up with your standard enterprise applications
Prepare the onboarding plan – what will your new team member need to know about your company (you can find a template here: [*]). Make sure to review that plan with the team.
Sit with the team and plan the initial assignments during the first 2..3 weeks. Make sure to leave enough room for startup and learning.

DAY ONE

Take some time to chat and introduce the new one to the team
Explain your companies’ basics – where is the coffee machine, what are the usual office hours (if any), how to you handle work from home, overtime, holidays, business travel etc.
Explain your work context – what is your groups position within the company, who are your customers, what are your interfaces. You have covered some of that during your hiring interview (see [*]) already.
Give a broad overview of the new ones’ role. Maybe leave the details for later. Go through the onboarding plan together. Hand over that plan – your new team member will own it from now on.
Note that onboarding is not done after day one – It is a process that takes much longer

3 days after day one

Now that the dust has settled take some time to discuss what has been happening so far. Answer questions. Are there any issues to solve? How does the new position feel like? Talk about the role and why it is important. What the major success factors? Why does your group exist? What is the new one’s contribution to that?
Fix a date for the next follow-up meeting 3…4 weeks later

3…4 weeks after day one

Collect feedback. What is good? Any help needed? How’s the team? How’s the work context in your place compared to the new one’s past experience? This is also a learning opportunity for yourself.
While you sit together write down 2…4 high level goals and/or desired outcomes. Focus on goals and outcomes, not on tasks. E.g. “ensure that the developed services are highly available” is something concrete and tangible, it could even be measured. You’re not doing this to control and measure but to ensure a good mutual understanding, and to get priorities clear.
Explain your approach for ongoing communication and follow-up on this exercise. Fix a meeting for 3…6 months in the future where you will review results, give credits for achievements, talk about experiences and expections, improvement potentials or whatever needs to be adressed outside of the day-to-day work context. You can find a template in the download section.

Check out these related articles: