Taking Over a Project

So I’m taking over a new project as a technical team lead. This team has been working for some time (for a long time). Now my task is to lead its further development. I’m excited and worried at the same time.

I spent some time wondering about what should I know about this new project and about the team. Here is the list of topics that I think I should gather some information about. Maybe someone else will find them useful. I also hope for someone giving me hints about things that I forgot.

I did not mention some obvious stuff like “what the project is all about”. The list is chaotic, but so am I. 🙂

Team

• who? + characteristics + how long they work with the team + strong/weak points + maturity level / how independent they are? + maybe there is some BSC mechanism, if so, take a look at the previous records
• language skills
• contact – mail, skype/jabber nick etc.
• working hours? anyone working half-time? anyone with unusual working hours?
• where? one room or many places
• some people from other teams involved? independent consultants? some project partners (external companies) that we cooperate with?
• what are the roles of people
• who knows what?
• are team members involved in other projects?
• questions to ask to each team member:
  • what are you proud/angry/annoyed about? what (de)motivates you?
  • please draw the architecture of the system
  • please write down the “definition of done”
  • what issues do you think we have? what is the most common source of bugs? which bugs are the most annoying for us / for clients?

Meetings / Telcos

• internal (only the team is involved) – Scrum – daily / sprint / backlog ?
• with clients
• with higher-ups?
• traveling? where? for how long?
• how are the invitations send? who sends them? who sets the agenda? who sends minutes (if any)? who attends?
• how long is the meeting? who participates?

Documents

• where can I find them, how are they generated, who maintains them?
• technical documentation
• user documentation
• developers documentation
• reporting – internal / external
• templates – documents? mails? reports? presentations?
• bug tracker – how are issues commented?
• where is the database schema?

Infrastructure

• SCM, FTP/WebDavs, Sonar, CI, bug tracker, artifacts repository, wiki
• keystores, certificates
• mailing lists (internal, external)
• adresses, credentials, who creates accounts? who administrates?
• environments – local, testing, production?
• Can anyone, besides the team, access any of these (e.g. client reading bug tracker issues) ?

Processes

• SCRUM? how does it really look like? how are user stories sized – hours or t-shirts (M, S, XL)? what meetings, how often etc., are daily standups held regularly
• code reviews – formalized, informal, who does them? peer reviews? external audits of code?
• any visualization tools? (well, these are the easiest to notice, aren’t they?)
• what is the “definition of done” of this team?
• any special recruiting process for this team?
• build process – automated?
• How are versions/releases created? What is a naming pattern? Are there different internal (for team) and external (for client) versions? How can one learn about the changes between versions X and Y?
• statuses of issues on issue tracker (e.g. todo, in progree, done, accepted etc.)
• production deploy & rollback, tools used – Puppet, Liquidbase?
• code conventions – format (Eclipse formatter?), checkstyle etc, but also use of TODO/FIXME tags in code
• SCM (SVN/git) – branches? how/when created, when merged?
• CI – schedules, how are they set?

Testing

• unit
• integration
• end2end
• does client test?
• automation? which requirements functional and non functional are being automatically tested?
• code coverage – how high, is it automatically calculated, is code coverage of different tests merged?

Development Tools

• what tools/software is being used by team members
• OS? IDE? build tools? testing libraries? mocking libraries? code review tools?
• specific applications for Win (Visio?, Outlook?)

Problems

• what we know? what are the main problems from our point of view? (e.g. internal code quality, our build process, client?), does client is aware of this?
• recent problems, what were the causes, are they fixed?
• what is the main concern of client?
• common bugs, how many critical bugs, are they added to the current sprint?

Client(s)

• communication – how do we communicate with clients? with whom exactly should I talk about certain topics? who has the right to make decisions?
• communication – how does client communicates with us?
• communication – what hours is he available? does he answer emails immediately?
• what does he value, what are his goals?
• does he own the code?
• does he has a say in technologies we used, should we ask him for approval for new libraries/tools that we plan to use?
• is it possible to negotiate the scope?

Next steps

• What is the most pressing matter? Are we late with anything?
• Any meetings/telcos ahead?

Architecture

• software
• hardware

Questions, questions, questions… Surely there are many more things to ask and topics to understand when you join a project. I will try to use the above list for the task at hand. Will see if it turns out to be any good.