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

question-marks_0
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.

Leave a Reply

Your email address will not be published. Required fields are marked *