Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Version History

« Previous Version 24 Next »

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 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”): Beck Davis, 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: A concrete step towards the Product Goal.  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.


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


  • No labels