A few program manager friends of mine are book-clubbing the book Shape Up by Ryan Singer that describes how Basecamp does development. Before we met, I wanted to round out my observations.
BLUF. Basecamp has a home-grown framework that claims to be unique, but is a variant of Iterative Agile. It shows how one organization may tailor a framework like Scrum or Scaled Agile to meet its business needs without embracing all the tenants.
It's Iterative Agile. Shape Up claims that Basecamp is neither Agile nor Waterfall, which is more reflective of the organic way they developed their method than it being a novel approach. They follow a sort of Iterative Agile model similar to Scaled Agile. Each iteration or "cycle" comprises six weeks of delivery and two weeks of planning. They call the planning phase "cooldown" as the focus is similar to SAFe's approach of cleaning the desk and planning for the next iteration. The key distinction is that Basecamp does not use sprints or stories per se--but they do.
Features & Projects & Bets, Oh My! Basecamp's planning process involves what they call a Bet or Project, whether it is in the planning or committed phase (respectively). This is akin to SAFe's Feature, which is a newsworthy deliverable that is rigidly timeboxed in the Iteration. A Bet goes through proposal stage where it is given fairly rigid, defined design constraints, then a Tech Review stage where the Bet is technically evaluated/tweaked to ensure it is feasible and can be delivered in six weeks. The Proposal and Tech Review correspond to SAFe's Feature Funnel and Analysis stages.
Feature Selection. During the Cooldown/Planning sprint (2 weeks), all Bets are stakeholder evaluated in a 1-2 hour session they call a "Betting Table." When approved, bets are converted to projects and implemented over the next six weeks. When rejected, they are cancelled and might be resurrected later with strong advocacy. Compared to SAFE, the Stakeholders move the Feature from Backlog (where it sits after Analysis) to Implementation. Thus by the end of each Planning phase there are zero features / bets in the Backlog. Their stakeholders (CEO, CTO, lead product manager, lead developer) are tuned to their velocity since they are a 100% creative shop.
Pitching and Announcements. Each Bet/Feature has a multi-page pitch comprising the Problem, Appetite (how much time), Solution (a design rougher than a wireframe but defined enough to comprehend the end-state), Rabbit Holes (areas agreed to avoid), and no-goes (scope constraints). When a Bet's pitch is accepted, they write up an internal announcement that gives the team the strategic vision for the iteration. Then the teams select projects and go to work...
Despite their protest, they have Stories. I mentioned earlier Basecamp claims not to have use stories. Their Bet / Projects are Features, which they decompose into "Scopes," which look and smell like stories in most aspects. The distinction is a Scope is not time-boxed to a Sprint. Scopes are defined by the team and are focused on incremental delivery of shippable value. You know, a story. They have a feature on their platform that allows at-a-glance status of these scopes that allows for the regular intervention if things are not going well.
Circuit Breaker. What if a project (feature) does not deliver? They focus on the highest-value scopes first, so anything not delivered is cut, but quality is still delivered. Then they decide whether to ship the finished project or not. If they don't, then they scrap it, avoiding the Sunk Cost Fallacy.
Feedback and Bugs. They do not treat bugs with any significant distinction. They are addressed either during the developer's cooldown (planning) phase or at a once-annual "bug smash" iteration where six weeks focus on paying off the technical debt accrued. If the bug is significant enough, then it is pitched as a bet and if approved becomes a project to be worked at during a cycle.
The balance of the book focuses on how to do all of this in Basecamp, making the book a bit of a pitch to get you to use Basecamp's product. It also talks about how to adopt.
BLUF. Basecamp has a home-grown framework that claims to be unique, but is a variant of Iterative Agile. It shows how one organization may tailor a framework like Scrum or Scaled Agile to meet its business needs without embracing all the tenants.
It's Iterative Agile. Shape Up claims that Basecamp is neither Agile nor Waterfall, which is more reflective of the organic way they developed their method than it being a novel approach. They follow a sort of Iterative Agile model similar to Scaled Agile. Each iteration or "cycle" comprises six weeks of delivery and two weeks of planning. They call the planning phase "cooldown" as the focus is similar to SAFe's approach of cleaning the desk and planning for the next iteration. The key distinction is that Basecamp does not use sprints or stories per se--but they do.
Features & Projects & Bets, Oh My! Basecamp's planning process involves what they call a Bet or Project, whether it is in the planning or committed phase (respectively). This is akin to SAFe's Feature, which is a newsworthy deliverable that is rigidly timeboxed in the Iteration. A Bet goes through proposal stage where it is given fairly rigid, defined design constraints, then a Tech Review stage where the Bet is technically evaluated/tweaked to ensure it is feasible and can be delivered in six weeks. The Proposal and Tech Review correspond to SAFe's Feature Funnel and Analysis stages.
Feature Selection. During the Cooldown/Planning sprint (2 weeks), all Bets are stakeholder evaluated in a 1-2 hour session they call a "Betting Table." When approved, bets are converted to projects and implemented over the next six weeks. When rejected, they are cancelled and might be resurrected later with strong advocacy. Compared to SAFE, the Stakeholders move the Feature from Backlog (where it sits after Analysis) to Implementation. Thus by the end of each Planning phase there are zero features / bets in the Backlog. Their stakeholders (CEO, CTO, lead product manager, lead developer) are tuned to their velocity since they are a 100% creative shop.
Pitching and Announcements. Each Bet/Feature has a multi-page pitch comprising the Problem, Appetite (how much time), Solution (a design rougher than a wireframe but defined enough to comprehend the end-state), Rabbit Holes (areas agreed to avoid), and no-goes (scope constraints). When a Bet's pitch is accepted, they write up an internal announcement that gives the team the strategic vision for the iteration. Then the teams select projects and go to work...
Despite their protest, they have Stories. I mentioned earlier Basecamp claims not to have use stories. Their Bet / Projects are Features, which they decompose into "Scopes," which look and smell like stories in most aspects. The distinction is a Scope is not time-boxed to a Sprint. Scopes are defined by the team and are focused on incremental delivery of shippable value. You know, a story. They have a feature on their platform that allows at-a-glance status of these scopes that allows for the regular intervention if things are not going well.
Circuit Breaker. What if a project (feature) does not deliver? They focus on the highest-value scopes first, so anything not delivered is cut, but quality is still delivered. Then they decide whether to ship the finished project or not. If they don't, then they scrap it, avoiding the Sunk Cost Fallacy.
Feedback and Bugs. They do not treat bugs with any significant distinction. They are addressed either during the developer's cooldown (planning) phase or at a once-annual "bug smash" iteration where six weeks focus on paying off the technical debt accrued. If the bug is significant enough, then it is pitched as a bet and if approved becomes a project to be worked at during a cycle.
The balance of the book focuses on how to do all of this in Basecamp, making the book a bit of a pitch to get you to use Basecamp's product. It also talks about how to adopt.
--
Ben
In tenebris solus sto