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: 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)
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
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 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.
- Agile, Wikipedia: https://en.wikipedia.org/wiki/Agile_software_development
- 2001: Agile Manifesto, 2001: https://agilemanifesto.org/principles.html
- Ways of working/thinking:
- Iteration as a way to make progress (rinse and repeat): https://basecamp.com/gettingreal/06.2-rinse-and-repeat
- Seek and celebrate small victories: https://basecamp.com/gettingreal/07.4-seek-and-celebrate-small-victories
- 80/20 Rule, Pareto principle: https://en.wikipedia.org/wiki/Pareto_principle
- What 20% effort can we apply to get 80% done?
- When we get to 80% can we stop, or do we need to do the final 80% of the effort for only 20% of the returns?
- “Don’t Do Dead Documents”: https://basecamp.com/gettingreal/11.2-dont-do-dead-documents
- Documentation should also have stakeholders and users (teammates/managers who use the documentation; other stakeholders)
Scrum and Sprints
- “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)
- 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):
- “is an Agile software developmentprocess that encourages collaboration among developers, QA and non-technical or business participants in a software project. It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave. It emerged from test-driven development (TDD). Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.”
- Working together to specify features (and not allowing non-tech users to determine how to do the work; “they’ll design a solution for you” (BDD in Action)
- See: user story versus specification
- Working from examples
- Design for the edge cases (e.g., accessibility; lowest common tech; etc.): https://tannerchristensen.com/blog/2019/6/17/design-edge-cases-and-where-to-find-them
- Corner cases: https://en.wikipedia.org/wiki/Corner_case
Philosophies and Practices
- Make Opinionated Software: Your app should take sides: https://basecamp.com/gettingreal/04.6-make-opinionated-software
- Compassionate Coding: https://compassionatecoding.com/
- Good, active documentation; built with pride of ownership
- Sustainable, maintainable; supports next-worker well-being
- Related-ish terms: technical debt, cruft, greenfield
- Minimal Computing, how can we do the work with the simplest to use (so most inclusive) and most sustainable technology possible; philosophy is opposed to architectural astronauts, overly expensive, and exclusionary (even if unintentional) systems/practices: https://go-dh.github.io/mincomp/about/
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