VSHN Improvement Proposals

We need a way to capture and track organizational drivers. This way, we can ensure that everyone can see how we’ve responded to organizational drivers, what agreements we’ve made, and when and how we’ve reviewed the agreements. We also need an easy way to make drivers visible at any stage to the current accountable circle.

Don’t know what Organizational Drivers are? Start by reading How we evolve our organization.

Overview

The VSHN Improvement Proposals - in short VIPs - are a way to capture and record Organizational Drivers. It can be seen as our main Governance Backlog.

See Respond to Organizational Drivers to learn more about the difference between Governance and Operations.

VIPs are implemented as VSHN Improvement Proposal in Jira.

Statuses of VIPs

vips overview

Understand and Assign

Someone noticed Tension and wrote a (provisionally formulated) Driver. The Circle has to:

  • Consent to the Driver (formulation).

  • Consent that it’s as an organizational Driver, otherwise Drop it.

  • Consent that it’s within their Domain (are responsible), otherwise assign it to another Circle.

See Understanding and assigning Drivers.

Respond

We’ve an Organizational Driver which is within our domain (we’re responsible). It’s yet unclear how we respond to it. Possible options are:

  • Decide that this is Operations and doesn’t need a Governance decision.

  • Decide that it’s Governance.

See Respond to Organizational Drivers.

Proposal Forming

We’ve an Organizational Driver that we want to address with a Proposal. Usually the following might happen in this phase:

  • Through discussions, surveys, etc. we find constraints, considerations and ideas for a Proposal.

  • We choose 2—3 Tuners that will use the gathered information to Design a Proposal

See Create Proposals.

Decision Making

We’ve a Proposal that offers a solution to the Organizational Driver. The accountable circle:

  • consents to the Driver (if not already done perviously).

  • asks clarifying questions.

  • raises potential Objection.

  • resolves Objections with the help of the Tuners to amend the Proposal as needed to improve it.

If there are no unresolved Objections in the sense of good enough for now, safe enough to try, we made the decision.

See Consent Decision Making.

Agreement

The Proposal is now an agreement, let’s celebrate that! The accountable circle:

  • sets a due-date for the next review of the agreement.

  • can plan follow-up actions to implement this proposal.

  • makes sure that the agreement is documented (for example in the handbook).

Review

On the due-date of the VIP or when we see the need (tension based), the accountable circle:

  • Reviews the Driver - Is it still relevant?

  • Review the effect of the Agreement - does it still address the driver and does it have the intended effect?

  • Consents to either:

    • Keep the Agreement

    • Evolve it

    • Drop it

See Evaluate and Evolve.

Implementation

Jira is how we track VIPs - The Driver and the Proposal is on a Wiki page or in a Merge Request. The VIP itself is created in Jira - the resulting unique VIP number is used everywhere else.

You find the VIPs here in Jira:

  • Project: VSHN Improvement Proposals (VIP)

  • Issuetype: VSHN Improvement Proposal

VIPs can be anywhere in the Wiki as long as the wiki page and Jira issue are linked in both directions. There are some common places for the VIPs though, for example:

Wiki Pages, with the page name following the schema VIP-X - <name of driver = Jira summary> contain:

  • The Driver summary formulation

  • The Wiki page might contain information to help understanding the driver

  • Questions, Concern and Objections documentation

  • Proposal is (one of) linked:

    • On the same Wiki page

    • GitLab Merge Requests (usually the VSHN handbook), include VIP-X in the title of the MR

The driver formulation can be in Jira, until we go into Proposal Forming.

Merge Requests

If you don’t need a wiki page, you can simply use a merge request in GitLab as long as you link the MR and Jira issues in both directions.

Documenting Concerns

When we resolve objections during decision making we should document concern on the Wiki pages or in the merge requests. Concern can be considered when we review VIPs to Evaluate and Evolve.

Objection handling

The Wiki page templates has a section Objection handling with a table where we document each potential objection and the steps taken to resolve it. In Merge Requests this happens as threads with comments.

We should handle Objections in Governance or other meetings and not start discussions on a wiki page. Documenting the findings here is very welcome though.

Inter-Linking of VIPs

VIPs can:

  • relate to each other (relates to in Jira) - use sparingly where it helps to understand the context.

  • address a parent driver (address driver in Jira) or have sub-drivers (has sub driver in Jira) - mandatory

Making Proposals and Change visible

We want to make everything we’re working on visible to everyone so that everyone knows what’s around to read, comment, object or help with. As VIPs are normal issues in Jira, we can easily filter, sort and show the VIPs on boards in Jira and Confluence.

This allows us to have an automated overview to:

  • Show in Weekly Company Meetings

  • Base a "Weekly OrgDev newsletter" on it or similar.

  • Sync with external Coaching about what’s currently going on

Out of Scope

VIPs are for organizational topics (the Governance Backlog) and aren’t:

  • about tracking operational issues which clearly fall within an existing Domain's core tasks.

  • "Tickets" on which you actually work to implement something. Implementation is always done in follow-up tasks.

This process is tracked and reviewed as VIP-1