Delivery Management

I’ve done many types of delivery management in my career: project management, programme management, portfolio management, service management. In every case my aim is to help people to produce the best possible outcomes for customers in a way the team can sustain indefinitely.

I’ve always been a fan of Google’s SRE Model. It essentially breaks down work into two categories: fighting fires, and preventing fires. Under this model, the system becomes continuously more robust as causes of instability become less numerous and more interesting over time.

It applies beautifully to digital products & services and equally well to delivery of those products & services. Delivery can be brittle, opaque, and anxiety-inducing or resilient, transparent, and confidence-building.

Discoverable, recent, and accurate information form a foundation for stability & growth. There are many principles, tools, and processes for doing this. For my future reference, here are a few favourites.

I may expand on them in the future.

Measurable goals

• Avoid reporting on activities
• Use OKRs to describe impact
• Check-in regularly and share confidence, rationale, and next actions publicly

Week notes & newsletters

Send week notes. I like this format:

• What did we do this week?
• What will we do next week?
• What else should you know?
• Something fun…

Enable people to subscribe & unsubscribe as they like.

Roadmaps

• Try the 3 Horizons method (e.g. what things are you doing Now, Next, & Later?)

Decision Logs

I’m a huge fan of decision logs. They allow you to have living documentation of how a system works including both technical architecture and ways of working. They can include things like plans, designs, decisions, open questions, and working agreements.

• Use a simple text file
• Bonus: use markdown
• Store in version control
• Make them public

Typically they should include:

• Serial number for easy reference (e.g. DR-001)
• Title
• Date (of first publishing)
• Description of the question, problem, or condition
• Options considered
• Pros & cons (benefits/costs/risks) of each option
• Which option was chosen
• Follow-up actions required
• Signatories (who has agreed to this)
• Updates & changes (date and summary)
• Links to related:
  • Artefacts
  • Work items
  • Decisions
  • Operating procedures
  • Work instructions
  • Runbook items

Runbooks, work instructions, and operating procedures

• Runbooks: Step-by-step instructions for setting up, operating, maintaining, troubleshooting, and decommissioning a system
• Operating procedures - guidance for decision making and choosing which work instructions to follow (e.g. crisis management)
• Work instructions: step-by-step instructions for completing common tasks (e.g. onboarding)

Visible processes & visible work

• Kanban boards
• Ranked backlogs
• Ecocycle plans

Value stream maps

Visualise the flow of work. Understand each part of the process. What is it called? Who does it? How long does it take? At what point in the overall process does it happen? How often does it fail? What does it cost? How do they connect?

Patterns & templates

Save your decision-making energy for the things that really matter. Turn your good decisions into reusable patterns and templates for things like:

• New work items
• Newsletters
• Customer service emails
• Meeting minutes
• Decision logs
• FAQs
• Any repeatable process such as:
  • Team member onboarding/offboarding
  • Deployments
  • Code reviews
  • User research sessions
  • Customer onboarding
  • Agile ceremonies (backlog refinement, retrospectives, demos)
  • See runbooks, operating procedures, and work instructions above

Budgeting

• Practice agile budgeting
• See Beyond Budgeting & Bjarte Bogsnes
• Use “last best estimates” and update them frequently
• Share actuals frequently and accurately across the org
• Perform frequent re-forecasting & blameless gap analysis
• Redistribute funds between teams as necessary
  • This reduces fear of over/under spend

Prototypes, diagrams, sketches, & models

All models are wrong, but some are useful – George Fox

Building consensus

• Work in the open
• Share ideas early (use requests for comments - RFCs)
• Start building consensus with one person (via a one-to-one conversation)
• Bring conversations to a public forum when you have at least one person on board
• If a decision gets made, memorialise it in a decision record

Update-ability

• Default to things being editable by everyone
• Keep an audit trail of all changes
• Use version control (keep a history of changes)
• Write release notes for everything
• Consider using semantic versioning for everything
• Maintain quality (even for documents) with:
  • Pairing
  • Linting
  • Automated tests
  • Pull-requests

Discoverability

• Everything should have a canonical URL
• Link every mention of a thing to its canonical URL
• Link to detailed information, don’t duplicate
• Default to everything being open and visible
• Only lock things down when absolutely necessary
• When things move, mark the old version as obsolete and clearly sign-post to the new one (think 301 redirects)

Email

• Use sparingly, people get too much and things get lost.

Realtime chat

• For rapid, asynchronous conversations between humans
• Have a public channel for the team to share information and receive questions from outside the team
• Have a private channel for the team (only if necessary)
• Create new channels for specific topics, archive them when the topic is no longer relevant
• Use naming conventions to aid discoverability e.g. “team-proteus” for a specific team or “club-music” for a special interest group or “ticket-355” for a specific story or ticket
• Record short videos as an async alternative to a meeting or live demo

Releases

• Write release notes even if they’re minimal. It’s important to know what’s new
• Communicate via your newsletter, public chat space, and any other channels you have.
• Link to specific work items (tickets) which are included in the release
• Assign a semantic version number
• Include the version number somewhere in the app so people know what they’re using

Specifications & requirements

Use a single system & language understandable by every stakeholder and team member (engineers, machines, business people, customers, and designers)

• Use Behaviour Driven Development
• Use spec by example (see the book)

Meetings

Thanks to Peter Senge & The Fifth Discipline

• Don’t meet without an agenda
• Differentiate information sharing from decision making
• Share pre-recorded videos with closed captions, auto-translation and speed control
• hold optional live Q&A sessions later
• Debrief at the end of every meeting
  • What should we keep next time?
  • What should we change?
  • Try a ROTI
• Leave a 10 min gap between meetings
• End on time
• Record, transcribe, and summarise every meeting with AI
• Capture actions and decisions from every meeting (see Decision Logs)
• Understand the difference between debate, discussion, and dialogue.
  • Debate: one right answer; I’m going to prove I’m “right”
  • Discussion: Union of our ideas and answers, many possibilities
  • Dialogue: Discovery of new possibilities that no-individual could anticipate
• Balance advocacy with curiosity
• Learn & use Liberating Structures