IDPM is an agile project management process designed to support up to a dozen developers creating software up to approximately 500K LOC with “web app” grade quality. Other project management approaches will be better for larger teams, larger code bases, or more stringent (i.e. life-critical) quality requirements.
Here are a set of guidelines which implement IDPM.
For IDPM to work effectively, your team should meet together approximately twice a week to review progress and update the upcoming set of tasks to complete. While online meetings can work, face-to-face is generally quicker and results in better coordination.
For multiple people to work together effectively, you must figure out a way to decompose the work into small tasks that can be worked on independently. As a guideline, each task should take approximately three days to accomplish. If a task appears to take longer than that, then decompose it into subtasks. If a task takes only a few minutes to accomplish, then just do it and don’t bother to document it.
You do not have to figure out all the tasks before starting work. At any time, you only need to have the next 3-4 days of tasks precisely specified, since you will meet again within 3 days to revise the task list.
Specify each task as a GitHub issue, and once it’s in the In Progress column, make exactly one team member the owner of that task. While multiple people might occasionally participate in completing a task, you should always specify a single person as having ultimate responsibility for completing it.
To minimize coordination conflicts, create a branch for each task (i.e. GitHub issue). Use the issue number to name the branch to make the association explicit.
For example, if a task is “Put system under CI”, and it’s issue #15, then the branch in which this is accomplished should be named “issue-15”.
Merge the branch back into master when the task is accomplished. If, after merging, you realize the task isn’t yet finished, just continue work in that branch and merge again.
Just to be clear, all branches except the main branch should be named “issue-XX”, where XX is the issue number.
Do not append the issue title (i.e. “issue-23-create-landing-page”). This is because you may decide later to rename and improve the issue title, and if you just name the branch “issue-23”, then you don’t have to rename it.
In rare cases, you may need to create a branch off of an issue branch (as opposed to off the main branch). For example, you want to ask a smart question and need to create a “checkpoint” of the state of the branch to document the problem. In this case, it is acceptable to name the sub-branch with the issue branch plus a suffix (for example, “issue-23-a” ).
Every 7-10 days, your team should “deliver” something concrete regarding the project. To support this, we have organized development into a sequence of Milestones occurring every 7-14 days.
Each Milestone is managed using a GitHub Project Board. So you’ll end up creating one GitHub Project Board for Milestone 1, another one for Milestone 2, and a third for Milestone 3. Don’t create them all in advance. It’s easier if you only create a new Project Board once you enter the associated Milestone period.
You do not use the GitHub “Milestone” representation for IDPM. GitHub Milestones are redundant given we are using Project Boards.
To ensure that everyone always has something to do, make sure that the To Do column has at least as many issues as there are team members. That guarantees that each team member can immediately assign themselves an additional task once they finish their current one without having to consult the team.
Issues in the To Do column do not need to be assigned to a team member, but you can if that makes sense for your project.
For each Milestone, create a GitHub Project Board specifying the “Automated Kanban” template. This will result in a Board with three columns: To Do, In Progress, Done.
At the start of the Milestone, add every issue to the To Do column. Assign issues to team members during the meeting. There should be at least two tasks per team member, each task ideally taking 2-3 days to accomplish.
As team members take on a task, they should:
When team members complete a task, they should:
The GitHub Project Board “Automated Kanban” template can simplify project board management in two ways:
More details on project board automation can be found at https://help.github.com/en/articles/configuring-automation-for-project-boards.
When you reach the due date for a Milestone, you have to “transition” to the next Milestone. This means:
Understanding who is assigned an issue is significantly easier when every team member has a Github profile photo. Otherwise, a randomly generated avatar is associated with the issue owner in the project board. For this class, please go to your profile page in GitHub and provide a headshot for your profile photo.