Applying SOHP framework for organizational change

One of the common question raised by beginner Scrum Masters and Agile Coaches is how to structure the interactions with team or organization they are working with. One of the feasible answers to this question I borrowed from medical frameworks.

 

SOAP framework in a part of problem-oriented medical record approach that was suggested by developed by Lawrence Weed, MD in 1970s. It is used during initial assessment or subsequent visits to gather and capture relative information. It contains four components: Subjective, Objective, Assessment and Plan. While gathering data clinician covers this four areas:

  • Subjective data. Clinician gather data on how patient assess his or her own status, history of symptoms, etc. There are seneval mnemonics that help to structure this part of assessment, for example OLDCHARTS, that includes Onset, Location, Duration, Character, Aggravating / Alleviating Factors, Radiation, Timing and Severity.
  • Objective data. This includes information that the healthcare provider observes or measures from the patient’s current presentation, e.g. vital data, instrumental tests (MRI, x-ray etc.) and findings from physical observation etc.
  • Assessment. More and more often this one is replaced with “Hypothesis” (changing mnemonic to SOHP; this was proposed by clinical psychologist Barbara Lichner Ingram), but the main idea is pretty much the same – it is a summary of symptoms and diagnosis (including differential diagnosis and other possible diagnosis) and reasoning behind that diagnosis.
  • Plan. In this section clinician describes treatment plan: follow-up procedures, additional labs etc.

 

This approach has also some downsides. Some critics suppose that it encourages sequential analysis of the problem instead of an integrative approach, and focuses more on data collection than on evaluation and analysis itself. However, this approach has proved to be very successful in providing a structure that helps doctors record their notes about patients, and view those notes subsequently in a manner that quickly gives them a good understanding of that patients history.

 

It is important to notice that SOAP/SOHP describes not the whole process of clinician-patient interactions – it is imbedded in a general session structure that is adjusted for each session. Key thing is to start each action, including data gathering, by providing explanation of what a clinician is going to do, justifications for this particular action and getting consent from patient. Above the informed consent required by law in most countries, this helps to manage expectations and create trust between clinician and patient that usually improves therapy results.

 

With some adaptations this framework can be helpful to work with organizational transformation, especially for initial interview and change planning. I start the session by explaining how our session will be structured (describing SOHP framework and why do I need all this information), ask for consent and then structure out session based on modified SOHP framework:

  • Subjective data. Here I am trying to gather maximum data on how client sees their problem and what they expect from our collaboration. I use an extended version of OLDCHARTS: OLDCHARTERS: Onset, Location, Duration, Character, Aggravating / Alleviating factors, Radiation, Timing, Expectations, Results at success/failure and Severity. To clarify subjective view I use the following questions:
    • What can I do for you? (I use an open question and provide enough space for a client to talk about their problems to get as much information as possible. I can also ask “What else?” to dig deeper.)
    • How long does this problem exist? Have you had any similar problems? If yes, what have you tried to improve the situation? (Onset / Duration)
    • How severe this problem is? Does it disrupts organizational activities? What metaphor would you use to describe this problem? How would you rate a severity of this problem on a scale from 1 to 10? (Severity/Character)
    • Does this problem persist in a specific part of organization or it influences the whole organization? Who problem localization changed over time? (Location/Radiation)
    • What have you tried to do to mitigate this problem? How that influenced the problem? (Aggravating/Alleviating factors)
    • Does this problem gets better, worse or does not change with time? If there are changes, what is the pace of change? (Timing/Duration)
    • Are there any other related problems? (This question helps to identify problems that client think of as a separate problem, but they can be related to main issue).
    • What do you think causes a problem? What do you worry about in relation to this problem? (This questions can help to identify client’s assumptions about the problem and what they believe this problem might lead to).
    • Why now? What have changed compared to how this problem usually reveals itself? (This might reveal that the problem got worse recently, or client’s perception of the problem changed. Latter often happens as a result of a client went to a training of learned about changes happening in other organization).
    • What you expect from me? What are your assumptions on what I would be doing? What are your assumptions about what I would not do?
    • How would you know that the changes will be a success? What would you see in your organization 6 months (year, three years etc.) after today  if we could improve the problem? (This question helps me to identify how client defines success and assess whether client’s expectations are realistic)
    • How would you know that the changes will be a failure? What would you see in your organization 6 months (year, three years etc.) after today if our efforts will lead to failure? (This question helps me to identify how client defines failure and reveal possible scenarios that could worsen the situation)
  • Objective data. Here I gather all available metrics that are relative to the problem. This data can be helpful to assess the effects of the change. Руку I also gather the results of my observations, qualitative and quantitative assessment of organization. Here I also can propose to gather some additional metrics that can be helpful in assessing the effects of our work.
  • Hypothesis. Next step will be to create a hypothesis about problem causes and provide a justification of my view. I also describe how caт I confirm or disprove the hypothesis and what experiments I will run and what results I would expect as confirmation of disprove.
  • Plan. This is where I describe a plan of  organizational change experiments based on the above.

During interview with a client I don’t use the exact sequence and wording of the questions described above. Rather I use this as a framework, that guides the emerging discussion with a client. I also adjust the wording to fit a particular client: of example some clients avoid using the term “problem” speaking about what is going on in their organization. for such clients I use “situation” or “specificities”.

Here is an example of SOHP record made after initial interview with a head of IT department (in order to keep confidentiality this example based on a mixture of several real clients)

Context:

A team of 5 (3 developers and 2 testers) working on a new product for a big organization using Scrum framework. Team reports to head of IT department.

Subjective:

Team includes employees from a larger IT project, that had several teams developing a big internal application. Previous project used Scrum framework, but was unable to deliver any working product for a long time, so business lost their interest in it and it was cancelled. New team works on a completely new application that is considered a strategic priority and several C-level executives have stakes in it. Team Scrum Master learnet about Scrum on his own, but noone on the team had a training on Scrum. Scrum Master asked head of IT department to invite an Agile Coach to make sure that the team does not make any significant mistakes applying Scrum that might lead to a troubles with the team of with the product.  I expect you to observe their daily interactions anв Scrum events, review team’s artifacts and provide recommendations on what and how they could improve to increase probability of successful product delivery according to client’s expectations. i will consider coaching a success if Scrum Master and key stakeholder will consider your recommendations helpful to improve their collaboration. Ideally a team will deliver something that stakeholder could use to provide feedback within the following 4 weeks.

Objective:

Team has all elements of Scrum framework in place. Currently team run 2 two-week prints, but have not delivered any working Increment. Product vision is not defined explicitly while team members can describe in general terms the product that they are building. Product Backlog has 12 items in it defined as User Stories, but no item has Acceptance Criteria defined. Product Owner is a representative of a business department, communicating the expectations of the head of the department (key stakeholder). Product Owner can not identify with confidence the most valuable Backlog items. Team is distributed: Development Team and Scrum Master are located in a single room, Product Owner and key stakeholder located in a separate building in another district. Currently no metrics are gathered except team Velocity (in Story Points). During the first two Sprints team delivered about 50% of what was in the Sprint Backlog.

Hypothesis:

Misalignment and poor communications between Development Team and key stakeholder as a result of a dysfunctional Product Owner (“a ferry”) that has no authority nor clear vision. Because of that Product Owner has to approve all his inputs with the key stakeholder so decision making speed is very low. No explicit product vision prevents Development Team from making decisions based on key stakeholder expectations. Sprint Review does not serve it’s main purpose – to gather feedback from stakeholders because the latter are not present. To test this hypothesis I would compare the product vision presented by key stakeholder, and by members of Scrum Team.

Plan:

  • Run a workshop to define product vision and refine Product Backlog with Scrum Team and key stakeholder involved.
  • Recommend to invite key stakeholder on Sprint Reviews.
  • Observe Scrum events and coach Scrum Master on how to improve the events.
  • Personal coaching of Scrum Master.
Share