These are some insights I’ve gathered from the “Shaping Up” methodology, which is neither Scrum nor dependent on Kanban boards.
In the realm of software development, there’s a substantial element of the unknown, given that what we’re building hasn’t existed before. Waiting six months to realize we’re on the wrong path is excessively long, while a two-week span is typically too brief to produce anything substantial.
The solution lies in defining smaller projects that are actionable and testable. A period of six weeks is sufficient to both complete and deliver a project and short enough to allow for directional changes should they be necessary.
Instead of attaching a time estimate to a technical task, we should ask ourselves how much time we actually want to spend on this project. Consider the analogy of setting a budget before choosing a restaurant for dinner; it’s a strategic approach that takes into account the value, urgency, and business context.
We should strive for an agreement between product teams and technical staff to ensure the time is fixed and the scope is adaptable.
“Shaping” considers two major questions about scope: “What is included?” and “What is excluded?” It also addresses the detail required upfront versus what can be delegated to the team to resolve later. “Latitude” refers to the level of freedom or specificity given to the team.
A key part of shaping is the willingness to abandon features that are either technically impractical or not critical to the user interface.
Teams, consisting of two to three members, collaborate within a six-week cycle to deliver the complete project, not merely pieces of it. These teams maintain their focus without being burdened by unrelated tasks and are self-managed, operating at their own pace.
Work is distinguished as either planned (strategic) or unplanned (reactive).