What if the process should follow the change — not the other way around?
Ship It!
Ship It! is a lightweight software delivery framework for teams that already have a process.
Not every software change needs the same delivery process.
Ship It! helps you decide what each change needs before it ships, without replacing the practices that already work.
Delivery processes often describe everything around a change: planning, coordination, review, validation, and release. Those practices can be useful. The question is which of them this change needs before it ships.
Not every software change needs every step your process describes.
Most software delivery frameworks add concepts. Ship It! removes them.
Software changes are becoming smaller, more frequent and increasingly AI-assisted. Teams can produce changes faster than many delivery processes were designed to handle. AI can make changes faster. It doesn't make unnecessary steps necessary.
Ship It! describes the minimum workflow required to move a software change from Input to Ship, using four concepts: Input, Development, Validation, and Ship.
A familiar delivery story
The dependency update was Pino 9.13.0 to 9.13.1. We changed a version, ran the existing checks, and made no application-code changes. It entered the team's usual delivery path.
The team stopped and asked: what does this particular change need before it ships?
The existing checks provided enough evidence to give the team confidence that the change was ready to ship. Additional review and approval steps did not meaningfully contribute to what this change needed, so the team skipped them for this change.
Those steps remained part of the process for changes that needed them. This was a decision about this update, not a general rule for dependency updates.
The question is whether a step contributes to what this particular change needs before it ships.
What changes in practice?
Start with the change. Develop the solution. Validate it. Ship when relevant evidence provides enough confidence that it is ready.
Use existing practices where they contribute to what this change needs. Omit steps that do not contribute, and add practices that provide evidence the existing process does not.
A change's size alone does not determine what it needs before it ships. The four concepts remain the same; the practices depend on the particular change and its context.
Does this replace our process?
No.
Teams can keep Scrum, Kanban, continuous delivery, pull requests, automated testing, release management, and their own delivery practices. Ship It! is not another comprehensive process layered on top of them.
It describes the shared workflow underneath them: the work required for this change to become shippable. The question is not which process to replace, but what this change actually needs to reach production with appropriate validation.
Start with the change. Decide what it needs before it ships.
Keep your process. Improve your delivery decisions.