Compendium / Development Process
A Common Contract for Teams
In evolving toward greater agility, we must strike a balance between uniformity across teams and allowing flexibility for process tailored to unique team contexts.
As your organization grows from 2 to 10 to 50 teams, you have to be able to coalesce their delivery queues into an overall picture of what is being developed. However, if you push for too much uniformity, the process is no longer effective for all the types of work that go into developing your product, often to the detriment of quality and timely delivery.
Seeking that balance, I asked myself years ago what is the minimal commonality needed across teams. Coming from a (mostly back-end Java) programming background, I was inclined to express this in terms of an API. I call it The API for Teams.
Each team in the organization must implement the following four methods in the API for Teams:
Team.getBacklog()
Team.getThroughput()
Team.getRoadmap()
Team.getStakeholderMap()The spirit of the API is to arrive at an agreed-upon minimum level of commonality to orchestrate product development across teams without imposing artificial, counterproductive homogeneity.
Team.getBacklog()
The intent of getBacklog() is to provide visibility into the team’s queue of schedulable work. I advise teams to strive for a minimum of 3 cycles of work in the queue, but to work toward an eventual queue length of about 6 cycles.
Items in the upper half of the queue should skew toward the smaller range of sizes, while the lower half should lean toward the larger range. This is especially true as backlogs begin to build out beyond the 3-cycle length. Resist the urge to be overly granular further than 3 cycles out.
Team.getThroughput()
From getThroughput() we expect to receive the current rate of schedulable work completion per cycle, given in the same unit of measurement used to size the items provided in getBacklog(). This is what allows us to have conversations about when outcomes in the queue are currently positioned to deliver. The farther down the queue a given outcome sits, the more directional and less precise the projected delivery will be.
Team.getRoadmap()
The response of getRoadmap() should be a visualization of the big-picture, longer-term landscape of schedulable work. At the team level, I generally advise projecting two calendar quarters. That said, getting to a single quarter is a great first milestone that can take teams quite some time depending upon their individual context.
It is not uncommon for teams with 6-12 months of experience producing roadmaps to publish 4-quarter roadmaps. Continue to evaluate the effectiveness of those third and fourth quarters based upon your specific context. If few things that far out make it to execution, you may be projecting farther than is valuable at the team level.
Team.getStakeholderMap()
I added getStakeholderMap() to the API for Teams after a couple years based upon my work with numerous teams in various settings. The response of getStakeholderMap() explicitly identifies who has input into the content and priority of the team’s backlog and roadmap.
Why do we need this?
In this context, a stakeholder is someone with a say as to what goes into a team’s backlog and in what order that work should be prioritized. Note that having opinions and feelings about what is in a team’s backlog or roadmap does not constitute being a stakeholder. Others can give us feedback, but the stakeholders help us decide.
When driving stakeholder alignment on the priorities of your backlog, having a clear understanding of who should (and should not) be in those discussions can reduce loads of friction, overhead, and churn for the team.
Conclusion
When any team in your organization can provide visibility into their work queue, the rate at which work moves through that queue, what the bigger picture looks like farther out, and who is involved in prioritization and intake discussions, leadership should have what it needs to steer the organization, while allowing teams to self-organize and deliver in ways best suited to the nature of their work.