We’re planning to improve Teams functionality in Clubhouse, making them fully first-class citizens. We think that software Teams do their best work in Clubhouse, and so getting Teams on the right track is critical for the future. Read on to see our vision of Teams, how we plan on getting there (including what’s next), and how you can join us on the journey, impacting Clubhouse along the way.
A "Team" can mean something different depending on organizational scale and complexity. For example, we see companies split into Teams by their functional department (e.g. Engineering, Product, Marketing, CX); by role (e.g. Frontend, Backend, DevOps, Product Design, Visual Design); and by cross-functional teams or squads (which are often related to company-specific initiatives or objectives). And that's not even getting into companies with multiple products, brands, or business units.
We think Teams (and especially small teams) are the secret sauce in companies that ship software in order to advance their businesses. In a small team, communication overhead is minimized and collaboration is maximized. And so if properly empowered, Teams can make quick business decisions and execute on them, ultimately delivering value to satisfy the ever-increasing demands of customers in fast-moving industries. What "small" means really depends on your particular organization and culture. So as your organization grows and your culture evolves, find out the optimum Team size. You may find yourself needing to split up Teams to work on more focused areas to remain nimble and flexible. Teams are critical in modern companies and to Clubhouse users. And so we are focused on advancing Teams functionality in Clubhouse.
We think Teams work best when folks are openly sharing information, maximizing the opportunities for focused collaboration. To that end, Teams in Clubhouse will not become artificially erected digital silos. Instead, they will be structured spaces that foster the exchange of ideas. People will be able to create, see, join, and leave Teams as they see fit. Most folks will join multiple Teams and collaborate across them regularly. Teams will not be overly restrictive or otherwise onerous to maintain.
Since Teams are optimized for driving forward businesses, we think they are ultimately responsible for the work itself. Practically speaking, this means we think Teams should be the owner of collections of work: Epics and Iterations.
A Clubhouse Epic is a collection of stories that make up a larger initiative, that typically meets a business objective. And so it follows that a Team should very much own an Epic and drive it to completion. We plan to allow Epics to be owned by a future Team concept in Clubhouse.
Many software Teams work in short time-boxed periods called Iterations (or sometimes sprints), allowing them to focus on deliverables agreed upon with business stakeholders, but still being responsive to changing customer demands between Iterations. Teams usually have their own unique Iteration needs. (Two weeks or a month? Start on Mondays or Fridays? When to plan and retro?) And so we plan to allow each Clubhouse Iteration to be associated with a Team to support those needs.
Work, as scoped in Epics, is planned in Iterations and executed over time. People will be able to see that work using existing views throughout Clubhouse, filtered to the Teams they care about. In particular, since Clubhouse knows which Teams you belong to, it will automatically show relevant work to you by default. But you will still be able to see work owned by other Teams, again in the spirit of open collaboration.
Clubhouse workflows are a powerful mechanism to guide work through a standardized process. Different types of work have different Workflow needs. For example, updating a native mobile app may require an app store review step, but updating a web app does not. In Clubhouse, you would have a mobile Workflow and have a separate web Workflow to support these two scenarios. In other words, we think that Workflows are best associated with the work collections themselves. In Clubhouse, these are Projects.
We think that Teams should not be coupled to Workflows, since a given Team could be working on multiple different things, even at the same time. So it really depends on the work itself (in Clubhouse that’s a Story) that determines the Workflow that should drive that work to completion. Taking the example above, a single Team could be working on shipping a common feature across both their web and mobile channels. This one feature should then be scoped to at least two Clubhouse Stories. One Story would go through the web Workflow, while the other would go through the mobile Workflow.
Currently in Clubhouse, the existing concept of Teams is tightly coupled with Workflows, but Teams don’t actually have a Teams membership functionality. In fact, Teams in Clubhouse today are actually extraneous, and many users have expressed confusion over Teams and Workflows. So our very first step going forward is simplifying these existing concepts. We plan to merge Teams into Workflows, essentially eliminating Teams as they stand. (Thus, there won’t be any coupling of Teams and Workflows in this interim period, since Teams simply won’t exist.) For example, if you have a Team that’s called “Engineering" now, it will simply be the name of a Workflow in your Workspace after we make this change. Projects previously in that Team will now be part of the “Engineering” Workflow. No functionality in your day to day usage of Clubhouse will be affected. “Team” will be renamed “Workflow” throughout the main Clubhouse UI. And the Settings screens associated with Teams and Workflows will be simplified accordingly.
Afterward, we plan to introduce a new first-class concept of Teams that is totally separate from Workflows, per our vision above. It will include Team membership functionality. We're considering how best to associate Teams with other entities in the product, like Iterations, Projects, Epics, and Milestones. These ideas will likely evolve over time.