Skip to content

Working agreement

Jump to bottom
Philip Levy edited this page Sep 2, 2021 · 9 revisions

Sections:

Process

The general approach is inspired by Shape Up from Basecamp.

High-level sequence:

  • Gather ideas.
  • Form promising ideas into a pitch.
  • Product owner adds pitch to a cycle.
  • Work is completed and launched during at end of cycle.

Types of work

The team has two streams of work: planned work done in regularly scheduled cycles and unplanned work picked up in response to business development opportunities.

Planned work:

  • Happens in cycles
  • Includes a mix of project initiatives and maker materials (tools, templates, frameworks)
  • Maybe be delayed by unplanned work

Unplanned work:

  • Takes priority over planned work
  • May involved people outside the core team
  • Will usually be in response to a timely business development effort

Deciding what to work on

Consider these factors when deciding what planned work to take on: relevance, scope, benefits. The product owner will make the final call on what to add to the cycle.

Relevance

  • What portofolio does it align to?
  • Which clients is it relevant to?
  • Is this is a good time?
  • How does it align to team principles? (speed, tangibility, reusability, openness)

Scope

  • What problem are we solving?
  • How important is the problem?
  • What version of this can we comfortably commit to completing during a cycle?

Benefits

  • What capabilities can we demonstrate?
  • What technologies are we using?
  • How does this support our overall objectives?

Cycles

The initial work for this team has been defined in 30/60/90-day milestones. See the roadmap. Beyond that, we will define work in 3-week cycles, with a 1-week break in between them. Planned work that is committed to should be completed within the cycle time (unless it necessarily deferred by unplanned work).

Shaping

Before we commit to doing work during a cycle, it must be shaped. That means the problem discovery and problem validation has already happened. See Shaping work in the Bixal Methods wiki for more details.

Committing

Committing is the process of deciding what shaped work is added to the cycle.

All work committed to should have a reasonably probability of being completed during the cycle.

All issues will be assigned to a team member.

Doing

During the cycle, work will be tracked on a GitHub project board.

Team members should keep their assigned issues up-to-date by adding comments and links to latest work, and updating the status on the project board.

All work must be reviewed by another team member before being moved to Done.

Definition of Done

Because we will do different types of work, the definition of done will not be uniform, but these are some general principles to apply across all our work:

  • It should be reviewed by someone else before shipping.
  • It's not "done" until it's shipped.
  • It's never really done, but anything we ship should provide a coherent experience.

Deploying

Depending on the nature of the issue, some issues may be deployed immediately. Others may be held and packaged into a release.

Team members

These are the core members of the team. Other people may augment the team from time to time depending on their availability and skillset and the needs of an engagement.

Meetings

We aim to have as few meetings as possible. The product owner will also shield the rest of the team from external meetings when possible.

Try to keep interactions that don't require getting everyone together at the same time asynchronous, for example status updates or quick feedback.

If you must schedule a meeting, consider using the mindful meeting invitation.

Working sessions

For the purpose of learning together and sharing knowledge in realtime, we will schedule some working sessions where the purpose is to collaborate or co-create (not just talk).

Communication

To keep things simple, we primarily use Teams for internal communication and GitHub for external communication. We may also occassionally send emails.

  • Ad-hoc, semi-synchronous chat: Teams
  • Ideas and Pitches: GitHub Discussions
  • Project management: GitHub Projects
  • Documentation: GitHub Wiki (public), Teams Files (internal)
  • Releases: GitHub Releases

Time

Work for capture or business development efforts may require a specific billing code. For all other work related to the team, use this code:

Feedback

  • If you find a bug, enter it as an Issue.
  • If you have an idea for a new project or maker material, start an Idea discussion.
  • If you have a fully formed pitch for consideration to take on during a cycle, start a Pitch discussion.
  • If you have questions, start a Q&A discussion.

Iterating on this agreement

This agreement will be reviewed between each cycle for potential revisions and enhancements.

Clone this wiki locally