Project dev lead guidelines
The goal of this document is to make a dev lead's life easier on a project. We would like for each dev lead to have a guidelines in a form of a checklist that can (s)he refer to. The checklist would contain item like for example: "have animations defined before development of that screen starts", "test the app on the older devices", "hold UI review at the end of the sprint", etc...
Dev lead should be included in design sprint at the start of the project in order to give insightful information to the client and the rest of the team while ideas are still being created. Already in that early phase he can make an influence on promoting or discarding some idea if, for example, he knows that something is easy, not so easy, or impossible to do. Moreover, he can contribute not just as a developer, but as platform poweruser, all of mobile developers naturally use a lot of apps and have a perspective on good or bad app behaviours.
Before the beginning of the implementation phase, dev lead should sit down with the PM and review the functional specification. First of all he should be familiar with the whole feature set and he will get familiar with it by studying the functional specification. If something isn't specified he should press the PM to specify it. While reviewing the functional specification he should think about the edge cases of a particular feature, the architecture, potential pitfalls, etc
After reviewing the functional specification project dev lead should write an onboarding document for that project. The purpose of the onboarding document is to be a single source of truth for important informations about the project, that a new developer on a project can use to familiarize himself with a project. And it is also useful for "old" devs too :) It should contain the stuff as e.g. test user names, urls to important resources, libraries that we use, project specific tips and tricks, architecture overview, etc. Good thing to know is that it doesn't have to be a google doc, on the contrary, it would be better if it were a wiki page, or perhaps a README file on the project source control. The important thing is, once again, that it is single source of truth, and that everybody knows where is it located. Lead dev is responsible to maintain that document during the development if there are some changes to be made. More on the project onboarding document: Project onboarding
Lead developer should cooperate with the PM in creating the tasks in Jira during the implementation phase. PM should create tasks and epics, but lead developer should add a sentence or two in every task with the directions on how to implement that task. Not a pseudocode, but a quick tip on how to keep it aligned with a bigger picture, with the rest of the app. Also if there is something specific to that task, he should mention it. For example if developer should use a particular non standard component for that task, etc. He should also think about the stuff that nobody thinks about and that is always forgotten and being forced into the app at the end of the project or a phase. For example negative cases such as offline screens, rejected permissions by user, etc. Think about it while creating the task for particular screen. Analytics - try to include it while creating the screen, not at the end of the project. When I say screen in this context, I mean UI, presenter, all the business logic related to the screen, etc... Yes, it's a UX's job, but if he has forgotten it, cooperate with him and resolve that stuff in this moment.
During the implementation phase dev lead is responsible for the team members' communication with the PM and the other teams. For example if there is something tricky that is already implemented in the iOS app, dev lead should have that information and at least connect the Android developer that works on that feature with the corresponding iOS developer.
Dev lead should know who in the team has what preferences, and communicate that to the PM while tasks are being dispatched. He should also try to ensure that context switching is held on minimum. Nobody likes to be constantly shuffled between tasks, not to mention different projects.
During the implementation phase dev lead should assert that the development pre-requirements are satisfied. For example that animations are defined, etc. More on the development prerequisites: Development prerequisites
Dev lead should route all the technical correspondence between the client and the team. At least at the beginning of the project, later on as some members of the team become more specialized in some areas and the whole team becomes familiar with the client team members and who is who at the client side, then it becomes more efficient for individual team members to communicate directly with the client team members.
Dev lead should review all the code in the project he is leading, pull requests don't get merged unless dev lead has approved it.
Project can be managed in a multiple ways, depending on the client and circumstances. We can do sprints, or we can have infinite backlog, we can have dedicated milestones, or we can launch version ad-hoc. No matter what style is being currently used by the PM, dev lead should be adapter for that style (and PM) on the one side, and team on the other side. He should ensure that team is delivering quality stuff consistently. He should enforce that UI review is being done now and then, no matter what the milestones are. He should ensure the app is tested on older devices now and then and catch optimization issues early before it runs out of hands. He should ensure that every feature is functionally done before it goes to the QA, not necessarily tested on every device, but that it works at least on the device(s) we are developing on. QA can catch edge cases and bugs on some esoteric devices, we don't have time to run it on every device, but it should at least work on our development device(s)
There are couple of tools that dev lead can use to ensure everything is going smoothly. He doesn't have to use them if thing are going OK, but he can refer to that tools if it's necessary
#Shadowing - Things don't always go smoothly, and it happens that there are sometimes additional devs needed on the project. Maybe someone is on a vacation, but we agreed with the client that the tempo will be the same, maybe we are being late, whatever. Dev lead should ensure that there is one additional team member shadowing the project. He can actively be on the other project, but he can look PRs on dev lead's project in a more detailed fashion, participate in sync now and then, etc. It's more convenient for that developer to kick in the project in desperate times than someone random.
Cross AC assertion - if it happens that we are constantly delivering unfinished features to the QA, dev lead can make an UDBA style table (or make up a rule) that says who controls whom. If dev A is responsible for dev B then after dev B makes a pull request for some feature, dev A should pull that feature branch and run through all acceptance criteria (AC) listed in Jira task for that feature. Only after dev A has approved PR (together with dev lead) it can be merged.
Opened issues table - If it happens that there is constant lag in the communication with the client, emails are being forgotten, there are open issues waiting weeks for an answer, dev lead can think about temporarily using an open issues list. It can have couple of columns, who is being blocked by an issue, who owes the answer, status (opened, email sent, client reminded, closed, etc...) and how long has been that this issue has been addressed. Team can run through that list on every sync and discuss why are we stuck on particular issue. The point is that the team should be aware that there is a problem. For example client needs to make a Google Play account for us in order to publish the app. Somebody sent an email with that request, client didn't respond and original dev that sent the mail moved on. Now when time comes to publish the app we might be in problems, maybe the guy on the client side that needs to do it is on the vacation and lot of money has been put into the marketing the release on that particular date. All of this could have been prevented by sending a simple reminder mail couple of days after the original. It's a simple example, but it can happen that there are 10, 15, 20 simple things like this that could smack you in the face in a wrong moment.
Boring, but necessary
Bookkeeping - dev lead is responsible for the bookkeeping on the project. That means that he should make sure that all the tasks that will soon enter implementation phase are estimated, and that all the tasks that have exited implementation phase are beeing time logged.
The process. Dev lead should make sure that everything is being done according to the process. That means that no dev is misbehaving in that matter, but also that PM isn’t doing something on his own, for example giving tasks under the hood, forcing unreasonable deadlines, etc. Dev lead should be the guardian of the process. It sounds nazi, but it's a way to "lawyer" ourselves when problems arise. People make mistakes, that's a given, and there is no running away from this. The idea is to tweak the process in order to keep that mistakes at the minimum. So, if we stick to the process, it's process's fault when the shit hits the fan. Finally, it's dev lead's duty, together with other dev leads, team leads, and PMs, to analyse the situations when process failed and to give constructive feedback and propose ideas on how to improve the process.