Basic project processes¶

These have been replicated and aggregated from our other project control documentation.

Processes for the team¶

• Sprints: Development will typically be in sprints of one week or two weeks each, aligned with calendar weeks (i.e. Mon-Fri)
• Sprint kick-off meeting: Each sprint will start with a kick-off meeting which will:
  • review the deliverables of the last sprint
  • discuss any problems faced and lessons learned for future sprints
  • freeze the list of deliverables for that sprint (and update the Sprints page)
  • tag the tasks for the next sprint in Redmine (mark their Target Version with the sprint name)
• Stand-up meeting: There will be a stand-up meeting at a fixed time in the first half each day, where three questions will be answered by each dev team member (1-2 mins per head), for the benefit of the project manager and the entire team
  • what work was finished yesterday
  • what work is expected to be finished by EOD today
  • what problems are anticipated which will block progress today.
  • If any obstacle is highlighted, the PM will discuss this issue offline with the team member after the stand-up meeting.
• Shared responsibility: The team as a whole will be responsible for the sprint deliverables. Tasks will be assigned to individuals, but tasks may be re-assigned by team members to each other (with mutual consent), provided the sprint deliverables are met at the end of the sprint. Credit or censure will be assigned to the full team, never to individual members.
• No broken build: The software built by the entire team must build correctly at the end of each sprint. A "build" means that
  • compilation, linking, and creation of EXE or other executable modules, must succeed.
  • the programs must run and superficial tests of basic operation ("smoke tests") must succeed
  • Bugs are acceptable at the end of the sprint, but a broken build is not acceptable. A sprint cannot be ended till a broken build is fixed.
• Sprint overshoot: Overshoot of a sprint's deliverables or presence of a broken build will mean that the team will work through the weekend till the sprint is closed. It is not permitted to carry over incomplete portions of a previous sprint into the next sprint unless the entire team has worked through the weekend and holidays to try to finish it first. During sprint overshoot, the entire team must work through the weekend, irrespective of whether the delay is due to just one member's work.
• Short sprint: If a sprint finishes earlier than its end-date, the PM has the option to let his entire team take a break (e.g. Friday second half), or he may, with the consent of the team, add tasks from future sprints to this sprint and stretch the sprint scope. Even after stretching the scope, the sprint must finish and complete all deliverables, including the stretched ones, at the end-date of the sprint.

Basic point: the dev process and sprint deliverables are owned by the team as a whole. There is no individual responsibility outside this shared goal.

Processes for dev team members¶

• Meetings: Each member will participate in daily stand-up meetings and all sprint-kickoff meetings.
• Task initiation: Each dev team member will pick up a task and
  • change its status from "New" to "In progress",
  • mark the Assignee to himself/herself, and then start working on the task. If a team member clocks time on a task or posts an update to a task whose status is "New", then this is violation of process.
• No concurrency: Each dev team member will have a max of two tasks assigned to himself/herself and with status of "In progress". No task must be picked up when a previous task is half-finished. The member must finish a task, change its status to "Testing", and then pick up the next task.
• Daily update: Every day, each member must post at least one update to at least one task, at EOD. More updates are welcome. If a member has worked on a task assigned to someone else, to help him debug something or to discuss a problem, then he may post an update to that other person's task too.
• Daily source commit: Every day, each member must commit at least one check-in to the source repository, at EOD. More commits are welcome.
• Tagged commit: Each commit must carry a tag in the commit comment giving the Redmine issue number of the task for which this code is being changed and committed. The syntax for this tag is a '#' symbol followed by the issue number (without any spaces or gaps). Example: #10036. Untagged commits are a violation of process.
• Time clocking: Each day, each team member must clock the number of hours spent on each task he or she worked on. If he spent some time helping another team member with some other task, he must clock time on that task too. All time clocking for a day must be posted by EOD the same day.
• Task closing: After finishing and testing a task, the member must mark the status of the task as "tested" and change the Assignee to the PM. They will be marked "closed" by the PM at the end of the sprint after review.

Code review¶

• Daily review: The last 45-60 mins of each working day must be set aside for peer-to-peer code review.
• Check source diffs: 1-2 members must sit and review the work of one other member, by looking through the last 1-2 diffs of source code commits. The diff feature of Redmine's repository module must be used.
• Update with observations: Review comments must be posted as an update to the task whose code is being reviewed. Review observations must be fixed by the programmer (the assignee of the task) by the end of the sprint.
• Update from reviewer: The update must be posted by one of the reviewers, not by the developer to whom the dev task has been assigned.
• Rework if needed: If the status of the task whose code is being reviewed has been set to "Tested" already, then the reviewer must change the status to "Rework" and post the update. After the observations have been fixed in the code and the changes committed to the source repository, the assignee may set the status once again to "Tested".

Each dev team member must be a part of this code review every day, either as reviewer or programmer.

Processes for the PM¶

At start of project¶

• Container for all tasks: He must define a new Target Version called "NextSprint" in Redmine.
• Task defining: He must create all tasks as issues in Redmine, as per project WBS, set their tracker to "Task" and set their "Target Version" tag to "NextSprint". Later, when these tasks are moved to the current sprint or a new sprint, their Target Versions must be updated. A task should be about 2-3 person-days of work. Larger tasks must be broken up into smaller, independently verifiable chunks if needed.

At start of each sprint¶

• New TV: He must create a new Target Version named after the sprint date. For instance, if the next sprint will be from 10 to 16 April, then the Target Version name must be "sprint 10Apr-16Apr"
• Sprint review meeting: He must conduct the sprint review meeting:
  • discuss sprint overshoots and their reasons. He must invite team members to suggest reasons, and methods to prevent it in future.
  • discuss quality issues and their reasons. He must invite team members to give their analyses and prevention suggestions.
  • highlight difficult problems solved or good work done (there are 1-2 in each sprint), congratulating the team for it.
  • freeze next sprint's scope, with the buy-in of the full team
  • write brief notes about the review meeting minutes in the Sprints page, giving a date
  • update the Target Version of all tasks for the next sprint from "NextSprint" to the new version, e.g. "sprint 10Apr-16APr".
• Customer update: He must present the sprint deliverables to the customer, inform him of progress, and note any observations or change requests. If there are change requests based on visible output of the closing sprint, those must be logged in Redmine as fresh issues with
  • tracker set to "CR" and
  • Target Version set to "NextSprint".
• Roadmap: Click on the Redmine "Roadmap" tab and stare at the report. Notice changes to the numbers and percentage completion figures for each sprint.

Budget half a day for each sprint kick-off cycle. The second half of the day must be made available for the dev team to start work on the sprint.

Every day¶

• Stand-up meeting: He must conduct the stand-up meeting every day. He must update the findings of the meeting in one bullet-point per team member, in the Stand-up meetings page, marking the date. Each standup meeting should not take more than about 1 min per team member, plus 5 mins of overhead.
• Review Redmine: Once a day, he must check the following on Redmine, for each team member:
  • she must have posted at least one update in the last 24 hours
  • she must have done at least one source code commit in the last 24 hours
  • each commit in the source repository must be tagged with a Redmine issue number
  • she must have logged hours worked against some issue or other in the last 24 hours

If any team member slips up on any of this, she must be reminded, and the follow-up vigilance on compliance must be stepped up. The project becomes unmanageable without these small checks, and therefore non-compliance leads to loss of manageability.

Ongoing¶

• Check notifications: Keep email notifications switched on in Redmine for the GBA project, and read the email notification which comes from each update from Redmine. Keep track of whether any team member is posting a question or highlighting a roadblock. Step in if needed.
• Roadmap: Click on the "Roadmap" tab on Redmine and stare at the report.

Sometimes, developers are accustomed to posting a question in Redmine in an issue update, asking the PM for assistance or a decision. Such questions can only be read if the PM has notifications switched on and skims through each update notification.