In the first two posts in this series, we explored how to identify the product and how to identify the Product Owner. If you missed these tips, check them out HERE.
Now let’s say you have effectively identified both the Product and the Product Owner. How do you identify the Development Team? Or in the case of BIG products, which this series is focused on, how do you identify multiple Development Teams?
Regardless of the development type - Product Development, Internal Product Development or Project Development - with Scrum, the Development Team characteristics as described in the Scrum Guide remain the same:
Are self-organizing. No one (not even the Scrum Master) tells the Development Team hot to turn a Product Backlog into increments of potentially releasable functionality
Are cross-functional, with all the skills as a team necessary to create a product increment
Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis
Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole
If Identifying Product was Skipped:
Scrum adoptions are rarely effective if identifying the Product was skipped and what is happening is an attempt to make Scrum fit into existing structure or the status quo. Scrum is about changing the status quo. It potentially requires structure change in order to effectively optimize for delivery of working product.
As an example, if the structure of the organization has people segregated by specialized, singular activities such as analysis, building, testing, architecture, etc. those are component teams. The component team structure not only requires hand offs, late integration which increases risk, it structurally does not enable delivery of value to the customer the way a cross-functional feature team can. If the organization is still using project management with component teams, it’s rare that any members of component teams are 100% dedicated to one project. Typically, people are assigned to multiple projects to execute the one, specialized skill so that instead, they appear to be 100% “utilized”. This divides their attention, is less productive due to context-switching between projects and is a cost drain.
Like Scrum, Large Scale Scrum or LeSS, requires the teams to be cross-functional possessing all of the necessary skills to deliver a customer-centric feature or features in any given sprint (analysis, programming, testing, database work, etc.). Team members are 100% dedicated so there is focus on value and no loss of productivity due to time-slicing. Although people may initially have a special skill, Scrum and LeSS teams are multi-learning teams. People are willing to learn other skills and work together to deliver value. An illustration from https://less.works/ comparing component teams to feature teams:
Because there’s always new features, maintenance or items that come back to the team via feedback loops, these teams are also long-lived. Customer centric features from the Product Backlog are broken down into items on the Sprint Backlog that the cross-functional, self-organizing feature team delivers in a sprint. Identifying Product at the beginning of the adoption makes it pretty simple to identify all of the skills that will be needed in order to achieve this. Each of these feature teams is made up of a minimum of 3 people with a maximum of 9 people per team.
How many cross functional feature teams are needed may be determined based on the needs of the Product itself or budget. In a LeSS adoption, the upper limit for the number of teams is 8. In really BIG product scenarios, LeSS Huge may be adopted which involved more than 8 teams. For more information on LeSS Huge teams please visit: https://less.works/
To learn more from Large Scale Scrum (LeSS) co-creator, Craig Larman, and to earn a Certified LeSS Practitioner credential register HERE.
