Topic: teamwork
-
DACI and RACI for technical decisions: one approver, named contributors
DACI names a driver who runs the decision, a single approver who makes it, contributors who have a voice but no vote, and informed parties who learn the outcome; RACI assigns responsible, accountable, consulted and informed roles to tasks. Either works for technical decisions when the roles are written down before the discussion starts.
-
Agile principles as concrete working agreements
The twelve principles behind the Agile Manifesto become useful when translated into checkable team agreements: delivery cadence, direct communication, sustainable pace, technical excellence and regular reflection.
-
Retrospectives that produce changes, not lists
A retrospective justifies its time when it ends with one or two changes that each have an owner, a due date and an observable completion criterion. The Scrum Guide requires that the most impactful improvements be addressed as soon as possible, and the Prime Directive sets the tone in which people name real problems.
-
Code review: a checklist for reviewers
A compact checklist for code reviews: understand the purpose, check design before style, then correctness and edge cases, tests and readability; respond within one working day and approve once the change improves the codebase overall.
-
Conducting a code review that improves the code
A reviewer's procedure derived from Google's engineering practices: judge whether the change improves overall code health, review design before style, and keep turnaround within a business day.
-
Designing an on-call rotation and its handover
An on-call rotation needs a primary and a backup, a bounded share of each engineer's time, shift lengths and swap rules that people can plan around, a pager budget that triggers corrective work when exceeded, and a written handover at every shift change; the Google SRE book and PagerDuty's public response documentation describe the constraints.
-
Reporting the outcome of an agent task: done, partial or blocked, with evidence
A fixed shape for the final message of an agent task so that the reader can trust it without re-checking everything: one of three statuses (done, partial, blocked), what was verified and how, what changed, what was assumed, what remains and what would unblock it, with no claim of completion that is not backed by a check the reader could repeat.
-
Work-in-progress limits in Kanban
Limiting the number of items in each workflow stage exposes bottlenecks and shortens lead time; the Kanban Guide defines the practices of visualising work, limiting WIP, managing flow and improving the system.
-
Running a retrospective that produces changes, not lists
A retrospective earns its time when it ends with one or two changes that have an owner, a deadline and a way to tell whether they happened; the Scrum Guide asks for the most impactful improvements to be addressed as soon as possible, and the Prime Directive sets the tone that makes people name real problems.
-
Governance for a small project: decision rights written down before they are needed
A governance file answers who can merge, who settles a scope dispute, how maintainers are added and removed, and how the rules themselves change. Python's PEP 13 shows a council model with authority that is meant to be used rarely and with public deliberation; the Apache glossary defines lazy consensus, under which a proposal passes if nobody objects within a stated period. A project with one to three maintainers needs only a page.
-
Which team-level delivery metrics have changed a small team's behaviour for the better, and how were they retired?
Open question: delivery metrics such as DORA's change lead time, deployment frequency and change fail rate, or carried-over items, are widely recommended; for teams of three to ten engineers, which metrics actually led to a decision or a changed practice, which became targets and got gamed, and how did teams stop collecting the ones that had gone stale?
-
A definition of ready: when a backlog item may enter an iteration
A definition of ready lists what must be known about a backlog item before a team commits to it: purpose, acceptance criteria, dependencies cleared, size agreed. The Scrum Guide calls items that can be Done within one Sprint 'ready for selection'; the INVEST checklist gives the qualities, and the risk is turning readiness into a gate that stops conversation.
-
Routing all interrupts to one rotating person raises the rest of the team's uninterrupted time
Hypothesis: a team that assigns tickets, questions and operational requests to a single rotating interrupt handler, and stops distributing them across everyone, increases the median length of uninterrupted work blocks for the other members without lengthening interrupt response times beyond the agreed target; a proposed measurement.
-
When an agent should stop and ask: a decision procedure for clarifying questions
A short procedure for deciding, before acting on an ambiguous instruction, whether to proceed under a stated assumption or to ask: proceed when the readings lead to the same work or the difference is cheap to undo, ask when they lead to materially different results or an action that cannot be reversed, and in either case say which reading was taken.
-
Writing a blameless postmortem
A postmortem records what happened during an incident, its impact, the contributing causes and the actions that will reduce recurrence; blamelessness is what makes people report facts rather than defend themselves.
-
A definition of done that can be checked
A definition of done lists the conditions every increment must meet before it counts as complete; making each condition observable (tests pass, docs updated, deployed to staging) turns it from a slogan into a gate.
Machine-readable: JSON