ATT Handbook

Owned by Peter Green
Last updated: Jul 25, 2024 by Paul Diskin

The Alma Tech Team (ATT) supports Alma, working with functional areas throughout the Library to streamline workflows in order to more efficiently acquire, catalog, publish, and circulate materials.

This page is to help with onboarding, as well as to provide a high-level overview of how we work as a team. 

ZenHub Board

Requires GitHub login and membership in Princeton University Library GitHub organization (request from ATT or other members):

Routines

Recurring tasks, not represented on the ZenHub board

  • Recurring meetings with functional areas: Acquisitions, Cataloging, Circulation, E-Resources, Finance, IT, Inventory Management, Resource Sharing
  • Fiscal Period Close tasks
  • Running import profiles
  • Reports: ad hoc, for Inventory Management and Cataloging
  • Clearing out SCSB exceptions
  • Adding, editing, and auditing Alma user roles
  • Reviewing Alma releases and sharing new features with functional groups
  • Running EDI files

Review

  • At least one other pair of eyes, those of a team member who did not do the original work, to review resolved issues (e.g., new import profiles, norm/indication/merge rules, changes of configurations, etc.)
  • The higher the priority and greater the impact, the more important the review

Scrum Implementation

In Dec 2023, all members of the ATT earned Scrum Master certification and began implementing the agile Scrum framework, which comprises 3 team roles, 3 artifacts (“social objects”) and 5 events, all directed toward our Product Goal.

ATT Product Goal

The team's work supports the library's ability to be strategically and operationally agile by helping to develop metrics to measure the library's work. As Alma is the main system that facilitates the library's essential operations, this team is central to the library's ability to meet patrons where they are and democratize access to knowledge. The Alma Tech Team's main goals are to:

  1. Ensure the Alma system is working properly;
  2. Provide accurate data from Alma;
  3. Serve as subject matter experts (SMEs) for workflow creation and refinement that involves Alma;
  4. Maintain batch processes that integrate with other systems; and lead projects centered on bulk data processing and analysis.

Team roles

  1. Product Owner: Mark Zelesky
  2. Scrum Master: Paul Diskin and Peter Green (alternating) 
  3. Developers (“team”):Paul Diskin, Peter Green, Cathy Weng, Mark Zelesky, Tom Ventimiglia (ad hoc guest) 

Artifacts

  1. Product Backlog: a “Product Backlog” ZenHub column, ordered by the product owner following the team's Prioritization Matrix
    • Committed to the Product Goal, which is a future state of the product which serves as a target for us to plan against.
  2. Sprint Backlog: a “Sprint Backlog” ZenHub column, representing tickets currently in progress (including tickets currently in review).
  3. Increment: ZenHub tickets. Each is a concrete step towards our Product Goal and is additive to (builds upon) all prior increments. 
    • Committed to a “Definition of Done”: each ticket is closed after meeting acceptance criteria defined by the product owner before it is considered “Ready”. Built-in ZenHub burndown and velocity reports are used to track velocity and refine estimates.

Events of the Sprint

  1. Sprint Planning: sprints run for 5 work days: Wed - Tues (originally Mon - Fri); planning takes place on the first day of the sprint and timeboxed for 1 hour. The product owner, in collaboration with the team manager, determines which tickets are ready to work on and their priority. 
  2. Daily Scrum: each afternoon,  timeboxed for 15 minutes
  3. Backlog refinement: takes place during the mid-sprint Scrum (a.k.a. “reality check”): do we need to move any tickets out of or into the sprint?
  4. Sprint Review: last day of the sprint, timeboxed for 45 minutes. In lieu of sharing with stakeholders during review, we create a summary of highlights to share: at bi-weekly Acquisitions and Resource Management check-ins, CaMS updates, and potentially other channels of communication as opportunities arise. 
  5. Sprint Retrospective: follows the Sprint Review (and a break), timeboxed for 45 minutes; includes deciding on a kaizen (small improvement for the next sprint)

Each event is attended by the full team, whenever possible. Running notes for the review and retrospective are kept in Google Docs to document discussions and highlights.

Quarterly Maintenance Sprints ("Sprint-free Weeks")

Every three months (Feb, May, Aug, Nov) one week is set aside for explorations, housecleaning, collaborations, roadmap refinement, etc. There is no daily stand-up but there is a review and retrospective at the end of the week.   

Annual Fiscal Period Close (FPC) Sprint

Each year, FPC demands our full attention, particularly during the rollover process (end of June). During this annual sprint, we maintain the structure of Scrum but allow for flexibility in meeting times and durations.  

Tools

  • Alma
    • Drools: norm rules, merge rules
    • Analytics
    • Data Visualization
  • Google Drive (docs, sheets, etc.)
  • GitHub repos
    • alma-config - general configuration and tasks
    • alma-ncip - ILLiad add-on
    • alma-notices - letters
    • lsp-data - reports
    • spine-o-matic - spine label prefixes
  • Microsoft Office suite
  • MarcEdit
  • Ruby / iRB
  • SN@P (Service Now at Princeton)*
  • ZenHub (to manage tickets in GitHub repos)

*For tickets taking more than ~30 min we are creating a ZenHub ticket, including just the link to the SN@P ticket, with all comments remaining in SN@P.

New Mac Setup