Chapter 9 Co-coordinated Workstreams (DataOps, PeopleOps)

9.1 Specific Workflows

  • support_workflow: This coordinated workflow of both quant_workflow and sim_ui_workflow is in support of development and operations value streams. Coordinated by DataOps.
  • sim_ui_workflow: This workflow provides design, maintenance, and operational support of the MTL Simulation User Interface (Sim UI) in support of development and operations. Coordinated by DataOps.
  • consult_workflow: VACO OMHSP Facilitators of the NIH & VA cluster randomized trials. Supports the research and operations value streams. Coordinated by PeopleOps.

9.2 Team PSD 2.0 Monthly Process

As Team PSD continues to grow, our workflow alongside team values in order to better support the needs of our team, just like how we developed Modeling to Learn to scale nationally in the Veterans Health Administration.

The participatory learning principles we scaled in Modeling to Learn are:

  • equitable access to resources
  • mutual learning
  • shared decision-making

Team PSD 2.0 is about becoming more scalable due to continuous integration, deployment and documention.

  • We aim for a completely free, accessible, transparent and reproducible workflow (aka “open science”).
  • Our mission to improve how healthcare quality improvement decisions are made enlists diverse team members and partners.
  • We want to empower effective contributions from all potential stakeholders.

The Team PSD 2.0 Monthly Process is based on the design thinking principles of user experience, which attemps to account for a person’s needs, pain points, goals, and emotional experience when using a product/service and/or going through a process and system.

Team PSD 2.0 Process for monthly sprints/epics:

Week 1: Gather user-centered hypotheses

Week 2: Clarify user assumptions w/ Minimum Viable Product (MVP) test

Week 3: Review results of user persona testing of your MVP Prototype (with concurrent video and retrospective verbal)

Week 4: Review user persona artifacts and second story perspectives mindfully and empathically to discover new understandings you might have missed or still need to learn

Our monthly process for each monthly sprint/epic is based on the process for design thinking:

9.2.1 Week 1: Gather User Hypotheses

In week 1, we want to gather the user centered hypotheses of the user/user group that we want to help and design for either by meeting with them and/or referring to their user personas.

Hypotheses should consist of the user’s needs, pain points, and consider the background and context of the user.

Week 1 follows the first phase of the process for design thinking which involves the ability to empathize with the user’s current state of experience.

  1. Empathize - To gain an empathic understanding of the need or problem you are trying to solve in terms of people, processes that set aside individual assumptions to get insight into the need.
  • What? Details of what to do (what happened).
    • This is when we analyze observe and document details that relate to users.
  • How? How the person does it (effort, etc.)
  • Why? Motivations/purpose (test this out…)

Exercises for assumptions (remember: everything is a perspective):

  1. List assumptions

  2. Ask: How could this not be true?

  3. Ask: What if we could do this twice as well in half the time?

Example of a User Persona:

9.2.2 Week 2: Clarify User Assumptions w/ MVP test

In week 2, we want to narrow down the week 1 user centered hypotheses by clarifying assumptions based on those hypotheses.

Assumptions the designer has based on week 1 hypotheses should clarified to define only the most crucial and necessary needs and pain points that will be addressed before prototyping a minimum viable product (MVP). This will prevent creating/designing for needs that do not solve 80% of the user’s pain points with only 20% effort being used in the development of the MVP and test and quickly rule out MVPs that do not respond to needs of the users in a fast and cheap manner.

Week 2 follows the 2nd phase of the process for design thinking which involves the ability to define with the user’s specific set of problems that needs to be immediately addressed.

  1. Define the problem - This is when we synthesize observations into holistic point of view (POV).

Goal is to make linkages, so that we define the right problem to address.

[Example POV: Busy, nationally distributed, cross-functional team of scientists has many partners, is about to hire more people, leads a national participatory system dynamics simulation learning program in, and is gaining increasing national and international interest in partnership HMW…]

2a. A problem statement: Focuses on

  • Specific peopleʼs needs (not the technology or specs),
  • Value and insights for the project (not the technical requirements), yet it is…
  • …narrow enough to be managed within our constraints

Exercises for definitions with how-why/why-how laddering (a variant of 5 whys principle):

  1. Asking “Why?” Explores to understand root causes (abstract, more common across people)

  2. …then “How might we?” to get to a specific problem/challenge we can solve (concrete)

Part I - The HMW Brainstorm…HMW

  • use the efficiency of GitHub [good]
  • remove the [bad] steep learning curve
  • integrate with existing GH norms the best part [explore the opposite]
  • remove reliance on training [question the assumption]
  • go after adjectives [make it easy, instead of hard]
  • use code instead of by hand [leverage unexpected resource]
  • enable self-directed learning like “Googling” [analogy from need/context]
  • attract help from Forio, MITRE, VA to solve this [shift POV against the challenge]
  • get it up and running now [shift a status quo]
  • divvy up chunks for each workgroup [break up POV]

Part II

  1. “Why do we need to integrate our manuals, workflows and processes on GitHub to achieve Team PSD values? (if start with Why, phrase as a need and make it meaningful.”

Because…

  1. “How do we use manuals, workflows and process on GitHub now?”
  • [describe]
  • “Why?”
  • “Why?”
  1. What what was most surprising?
  2. What would we have missed if we hadnʼt asked why?

9.3 Test a New Modeling to Learn Release

  • Value Stream: Development, Operations
  • Workstream: Co-coordinated by DataDevOps & PeopleOps
  • Workflow: facilitate_workflow, support_workflow
  • Video: TBP

Teams Channel Link

  1. Create a TEST branch off the Master branch in production.
  2. Coordinate with PeopleOps to identify the MTL Red & Blue TEST teams.
  3. DataDevOps works with PeopleOps to document the new release features and conduct User Acceptance Testing (UAT or “TEST”) with facilitators/learners.

TEST on lzim/mtl will be our slow TEST condition for new releases. - TEST does need to be current w/Master, so we will create a fresh TEST branch when we begin a TEST condition for a new release. - TEST will be where the health equity module and other new release work for MTL 4.0 will be tested with TEST teams.

Note this is distinct from QA on lzim/mtl which is our fast quality assurance process to the master branch.

In week 3, we want to share our MVPs with the user to collect user feedback.

To collect feedback, users will be participating in 2 Think Aloud protocols: Concurrent Screencast Video (no audio) and Retrospective Verbal.

  1. A Concurrent Screencast Video Think Aloud requires users to screencast themselves going through the MVP prototype, but without audio so they can focus solely on using the MVP.
  2. A Retrospective Verbal Think Aloud occurs after the Concurrent Screencast Video Think Aloud in which users think about how they felt about the MVP, what went wrong, what went right, what was missing, etc and write it up afterwards.

These 2 Think Aloud protocols allows us to leverage both the pros and cons of a Concurrent and Retrospective Think Aloud in which:

  • the Concurrent provides an undisturbed recording of the user going through the MVP.
  • the Retrospective allows the users to verbalize their thoughts, emotions, and feelings about the MVP.

Week 3 follows the 3rd and 4th phases of the process for design thinking which involves the ability to ideate MVPs based on the needs and assumptions of the users and get user feedback on a prototype MVP that will solve 80% of the user’s pain points and needs with only 20% effort.

  1. Ideate - Expand the problem space by identifying and testing out elements that would circumvent problems.
  • time-limit
  • quantity over quality
  • no distractions
  • no bad ideas
  1. Prototype - inexpensive, scaled down version with the key features to investigate the problem and solution. Goal is to identify the best possible solution.
  • Solutions are investigated, accepted, improved, re-examined, rejected based on user-experiences.
  • Should give much better sense sense of constraints and how users would behave, think, and feels when interaction with it.