A development team is an autonomous body that owns figuring out how to achieve their objectives. Continuous reduction to what matters most, rather than expansion, is their responsibility.
Responsibility for our software is divided into domains. A domain incorporates the entirety of a system, or systems, and wherever possible it is decoupled from other domains so that it can be independently maintained.
Every domain is owned by one team, and one team only, and they have defined the standards (language, environment, tools and framework) for the domain. Domain ownership is optimized to ensure that every team has the skills and the capacity to continuously maintain and improve their domains.
Rituals & Cadence
Full credit to basecamp and their shapeup methodology. We have borrowed most of it.
We work in 6 week sprints followed by 2 week cool downs. We prefer to ship continuously during a sprint in small iterations delivering what is hard first, then by order of value to our customer. We don’t wait until the end of a sprint to release in one big dump. Too risky.
What could be built during a sprint is defined by a pitch and anyone in the company can create and propose one. As a rule we prefer that the appetite for a pitch is never greater than the duration of a sprint - 6 weeks.
All pitches to be considered for a sprint are collated by the product strategist and delivered to the product council 2 weeks before a cool down begins.
1 week before the cool down the product council meets to review the pitches and decide what will be built, and by which teams, in the next sprint. If a team is being asked to complete more than 1 pitch, assuming the combined appetite is 6 weeks or less, the product strategist will recommend the order in which they are to be delivered based upon shipping the highest value to the customer first.
During a cool down a team completes the following;
- validate their last sprint
- confirm all open defects can be closed in the cool down, and if not they present a pitch for the next sprint, including a Success From Failure analysis, for what can’t be closed
- attend the kick off meeting for their pitch(es) with the development manager and product strategist
- negotiate and confirm with the product council what pitches they will be taking on next sprint
- update and confirm system documentation meets our documentation standards
- confirm standards for their domain are defined and current
- confirm all repositories are private and that they have an issue template in accordance with our defect template
- close any requests to delete personal data that are applicable to your domain
- reviews their domain for 3rd party deprecations and service changes, development principles adherence, refactoring for maintainability, reliance, cost reduction or performance, and reconcile / update their technical debt lanes
- prepare pitch(es) for any technical debt lane resolutions due within the next 4 months, or within the next 6 months if the debt requires more time to resolve than 1 sprint affords
- completes their scorecard reviews if due
- close all open defects that are expected to be closed within the cool down
- take part in a tech share & learn
- participate in a hackathon every second cool down
At the start of the sprint the team breaks down the must haves into scopes described in the sprint plan. Scopes are right if the scope name is unique to the sprint, each scope can be closed within a few days, and all of them, together, describe everything that must be released to deliver all of the must haves. Scopes are prioritized and delivered in order of what is hard (new technology, cross team dependency, possible gotchas...) and then by what matters to the customer as defined by the rank order of the must haves within the pitch.
Each scope is further broken down into the tasks that must be completed in order to ship the scope.
The sprint is managed on a trello card on the metascrum board. It has a problem to be solved and the measure of success in the description, the team lead is the owner, it has a start and due date, and a checklist of all of the scopes to be delivered by week. Each item in the checklist has a corresponding date.
The scopes are managed on the team trello board, not the metascrum board, for the sprint in progress. Each scope card includes a description of what is to be delivered, it has a start and due date, and a checklist of all tasks to be completed to ship the scope.
Once a sprint has begun the team confirms daily if they are on, behind, or ahead of schedule, and if behind or ahead, they estimate by how many days. They report their status daily at scrum of scrums, and weekly on their respective scoreboards. If behind schedule and the team doesn’t feel they can catch up then they must scope negotiate with the product strategist what they are taking out well in advance of the expected pitch delivery date. They must ask; What must be delivered? What can be shipped without what? What happens if we don’t do this? Is the cost of the must have too expensive for the budget afforded? Does it matter to our target customer? If scopes are reduced all conclusions from those negotiations are noted on the metascrum trello card and the deliverables in the checklist on the trello card that are no longer being done are preceded with the words “Scoped Out; “ and moved to the bottom of the list.
Whatever the team proactively (at least halfway through the sprint) scopes out is not counted within the on schedule calculation. For example, if a sprint has 6 scopes to be delivered, 1 per week, over 6 weeks, and by the end of week 3 they have only shipped 2 scopes, and they proactively negotiate out the last 2 to be delivered, as of the close of week 3 they are ahead of schedule (assuming the original scope estimates for the last 2 items hasn’t changed, they have 4 weeks left to deliver 2 scopes that at the start were estimated to take 1 week each). However, if they aren’t proactively planning and eliminating the hard stuff up front and they find in week 4, or later, that they have to eliminate something, then that miss continues to be counted in the days behind on schedule reporting.
Development teams do not use burn downs or sprint lanes, and there is no requirement to track velocity. However, a team can optionally choose to use points to break down task complexity and use their shipping velocity to estimate what volume of points they can typically deliver. But that is up to each team to determine and there is no requirement to publish those results should they use this option.
During the sprint the only time we interrupt a team is during their office half hour from 9am to 9:30am EST or we have an escalated issue. If somebody or something messes with our no interruption policy we log it and dissect what happened every week.