Guides @ UF: Library Technology Services: Agile@LTS

About Agile in LTS

LTS operates following principles of minimal computing and appropriate technology, and agile is a natural part of this as a light-weight framework focused on delivering software that works. We use the lightest and fastest methods sufficient for success, utilizing more as needed (e.g., to address confusion, complications, complexity). All work includes: starting with definition of done and success criteria, agile project management, test-driven development, and project portfolio management.

Resources

Research using terms: XP (extreme programming), test-driven development (e.g., unit, integrative, end-to-end), Pareto principle, CI/CD
Case briefing template for use in new products
https://agility.im/frequent-agile-questions/

Story for Explaining Process

Some programming is relatively simple, and is really scripting. For this, the scripts run and any user can see the results to answer yes/no on if it worked. For that type of work, this page is less relevant.

Here, we are discussing complex systems and programming. This really is engineering.

As an example, think about an engineering team that creates a new plane engine.

Stakeholders have provided their needs.
The project manager, analyst, and owner have reviewed and translated these into sufficient technical information for actionable use by the engineers, and these are documented as acceptance and success criteria.
The engineers build the engine in the engineering shop, and tested for all needs as an engine alone (unit testing).
- Stakeholders can see the engine work as an engine at this stage. This is like seeing code on a local development environment (computer or test system) work, and is like code complete (at best 2/3 of the work, just like building a new engine alone does not result in a plane that is flyable with the new engine in use).
The engineers then deploy the new engine in a plane.
- Here, more testing is needed to make sure the engine works in the plane (integrative and end-to-end).
- Deployment is normally 1/3 of the work. This is where actual working is first fully validated, and working has to be for more than the first time. The first time can be a fluke; this has to be tested and ensured for reliability and predictability.
- Problems at this stage can be in many areas, including:
  - engine (e.g., was something in the engineering shop specific/hardcoded to that environment, where it needed to be a variable)
  - integration: does the engine not work with the plane? Is there a problem in the way the two interact together? A problem with a dependent system within the plane and its interaction?
  - external: does the plane need a new fuel type with the new engine? Is a longer runway needed for the plane to fly with this engine?
Working needs to be able to be validated by both the engineers and the pilot.
- Does the pilot have controls and reporting elements on the dashboard that operate properly, and that meet requirements for the pilot to know how to fly and when there is a problem?
- Does the pilot have a pre-flight checklist for this type of plane and engine?
- Do the engineers and mechanics have sufficient information for regular maintenance and for correcting problems?
Safety/security/compliance requirements:
- Even with all of the above conditions met, "working" is insufficient because there are other technical requirements that must be reviewed for safety/security.
- In the same way that the FAA can prevent a technically operable plane from flying, different IT groups can prevent systems from being deployed or can make a working system have to stop operating because of security requirements.
All of the above have to be met and successfully validated before the passenger-stakeholders can benefit from using the plane.

Process, Roles & Responsibilities

Process: Agile defines roles and responsibilities for all involved, and includes defined concepts to support optimal work towards success. For an overview of the iterative nature of work in agile, see the DDT slides on iterative development. For all LTS projects, a member of LTS will serve as the Product Manager, in addition to roles for the programming/development and other technical work. Additionally, a member of LTS may often serve as the Product Owner. LTS representatives are also stakeholders.

Roles & Responsibilities, Examples

Product Owner: "Product owners are focussed on the needs of their agile teams. They are there to make sure that their teams have all of the information they require about the feature they are working on, so the team can break it down into stories. The PO is available to the team and, if there are questions that the PO cannot answer, they will seek out a suitable, timely response." (Agile.im) See more on product owners: https://agility.im/frequent-agile-question/what-is-a-product-owner/
Product Manager: "They prioritise features and ensure each feature has clearly defined benefits to the customer and/or the organisation before it can be picked up by one of the agile teams. The PM is also the main point of contact for business owners and other interested parties." (Agile.im)
Stakeholder:
- "Being a good stakeholder is about collaboration and conversation. It needs understanding and self-discipline. Top tips include: routing all requests through the relevant product owner, or head of product; providing the correct amount of detail and justification for requests being made; providing the time to explain the need behind the request, not the solution." (Agile.im)
- See Agile Modeling on cultural change with agile stakeholder practices.
- Stakeholders provide information and proactive input necessary for the Definition of Ready (DoR), which is complements the Definition of Done (DoD).
- Agility.im provides these as "common items considered for a definition of ready:
  - Actionable – Is the item immediately actionable (doable) by the team? Do the team know what they need to do, and can they do it now? Is the item free from external dependencies?
  - Refined – Has the item been through a process of refinement before sprint planning? Is there a common understanding amongst the team on what the item is and how it will be implemented?
  - Value – What is the business value of the item? What is the value to the end user? Is the value clear to everyone on the team?
  - Estimated – Has the item been estimated by the team? And, is the item agreed to be of a size that the team are comfortable can be completed within a sprint?
  - Acceptance criteria – Has the item got clear acceptance criteria?
  - Demo – Do the team understand how they might demo the item or discuss it in the sprint review once complete?"
Developers:
- Developers are responsible for programming and other technical work to deliver systems that work and are maintainable.
- This means that developers are responsible for:
  - Code complete (which is initial coding and includes testing that adheres to the success and acceptance criteria), which is at best 2/3 of the work.
  - Deployment (including validation in the system, and end-to-end testing for any integrations); this means beyond day 1 - getting the code out for day 2 and the next and next, for reliability and predictability.
  - Asking for their needs to be met, as with user stories, documentation, checklists, success and acceptance criteria, and other elements that must be in place from stakeholders in order for developers to be successful.

Example: Panama Canal Museum Inventory

Years ago, the Panama Canal Museum Inventory (PCMI), which is a database without digital files, was loaded into UFDC. UFDC is not an appropriate technology because it is a digital library and users expect to find records and digital files, never just records.

With the migration pending for UFDC, LTS reached out to John Nemmers, who directs the Panama Collection, to see about options. In a meeting, three options were reviewed:

Pay for an external service like Past Perfect (example costs)
Use Omeka S hosted on UFLib Domains - no added cost; John defined that they would need customization (low expected initial cost, but unknown ongoing costs for mainetenance)
Build a local database

Following the meeting, John sent his specifications, so that LTS could review to better assess and make a recommendation.

In reviewing these options with the Software Unit, Chris noted a preference for the local database because it offered a learning opportunity for working with MVC. Given the relatively initial approximate costs for all options, the local database allowed for more known and lower costs ongoing, and the local database was the one option with an added benefit of a learning outcome, the local database option was selected by John and LTS in collaboration together.

This work is queued for Q3/Q4 of 2021.

ARL Position Description (PD) Bank

Brian Keith and Bonnie Smith led the development of the ARL PD Bank: a digital collection of position descriptions (PDs) from major academic and research libraries. The ARL PD Bank fosters the sharing of information through a browseable and searchable database that provides access to a national collection (or bank) of PDs. The ARL PD Bank supports the management of PDs for individual institutions, providing an effective organizational method and system that supports findability as well as archiving for long-term digital preservation.

For creating this important, international resource, Brian and Bonnie collaborated with library HR professionals around the country to develop the metadata tags, information structure, tools, and training. They then partnered with Mark Sullivan, as the programmer, and Laurie Taylor, as facilitator (in her Digital Humanities/Scholarship capacity) to support technical development. The first release went through iterations before and following release and testing.

As the ARL PD Bank emerged as a foundational resource, Brian and Bonnie again led next stage development, defining needs with two grants, and again collaborating with Laurie, Todd Digby, and Chelsea Johnston, to continue to develop the system, including moving to UF IT hosting and development, with a service level agreement and contracts for each phase with subcomponents and projects. As of 2021, the ARL PD Bank has released two major versions (funded by two major grants) and is in process on a third. In all of this, Brian and Bonnie have served as subject matter or domain experts, and collaborators informing and providing necessary information to inform and support development.

See more about the ARL PD Bank.

Example: ArchivesSpace

March 2020

LTS and Special & Area Studies Collections connected together to move ArchivesSpace forward. ArchivesSpace is industry standard software for managing archival collection information, which takes the form of finding guides. Previously, these had been managed on the Libraries' website, which is not the appropriate technology for this work because it does not fit for website or archival needs. Indeed, ArchivesSpace had been developed over many years specifically for these needs, and it is the appropriate technology.

LTS identified the Software Unit as the owners for this work: Andy as lead, with support from Chris (with support from Cliff for Linux, etc.). SASC identified Matt Kruse as primary, with John Nemmers as support. The four of them (Andy, Chris, Matt, and John) worked closely together through installation and configuration, and then updates.

October 2020

The updates were defined by Matt, who provided a list of desired features, user story style explanation of each need (what it does, why, etc.), notes on possible solution resources from the ArchivesSpace community, and other information to support Andy's work. Matt also defined his migration plan, which included shifting workflows, migrating content, and communications. The LTS and SASC team worked from this in an iterative and consultative manner.

February 2021:

ArchivesSpace officially went live.
LTS and SASC hosted a facilitated discussion on ArchivesSpace.
The Web Team updated the website search to include search of ArchivesSpace.

Resources/Supports

Matt provided: overview documentation, documentation throughout the process, expert consultation, referral to contacts at other institutions using ArchivesSpace for consultation, requirements for definition of done, migration path and process, and other work to support the process.

Andy and Chris: in addition to the technical work, they learned Linux (working with Cliff) and other technologies to be able to implement the system. Further, Andy and Chris met regularly with Matt for any questions/clarification. Chris sent weekly emails to Todd and Laurie, for updates and so Todd and Laurie could help on any questions/translations and on clearing any blockers.