Readers/Web/Team/Development cycle

The Reading Web Team develops software in two-week long sprints, or iterations. During the course of a development iteration, planning occurs for upcoming iterations.

Rationale

The team works in such a fashion in order to:

• Keep the cost of change low (in all facets of the project - requirements, personnel, practices, etc)
• Minimize risk by iteratively prioritizing requirements, closely examining/reevaluating the evolution of the product with the product owner and key stakeholders
• Rapidly make adaptive changes as the product evolves
• Increase productivity/limit context switching by focusing on a limited scope of small, manageable, discrete chunks of work
• Measure and evaluate team capacity to aid in realistic estimation and create realistic expectations
• Maintain a sustainable pace by limiting scope to the team's capacity

Our Phabricator Phrocess

Kanbanana board

The Web team's current work is captured on the sprint board (affectionately known as the kanbanana board). The Sprint board is comprised of the following columns. The board is designed in Kanban fashion where tasks move from left to right as they are being worked on.

Tasks in all columns are prioritized via colors as well as their position in each column (tasks at the top of the column are higher priority than those near the bottom of the column). The product owner sets the priority on most tasks, and engineers should generally pick up tasks closer to the top of the column.

Quarterly goals

This column lists all the current goal for the quarter. Tasks in this column are usually marked with [GOAL] or [EPIC]. These tasks do not move through the board like regular tasks (they usually stay here until the end of the quarter, when they can be placed in ready for sign-off if completed). They serve as a high-level reminder of our current commitment, and current tasks are usually subtasks of these goals.

Needs analysis

Before a task is ready to be worked on, it is typically put in the "needs analysis" column to be scoped by an engineer. This process involves taking a preliminary look at the problem and documenting the most likely approach for the problem.

Upcoming

Once a task is analysed, it can be placed in the upcoming column. Tasks here are waiting for estimation. Once a task has been estimated, it's ready to be moved to the next column.

Ready for Development

Tasks in ready for development can be picked up by an engineer. Once someone claims a task, it can be moved to "doing". Tasks are prioritized with colors as well as the order in the column (i.e. tasks at the top of the column are the highest priority).

Blocked on others

If a task is analysed, estimated, but waiting for input or work from an external team, it can be placed in "blocked on others" until it is ready to be worked on. From here it can go back to "ready for development" or "doing".

Design review

When a task is in progress but requires some design guidance, it can be placed in this column, usually with a link to a demo showcasing the work in question, or a screenshot. At this point in the cycle, the patch may need refinements of visual/interactive elements, and the engineer should work collaboratively with the designer to resolve any design issues or questions.

Code review

Once a task has been worked on and a Gerrit patch has been submitted, the task should be placed in code-review. This allows other engineers to know what needs review and assign themselves to tasks they feel most capable of reviewing.

Needs more work

When a task has been code-reviewed but requires further modifications, it's placed in this column as a signal to the original developer that the patch needs updating. The original developer may then continue to push modifications to the patch and place the task back in code review when updates are ready. Whether or not the task should be placed in "doing" while the updates are being worked on, is and will remain, a perennial question for the web team.

QA

Once a patch has been merged, it should be placed in the QA column for the QA engineer. Before placing a task in the QA column, ensure that it has QA steps and Acceptance Criteria in the description, outlining what steps should be followed to test the patch (including any specific browsers, languages, environments etc. if necessary) and what the accepted outcome of those steps are. QA is usually done on the beta cluster unless specified otherwise.

QA in prod

Because life is hard and wikis are complicated, sometimes we need to double check the work when it's deployed in production. This lets us catch bugs related to gadgets, user scripts, and differing wiki configurations that are not available on the beta cluster.

Ready for Signoff

And finally, once a task passes QA it can be placed in "ready for sign-off" for one last look before it's resolved.

Regular Rituals

There are a series of regular meetings to facilitate iteration planning. They are strictly timeboxed and facilitated by the program manager. Regular planning meetings are open to all, but are mandatory for some. The regular meetings are intended to balance the need for planning activities against the need for head's-down focus time for everyone on the team, and ultimately minimize the amount of expensive context-switching everyone on the team is exposed to.

This table captures the particulars of all regular planning meetings. Specific days of meetings are subject to change for scheduling conflicts, holidays, etc. Attendees are invited via Google calendar, where the definitive date/time of meetings is maintained.

Day	meeting name	Purpose	Attendees
Monday	Super happy dev time	For engineers to discuss technical matters such as current challenges and future goals.	Tech lead Engineers Engineering manager
	Web Weekly planning	Setting out the agenda for the week ahead. Includes: Administrative stuff Board check Analytics sync Community update Tasks to update/assign	Product Manager Program Manager Tech lead Engineers Engineering manager QA Designers Data analysts CRS
Tuesday	Web board grooming	Updating and organizing the Phabricator workboard: Board check Triaging new work Estimating existing work Updating backlog	Product Manager Program Manager Tech lead Engineers Engineering manager QA Designers
Wednesday	Web midweek standup	Meeting to discuss work and any blockers. Board check Identify issues for deep-dives	Product Manager Program Manager Tech lead Engineers Engineering manager QA Designers
	Retrospective (biweekly)	Biweekly team retro. The retro is a place to pause in the dev cycle to reflect on the previous sprint and how to make the next sprint better. It is a forum for the team to talk about what is working, what is not, and what is confusing. It is an opportunity to reinforce team unity and celebrate. :)	Product Manager Program Manager Tech lead Engineers Engineering manager QA Designers
Thursday	Web task sync	Meeting to follow up on plans from Monday and have more in-depth discussion as needed. Board check Talk about tasks Prioritize/estimate as needed	Product Manager Program Manager Tech lead Engineers Engineering manager QA Designers
	Team time (biweekly)	Biweekly meeting for additional planning and/or social time.	Product Manager Program Manager Tech lead Engineers Engineering manager QA Designers CRS
Friday	No meeting day!	Reserved for 1:1s or focus time.