A Check List for Knowledge Transfer
First, I try to handle the following set data and access rights.
- Members of the team
- Hierarchy and responsibilities, reporting
- The customer's / related teams' / vendor's contacts
Business requirements, trying to get access to:
- Description of business requirements
- User documentation
- Test cases
- Repository URLs
- Creating accounts with the required rights
- Getting all configuration scripts and requirements for developers' workstations
- If possible, creating automated scripts of environment deployment or creating system images – to save precious time for the developers.
- System architecture
- Sub-system architecture
- Architecture in terms of technical primitives
- Architecture in terms of business tasks, use cases
- Team's technical debts
- All technical findings and proposals regarding the existing system
- It is possible to carry out an experiment: ask the new team to create a "pattern" of the system with the purpose of identifying infrastructure components that ensure the system's operability, and superimpose business requirements on that – judging by my experience, people catch on the project much quicker.
Delivery and environment system:
- CI/CD servers
- Test infrastructure
- Build versions
Information systems (very important):
- User requests handling system
- Bus tracking system
- Knowledge base system / information portal
- Monitoring system
- User actions analytics system
- It is crucial to identify contact persons for all issues regarding each system
- Also all procedures and ceremonials: flow processing of user requests; flow approvals of new technical documentation
Processes and a list of decision makers (DM):
- Procedures and a list of DMs connected with daily routines
- Procedures and a list of DMs connected with closing a sprint / iteration / work stage
- Procedures and a list of DMs connected with planning a new release / iteration
- Procedures connected with handling Change Requests, and a list of DMs
- Procedures and ceremonials connected with issuing a new release
Testing, quality assurance team:
- Necessary to get access to all test script databases
- Necessary to get the description of release issue procedures
User accounts – I bring them out, to keep in mind:
- Testing / staging / production user accounts for testing the product
- Accounts in the analytics / vendors / partners systems
Field of action:
- Work plan
- Objectives definition in technical terms
- Objectives definition in terms of product
Third party services, vendors, partners:
- Access to all third party systems with admin rights – to be able to add your own users
- Contacts of all vendors and partners, their DMs, interaction schedule, their team structure, responsibilities, and a brief description of the interaction domain and the team's objectives
The "Objectives" Section is very important:
- What is required from the development, testing, and support teams?
- What are the objectives of the new team?
Of course, the modern development frameworks can greatly help in project implementation, and in general all ceremonials and team roles are known, but the real world is not perfect, and therefore it's better to get through the team's activities from start to finish.
It should be noted that the best way to carry out a knowledge transfer would be to keep two teams in parallel, in which case the entire team would be able to gradually flow into the development process, talk with knowledge holders about the issues of system configuration, process systems (for example JIRA), bug life cycle, etc.
If the team works according to Scrum or Scrumban, I would recommend to conduct one or two sprints, observing all the ceremonials: planning, groomings, triage, retrospectives, demos.
Interested in improving your skills? Check out our Agile trainings.