Digital Partnerships & Strategies Department, Strategic Planning, Handout

By:
On:
In: Uncategorized

Below is a handout (or digital file) for our departmental strategic planning session for this year year.

Digital Partnerships & Strategies, Readings for Strategic Planning Meetings in 2020

From 2019 readings:

Grounded Theory

Grounded Theory: research method where the theory and findings are developed from the data; does not start with a hypothesis that is then tested by experiment/data.  Benefits include: “Ecological validity: Ecological validity is the extent to which research findings accurately represent real-world settings. Grounded theories are usually ecologically valid because they are similar to the data from which they were established. Although the constructs in a grounded theory are appropriately abstract (since their goal is to explain other similar phenomenon), they are context-specific, detailed, and tightly connected to the data.” (https://en.wikipedia.org/wiki/Grounded_theory)

Situated Knowledges:

We are limited, and our world is complex. If we want to see and understand at the greatest scope possible, we do so by defining our partial vision, our limited locations, and our distance and responsibility to our communities. Doing this “allows us to become answerable for what we learn how to see.” https://philpapers.org/archive/HARSKT.pdf

Designated Community

Management Council of the Consultative Committee for Space Data Systems (CCSDS), REFERENCE MODEL FOR AN OPEN ARCHIVAL INFORMATION SYSTEM (OAIS), Magenta Book:

Archive: An organization that intends to preserve information for access and use by a Designated Community.

Designated Community: An identified group of potential Consumers who should be able to understand a particular set of information. The Designated Community may be composed of multiple user communities. A Designated Community is defined by the Archive and this definition may change over time.

Notes above, consider in relation to: stakeholders, who we design for, how we manage projects/programs/activities

|

Notes below, consider how all of these are communication methods to: translate/map/connect across different domain expertise areas together, and to do these following norms/standards for project/program/process management.

Agile

Agile is an approach, mindset, collection of values and principles, but not a methodology. From Wikipedia: “[Agile software development] approaches develop requirements and solutions through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s). It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages flexible responses to change.” Not a framework or methodology.

Scrum and Sprints

Wikipedia:

  • “Scrumis an agile framework for developing, delivering, and sustaining complex products, with an initial emphasis on software development, although it has been used in other fields including research, sales, marketing and advanced technologies. It is designed for teams of ten or fewer members, who break their work into goals that can be completed within timeboxed iterations, called sprints, no longer than one month and most commonly two weeks. The Scrum Team track progress in 15-minute time-boxed daily meetings, called daily scrums. At the end of the sprint, the team holds sprint review, to demonstrate the work done, and sprint retrospective to continuously improve.”
  • “Scrum is a lightweight, iterativeand incremental framework for managing complex work. The framework challenges assumptions of the traditional, sequential approach to product development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines involved.”
  • “A key principle of Scrum is the dual recognition that customers will change their minds about what they want or need (often called requirements volatility) and that there will be unpredictable challenges—for which a predictive or planned approach is not suited.”
  • Other notes:
    • Roles: Product Owner
    • Acceptance criteria: When is something done, and who validates?
      • Existing concepts/ways for working: Peer review process, for improvement and validation
    • How we are doing this with the Digital Development Team, and what we had before.
    • From project management, schedules do 3 things: commitment, contract among those involved, communication (often external)
    • Schedules
      • Follow rule of thirds: 1/3 each for: design, implementation, testing (and iterate; big projects have main and then many little schedules)
      • Schedule is a possibility, and more accurate when working from places of greater information
      • Changes cause chain reactions; iterating de-escalates and controls for this
    • Test Driven Development: https://en.wikipedia.org/wiki/Test-driven_development
      • Tests validate the coding, but the process is changed because developers design for test-ability and: “By focusing on the test cases first, one must imagine how the functionality is used by clients (in the first case, the test cases). So, the programmer is concerned with the interface before the implementation.”
    • Behavior Driven Development (https://en.wikipedia.org/wiki/Behavior-driven_development):

Philosophies and Practices

Notes on Scale:

  • “Scale is a mysterious phenomenon – processes that work fine at one scale can fail at 10 times that size, and processes that successfully handle a 10-times scale can fail at 100 times. […] Institutions offering tools and systems for digital preservation should be careful to explain the scale(s) at which their systems have been tested, and institutions implementing such systems should ideally test them at scales far above their intended daily operation […] to have a sense of when scaling issues are likely to appear.” (Page 26; Shirkey, Clay. Library of Congress Archive Ingest and Handling Test (AIHT) Final Library of Congress. June 2005. Washington, DC. 1 May 2011. www.digitalpreservation.gov/library/pdf/ndiipp_aiht_final_report.pdf
  • “Scale changes everything” (Page 28, Owens, Evan; Cheruku, Vinay; Meyer, John; and Morrissey, Sheila. “Digital Content Management at Scale: A Case Study from Portico.” Digital Library Federation Spring Forum. 28-30 April 2008. Minneapolis, MN. 1 May 2011. diglib.org/forums/spring2008/presentations/Owens.pdf