... coming out of The Mist, the Product Owner has a Product Vision whose realization is beyond the reach of any individual. The Product Owner is either working alone at the forefront of a new venture, or is working in the company of people who are impassioned by the same vision. The fledgling effort might have formed in The Mist and needs to come together. The effort is at a point of taking steps to turn the vision into a reality, both by coordinating the work of the longstanding members of the group and potentially by involving new people. Together they seek a way to balance their collective identity with individual development responsibilities: to connect to each other under a framework that manages time and talent to support the business and create a rewarding workplace.
✥ ✥ ✥
Many great endeavors cannot achieve excellence through individual effort alone, and the greatest power in production comes from teamwork. Great individuals can also produce great products, but starting with a single individual makes it difficult to scale later: each new person detracts from the effectiveness of everyone else on the team by about 25% for about 6 months. Some products simply cannot realize greatness at the hands of a single individual; it's too easy to become blindsided in a feedback vacuum. Experience shows that person-for-person, teams outperform individuals: Many hands make light work. While industry data tend to suggest a range of 10-to-1 in individual programmer output1, Jeff Sutherland reports that an IBM study showed that some teams outperformed others by a factor of 2000-to-1.2
On the other hand, it's difficult to form a consensus direction across an overly large group, and too many cooks spoil the broth. A development department of handfuls of people can eventually achieve consensus but usually can do so only with long mutual deliberation and socialization. Such delay is intolerable in a responsive business.
In the lean startup model, everybody does everything, whether related to business, process or production. The problem is that market shearing layers (different segments of the market whose needs evolve at different rates) and rates of change can be different than those of development. Market analysis and planning can play out over months, while development for the market typically follows a monthly rhythm (Follow the Moon) and can be as short as a day, or even hours or minutes, for field site emergencies. So putting both of these functions in one tightly coupled organizational unit puts stress on the people and on schedules. Such a model is not sustainable as the enterprise grows.
History, experience, and inclination will draw individuals to particular areas of focus (e.g., eliciting needs from the market as opposed to production), but too much specialization (e.g., to want to be in production without wanting to deal with other development tasks like documentation or testing) can lead to expertise starvation as development needs vary from delivery to delivery. Role differentiation should primarily follow from variations in the long-term rhythms of those roles' primary activity. For example, one set of roles may deal with the market on a release cadence while another set of roles may deal with day-to-day production issues.
Building on Stable Teams, create a Development Team that rallies around a product inspired by the Product Owner's vision, to deliver successive increments of that product to its end users. The team is a bonding of five collocated individuals, more or less — a Small Team — committed to working with each other towards a common goal.
The team is autonomous: self-selected, self-organizing, and self-managing. Give the individuals a collective identity to realize the Product Owner's vision. The Product Owner can tell them: "This is your product: do it."
✥ ✥ ✥
The individuals forge a new identity tied to the product vision while honoring each others' identity within the new organizational unit. It's not about scaling individual potential to raise productivity to some production level, but about a changing the paradigm of development to that of a collective mind, of a whole that can achieve more than the sum of the individuals.
You can build the team either top-down or bottom-up, but in either case you need a vision to seed the team. In the top-down approach, the Product Owner hires the team after securing funding for the effort. The bottom-up approach arises from a setting similar to that of a lean startup: We are a bunch of five nerds and we struggle to respond to the market and we want to be identified as the development team. Who do we respond to? The PO. How do we work? From the top of the Product Backlog. The Team can further evolve according to the Scrum framework with the introduction of additional patterns; see below.
If you don't yet have a stable candidate team in place, then strongly consider building a Self-Selecting Team from available personnel, from scratch, and / or from the market. Look for a Community of Trust as a seed: if the trust doesn't yet exist in the current set of individuals, it will be the first thing the group will need to take care of.
Team members are generically called Developers to avoid any labeling or compartmentalization that might violate the not-separateness of the whole. The team minimizes specialization and has no internal sub-teams but rather has undifferentiated membership. As early as possible strive to build a Cross-Functional Team that has the skill set and talent, or the appetite to develop the skills and talents, necessary to building a succession of complete product increments that are Done.
Though Scrum tradition recommends team sizes of seven plus or minus two, research3 has shown that most effective teams tend to be smaller, with a membership closer to five. Some experience indicates that the best Scrum teams comprise three developers.
Small efforts sometimes arise to meet isolated, short-term business needs. In such cases it might be overkill to build a team; consider Solo Virtuoso
As mentioned above, the team can differentiate itself as a Scrum Team with additional patterns. The team's work can be guided by a Product Backlog to produce Regular Product Increments in time-boxed development intervals called Sprints. Team members create their own work plan for each Sprint and manage themselves during the production part of a Sprint. During the production part of a Sprint, protect the Development Team so its members can work as an Autonomous Team and manage their work as a Self-Organizing Team. Such protection, as well as encouragement, support, and process guidance, are provided by the Product Owner and a ScrumMaster.
1 McConnell, "What does 10X mean?" In Making Software, Oram and Wilson, eds., O'Reilly, 2011.
2 Sutherland, "Scrum: The Art of Doing Twice the Work in Half the Time." Crown Business, New York, 2014, p. 42. Based on work by Lawrence H. Putnam and Ware Meyers in Five Core Metrics, Dorset, 2003.
3 Coplien and Harrison, "Organizational Patterns of Agile Software Development", Section 4.2.2, "Piecemeal Growth Pattern Language", Size the Organization. Pearson, 2004.