When supporting teams in the many software engineering disciplines, we often help them define approaches to handling specific challenges. Writing them down on documents is an effective way to scale this process.
In his own words,
Strategies are grounded documents which explain the trade-offs and actions that will be taken to address a specific challenge.
Although very familiar with writing guides for my teams (I prefer this word to refer to such documents), I found this simple process very helpful in communicating the message, and I started applying it in some documents I share with my teams.
Characteristics of a strategy:
- Its purpose is to share an approach to a specific challenge;
- It is practical;
- It is accurate and detailed;
You may write as many as you want. For a development squad, in my perspective, some guides we could define include:
- Effective Backlog refinement;
- Measuring our development process;
- How to write User Stories;
- Our on-call process;
- How to partner with other teams;
According to the author, a good strategy consists of:
- Diagnosis: It is the theory describing the challenge at hand - its factors and constraints - and a problem statement;
- Policies: Those are the policies that we will apply to address the challenge. It describes the general approach that we take to tackle the problem;
- Actions: Those are the specific steps that we implement to address the challenge.
This process is quite similar to how a doctor treats a patient. First, he names the disease or pathology (diagnosis of the problem); Second, he considers the therapeutic approach for it (guiding policy); Finally, he prescribes therapy or medication (actions to be taken).