Category Archives: Large Teams

How Large Are Agile Teams in Practice?

The contrite answer is that they’re as large as they need to be, and the contrite agile answer is that they’re as small as they can be.  Now that we’ve gotten the contrite answers out of the way, how large are agile teams in practice?

In November of 2016 we ran the 2016 Agility at Scale survey.  It was targeted at people who were currently working on agile teams, or who had recently worked on agile teams, and we asked them straightforward questions around the size of the team, how distributed it was, what complexities they faced, an so on.  The following graph summarizes the responses around team size.

Agile team size

This year’s survey found that roughly half (48%) of agile teams are more than 10 people in size and one-quarter are more than 20 people in size.  These findings are similar to what we’ve found in the past with both the 2012 Agility at Scale survey and the 2009 Agility at Scale survey.

In short, don’t let anyone tell you that you can’t do agile with a large team because others are clearly doing so in practice.  Yes, large team agile is different than small team agile, which is one of the reasons why you need to take a pragmatic, context-sensitive approach to agile solution delivery.  The Disciplined Agile framework provides the foundation from which to scale your approach to solution delivery to address a range of scaling factors, including team size.  In fact, you may find our article around large agile teams to be of interest.

Related Posts:

 

Disciplined Agile Program Management: Internal Workflow

In this blog posting, the latest in our ongoing disciplined agile program management series, overviews the workflow internal to program management.

Workflow Within a Program

The workflow within a disciplined agile program is depicted in the following diagram.

Disciplined Agile Program Management - Internal workflow

As you can see in the workflow diagram, someone in the role of Program Manager coordinates the three leadership teams (described in greater detail in Large Agile Teams):

  1. Product Delivery Team.  This team is responsible for dealing with cross-team “management issues” such as moving people between teams, resolving disputes that cross team boundaries, and any coordination issue that doesn’t fall under the purview of the other two leadership teams.  The Program Manager often leads the Product Delivery team, which is made up of the Team Leads from the delivery sub-teams, and may even be a Team Lead of one of the delivery teams as well.
  2. Product Owner Team.  This team is responsible for requirements management, prioritizing the work, and assigning work items to the various sub-teams. This team is led by a Chief Product Owner (CPO), not shown, who is often a Product Owner for one more more sub-teams.
  3. Architecture Owner Team. The AO team is responsible for facilitating the overall architectural direction of the program, for evolving that vision over time, and for negotiating technical dependencies within the architecture.  This team is led by a Chief Architecture Owner (CAO), also not shown, who is often an Architecture Owner on one or more delivery sub-teams.

An important difference between the Disciplined Agile approach and SAFe is that the delivery sub-teams may be following different lifecycles.  The Disciplined Agile Delivery (DAD) framework supports several delivery lifecycles, including the Scrum-based agile/basic lifecycle, the Kanban-based lean lifecycle, a continuous delivery lifecycle, and the Lean Startup-based exploratory lifecycle.  Even when the sub teams are following the same lifecycle they may be working to different cadences (or not) – in the Program Management goal diagram we explicitly show that there are several strategies for sub team cadences.

The workflow diagram also shows that some programs may include a parallel independent testing effort in addition to the whole team testing efforts of the sub-teams.  The delivery sub-teams will make their working builds available to the testers on a regular basis, who will integrate all of the builds into their testing environment.  This independent testing effort often addresses end-to-end system integration testing as well as other forms of testing that make better economic sense when done in a centralized manner.  Independent testing is common for large programs that are tackling complex domains or complex technologies or that find themselves in a regulatory environment that requires independent testing.  The SAFe equivalent to a parallel independent test team would be called a system team, in this case one doing system integration plus independent testing.  Same basic concept, slightly different wording.

 

Related Postings

Why Do We Need Agile Programs?

Why?

An IT program is a large IT delivery team composed of two or more sub-teams.  The purpose of program management is to coordinate the efforts of the sub-teams to ensure they work together effectively towards the common goal of producing a consumable solution for their stakeholders.  In this blog posting we examine some of the reasons why large IT delivery teams are formed and strategies to reduce or even eliminate the need for such teams.

There are several reasons why large IT delivery teams exist in the first place:

  1. Some endeavours are inherently big. Sometimes an organization will decide to take on a complex effort, such as developing an operating system, an air traffic control system, a financial transaction process system at a bank, and many other examples.
  2. Overly-specialized staff promote larger teams.  When IT staff are narrowly focused it requires many people to work, at least part time, on a team so that the team has sufficient skills to get the job done.  When people are generalizing specialists your teams become much smaller and collaborative.
  3. Overly bureaucratic processes promote larger teams.  Sometimes the systemic bureacracy in the organization requires large numbers of people to address that bureaucracy.  I once assessed a eighty-person project team who were doing work that only required between ten and fifteen people to do the “real work” and everyone else to conform to the overhead of their traditional CMMI-compliant process.  Sadly they didn’t rework the team and failed to produce anything after three years and many millions of dollars of investment.  As an aside, it is possible to effectively combine CMMI and disciplined agile approaches, but you need to overcome the cultural dissonance of the two paradigms.
  4. Working on large teams can lead to greater rewards.  Similarly, someone is “empire building” and purposefully creates a large team so that they will be rewarded for doing so.  We have worked in two organizations where before their agile transformation the pay grade of a manager was determined by the number of people the person managed.  Worse yet, in one organization the people on the larger teams tended to get better bonuses, and quicker promotions, than people on smaller teams regardless of the actual ability of the team to deliver value to the organization.

In our opinion only the first reason is a valid one for building a large agile team.  The other reasons reflect aspects of organizational cultures that need to be fixed in time.  Luckily, there are several strategies that you can employ to reduce the size of a team:

  1. Reorganize the problem into a collection of smaller problems.  Disaggregation of a large problem is performed through a combination of agile envisioning and agile business analysis. This is a key responsibility of your product management efforts: to feed reasonably-sized portions of work to IT delivery teams.
  2. Reduce the problem.  Sometimes a large problem can be shrunk down through pruning features out of the vision, or at least by deferring them until later.
  3. Address your organization’s culture. As we discussed earlier, most of the reasons that organizations build large IT delivery teams are the result of cultural challenges.  Fix the real problem by adopting agile and lean ways of thinking and working.
  4. Organize the large team into a collection of smaller teams.  In other words, create a program.

When you find yourself in a situation where you need a large IT delivery team, and those situations do exist in many organizations, and you can’t find a way to reduce the size of the team, then you will need to adopt strategies to coordinate that team.  The disciplined agile project management blade describes such strategies.

Related Postings

 

 

Disciplined Agile Program Management: External Workflow

In this blog posting, the latest in our ongoing disciplined agile program management series,  we overview the external workflows that a large delivery team is likely to be involved with.

Workflow With Other IT Teams

The following diagram overviews the major workflows that a disciplined agile program is associated with.  Note that feedback is implied in the diagram.  For example, where you see the Technology Roadmap and Guidance flow from Enterprise Architecture to Program Management there is an implied feedback loop from the program to the enterprise architects.  Also note that the workflows do not necessarily imply that artifacts exist.  For example, the data guidance workflow from Data Management could be a conversation with a data management person, it could be a concise description of data standards, or it could be detailed meta data – or combinations thereof.  A second example would be a program providing their development intelligence to the IT governance team through automated rollup of metric data via your organizations dashboard technology.

Disciplined Agile Program Management

The following table summarizes the workflows depicted in the diagram.

Process Blade Process Blade Overview Workflow with Program Management
Continuous Improvement Addresses how to support process and organizational structure improvement across teams in a lightweight, collaborative manner; how to support improvement experiments within teams; and how to govern process improvement with your IT department. Your continuous improvement efforts should result in improvement suggestions gleaned from other teams that the program can learn from.
Data Management Addresses how to improve data quality, evolve data assets such as master data and test data, and govern data activities within your organization. The data management group will provide data guidance, such as naming conventions and meta data regarding legacy data sources, to all delivery teams.
Enterprise architecture Addresses strategies for collaborative and evolutionary exploration, potential modelling, and support of an organization’s architectural ecosystem in a context-sensitive manner. The enterprise architects will produce a technology roadmap that delivery teams should follow and be a good source of development guidance (such as programming guidelines, user interface conventions, security guidelines, and so on).  Delivery teams will provide development intelligence (metrics) and feedback pertaining to the usage of key architectural components and frameworks to help inform the decisions of the enterprise architects.
IT Delivery Addresses how to develop solutions in a disciplined agile manner.  This includes the four lifecycles – basis/agile, advanced/lean, continuous delivery, and exploratory – supported but the DAD framework plus the program management blade (effectively a large team following one or more of the lifecycles). There will be dependencies,both technical and functional, with other delivery teams (not shown in the diagram).  These dependencies between teams must be negotiated and managed appropriately.
IT Governance Addresses strategies for consolidating various governance views, defining metrics, taking measurements, monitoring and reporting on measurements, developing and capturing guidance, defining roles and responsibilities, sharing knowledge within your organization, managing IT risk, and coordinating the various governance efforts (including EA governance). The IT governance team will provide guidance to all IT teams, including large delivery teams.  This guidance typically focused on financial and quality goals as well as any regulatory constraints where appropriate.  Delivery teams will provide development intelligence to the IT governance team to enable them to monitor your team and provide informed guidance to it.
Operations Addresses how to run systems, evolve the IT infrastructure, manage change within the operational ecosystem, mitigate disasters, and govern IT operations. Your operations group will provide operations intelligence (metrics) to IT delivery teams, in particular around the usage of systems and features that a team is responsible for.  This enables the IT delivery teams to make informed decisions regarding the value of delivered features.
Portfolio Management Addresses how to identify potential business value that could be supported by IT endeavors, explore those potential endeavors to understand them in greater detail, prioritize those potential endeavours, initiate the endeavours, manage vendors, and govern the IT  portfolio. Your organization’s portfolio management activities will provide the initial vision and funding required to initiate a program, as well as ongoing funding for the program.  It will also provide guidance, often around management and governance conventions, to the team.  IT delivery teams will make their development intelligence (metrics) available to the portfolio management team to help inform their decisions.
Product Management Addresses strategies for managing a product, including allocating features to a product, evolving the business vision for a product, managing functional dependencies, and marketing the product line. The Product Management team will provide a business roadmap and stakeholder priorities to all IT delivery teams, including programs.
Release Management Addresses strategies for planning the IT release schedule, coordinating releases of solutions, managing the release infrastructure, supporting delivery teams, and governing the release management efforts. Your program will release solutions into production via your organization’s release management strategy.
Reuse Engineering Addresses how to identify and obtain reusable assets, publish the assets so that they are available to be reused, support delivery teams in reusing the assets, evolving those assets over time, and governing the reuse efforts. All IT delivery teams should reuse existing assets – such as services, frameworks, and legacy data sources – whenever appropriate.
Support Addresses how to adopt an IT support strategy, to escalate incidents, to effectively address the incidents, and govern the IT support effort. Your support/help-desk team will provide change requests, including defect reports, identified by end users to all delivery teams.  These change requests are in effect new requirements.

The activities associated with these process blades are often very highly related. For example, in some organizations the activities associated with enterprise architecture and reuse management are fulfilled by a single group.  In other organizations some product management activities are performed by the portfolio management team and some by the enterprise architecture team.  Some organizations may choose to have a separate group for each process blade.  And of course the organizational structure will evolve over time as your various teams learn how to work with one another.  Every organization is different.

Program Management and DevOps

A common question that we’ve gotten is how program management is affected by DevOps. For example, you see in the diagram that Operations, Support, and Release Management (amongst others) are shown as things that are external to Program Management.  Remember that the focus here is on process, not on team organization.  For example, in organizations with a disciplined DevOps strategy in place it is very common to see program teams taking on the responsibilities of operating and supporting their own systems in production, and of doing the work to release their solutions into production.  In organizations without a strong DevOps mindset (yet), you are likely to find that operations, support, and release management are done by separate groups outside of your program team.  Context counts, and it’s good to have a process framework that is flexible enough to support the situation that you find yourself in.

Related Postings

Disciplined Agile Program Management: A Goal Driven Approach

This posting, the latest in a series focused on a disciplined agile approach to program management, overviews the activities associated with program management. The Disciplined Agile (DA) framework promotes an adaptive, context-sensitive strategy.  The framework does this via its goal-driven approach that indicates the process factors you need to consider, a range of techniques or strategies for you to address each process factor, and the advantages and disadvantages of each technique.  In this blog we present the goal diagram for the Program Management process blade and overview its process factors.

The following process goal diagram overviews the potential activities associated with disciplined agile program management.

Disciplined Agile Program Management

The process factors that you need to consider for program management are:

  1. Allocate work. Work items must be allocated to delivery teams, or to open source efforts in the case of programs which include internal open source components, throughout the lifecycle.  The type of work and the focus of the sub-team are the primary determinants of how work is allocated.  However, team capacity and load balancing concerns, for example a team has run out of work or a team currently has too much work, will also be considered when allocating new work.  Work allocation is the responsibility of your product owners although team capacity planning and monitoring is typically performed by the program manager and team leads.  Regardless, these activities should be performed collaboratively by the available people at the time.
  2. Prioritize work.  The work performed by the teams – including new requirements and fixing defects – needs to be prioritized.  There are several ways to prioritize the work, such as by business value, by risk, by severity (in the case of production defects), or by weighted shortest job first (wsjf) to name a few strategies.  Prioritization is an ongoing activity throughout the lifecycle and is the responsibility of your product owners.
  3. Plan program.  Traditional programs are often planned on an annual or even ad-hoc basis.  Agile programs, at least the disciplined ones. tend to be planning on a rolling wave basis.
  4. Organize teams.  There are three common strategies for how you can organize delivery teams within a program – feature teams, component teams, and internal open source – each of which has advantages and disadvantages.  In addition to delivery teams, in a large program you are likely to find the need for leadership teams – the Product Owner team, the Architecture Owner team, and the Product Delivery/Management team – made up of the product owners, architecture owners, and team leads from the delivery teams respectively.  These leadership teams are responsible for work/requirements coordination, technical coordination, and management coordination within the program respectively.
  5. Coordinate teams.  There are several ways that the sub-teams can coordinate with one another.  For example they could choose to have cross-team coordination meetings (also called a Scrum of Scrums (SoS)); they could visualize the work through task boards, team dashboards, and other information radiators such as a modeling wall; they could choose to have “big room” planning sessions where all team members are involved or “small room” agile modeling sessions where a subset of people are involved; or even traditional (or agile) checkpoint meetings.  All of these strategies have their advantages and disadvantages, and all can be applied by the various types of teams mentioned earlier.
  6. Coordinate schedules.  There are several strategies that a program can adopt to coordinate the schedules between sub teams.  The easiest conceptually, although often hardest to implement in practice, is to have all sub-teams on the same cadence (e.g. every sub-team has a two week iteration).  This is what both SAFe and LeSS prescribe.  Another option is to have multiplier cadences where the schedules of sub-teams align every so often.  For example, we once worked with a large program where some sub-teams had a one-week iteration, some had a two-week iteration, and a few had a four-week iteration.  We’ve also seen another team where sub-teams had one, two, or three week iterations that provided alignment of iteration endings every six weeks.  Most common, although rarely discussed, is for sub-teams to have disparate cadences.  This is guaranteed to occur when teams are following different lifecycles (remember, the DA framework supports several).  For example, when some sub-teams are following the Scrum-based agile/basic lifecycle that has iterations, yet other sub-teams are following the lean or continuous delivery lifecycles that have no iterations, then you have an alignment challenge.  Or if you have sub-teams adopting any iteration length they like (we’ve seen some programs with sub-teams with two, three, four and sometimes even five week iteration lengths) then they also in effect have disparate cadences.
  7. Schedule solution releases.  Programs need to schedule their own releases, in accordance to your organization’s release management strategy, which involves coordination between the sub-teams.  When the cadences of the sub-teams are (reasonably) aligned then it is easier to coordinate production releases.  For example, when all sub-teams have two-week iterations (or at least the sub-teams with iterations do) then they could potentially release into production every two weeks.  In the case of multiplier cadences, there is the potential to release into production each time the iteration endings align.
  8. Negotiate functional dependencies.  An important responsibility of the Product Owner team is to manage the functional dependencies between the work being performed by various sub-teams.  There are strategies to manage dependencies between two agile sub-teams, between an agile sub-team and a lean sub-team, and even between an agile/lean sub-team and a traditional sub-team (this isn’t ideal, but sometimes happens).
  9. Negotiate technical dependencies.  Similarly, an important responsibility of the Architecture Owner team is to work through technical dependencies within the solution being developed by the program.
  10. Govern the program.  The program must be governed, both internally within the program itself while still operating under the aegis of your organization’s overall IT governance strategy.  Program-level metrics, particularly those tracking the progress of sub-teams and the quality being delivered, are vital to successful coordination within the program.  Sub-teams should also be working to common conventions, ideally those of the organization but in some cases specific to the program itself (perhaps your solution is pioneering a new user interface look-and-feel or new data storage conventions).  Programs, because of their size and because they are usually higher risk, often have more rigorous reporting requirements for senior management so as to provide greater transparency to them.  The implication is that a program’s dashboard often has a more robust collection of measures on display.

How Scaling Affects Program Management

Although program management primarily addresses the team size scaling factor, your tailoring decisions will still be affected by the other scaling factors:

  1. Geographic distribution.  Chances are very good that large teams will also be geographically distributed in some way.  There are two flavors of this: Are teams geographically distributed (e.g. in different physical locations) and are people within a team geographically dispersed (e.g. people are working in cubes, on different floors, in different buildings, or from home)?  Both add risk. Coordination within the program becomes more difficult the more distributed the teams are, and more difficult within teams the more distributed the people are.  Distribution hits the leadership (the product owner team, the architecture owner team, and the team lead/product delivery) teams particuarly hard because members should be located with their delivery sub-teams but also need to work regularly with their counterparts located elsewhere.  The implication is that the team may require more sophisticated tooling to enable collaboration and more importantly be prepared to invest in travel regularly to foster better communication between disparate locations.  Furthermore, when your stakeholders are geographically distributed it may require your Product Owners to get support from agile Business Analysts in the various locations to help elicit requirements from them.
  2. Compliance.  Compliance, either regulatory compliance required by law or self-imposed compliance (i.e. CMMI-compliancy), will definitely have an effect on your approach to program management.  In fact, the larger the program the more likely it is to fall under regulatory compliance due to the greater risk involved. Regulatory compliance generally requires greater governance both within the program and outwards facing as well.  Under some regulations your coordination efforts will require proof that they occurred, such as some form of meeting minutes that capture who was involved, the decisions made (if any), and action items taken by people.  Compliancy may also motivate more sophisticated approaches to capturing requirements by your Product Owners and to documenting technical concerns by your Architecture Owners.
  3. Organizational distribution. The larger the team, the more likely you are to involve contractors, consultants, or even to outsource portions of the work.  When external organizations are involved the Program Manager will likely be involved it the contract management effort, which in turn may require assistance by the team leads.
  4. Technical complexity.  The larger the team, the more likely it is that they are taking on greater technical complexity.  Or, another way to look at it, greater complexity often motivates the creation of larger teams to deal with that complexity.  Greater technical complexity will motivate greater attention to architecture and design, thereby motivating more regular collaboration of the Architecture Owners.
  5. Domain complexity.  Similarly, team size and domain complexity tend to go hand-in-hand.  Greater domain complexity will require the Product Owners to work in a more sophisticated manner and may even motivate them to get support from agile Business Analysts (or junior Product Owners as the case may be).

Concluding Thoughts

In some ways “program coordination” is a more accurate term than “program management.”  Unfortunately “program management” is a far more common term within the IT community so we have decided to stick with it.

Our next blog posting in this series will describe the workflow of program management with other key IT activities such as portfolio management, enterprise architecture, and IT delivery teams.

 

Related Postings

Disciplined Agile Program Management 101

Team of Teams

An IT program is a large IT delivery team composed of two or more sub-teams.  The purpose of program management is to coordinate the efforts of the sub-teams to ensure they work together effectively towards the common goal of producing a consumable solution for their stakeholders.  In this blog posting we explore the team structure of a typical large agile program and the type of activities that program management addresses.

Team Structure of a Large Program

We described in detail the team structure of a large agile program in Large Agile Teams.  The key ideas are that a large team is organized as a team of teams and that structures are required to coordinate people, requirement, and technical concerns within the overall program.  Where a “scrum of scrums” may suffice for this coordination on small-to-medium sized programs (say up to five or six sub-teams), it quickly falls apart for larger programs.  As a result large programs will find that they need: a Product Management (or Product Ownership) strategy where the Product Owners coordinate their activities; an Architecture (or Architecture Ownership) strategy where the Architecture Owners coordinate their activities; and a Product Delivery (or Management) strategy where the Team Leads coordinate their activities.  The Program Manager, a specialist role, is responsible for coordinating the overall leadership team.

Large Agile Team Organization

The following structure shows how the Product Owners of each sub-team are also members of the Product Management team for the program.  Similar structures, see Large Agile Teams, will also exist for Product Delivery and Architecture as well.

Agile Product Management Team

 

What Program Management Addresses

There are several important concerns that program management needs to address:

  • Architecture. The sub-teams must have a common architectural strategy that they are working to.  The initial architectural strategy will be identified early and will evolve throughout the lifecycle, requiring the architecture owners on each team to coordinate their efforts.  Although there are several ways to do this, a common strategy is for all of the AOs to hold  a weekly architecture meeting to work through program-level technical issues.   Subsets of the AOs will also hold impromptu meetings during the week to deal with immediate technical issues as needed.
  • Work item management.  The sub-teams work together to develop a consumable solution for their stakeholders.  The implication is that they need mechanisms in place to allot the work between the sub-teams, including development of requirements, change requests, and fixing of defects.  The product owners on each team will need to coordinate their efforts throughout the lifecycle.  Common strategies to do this include the POs holding joint look-ahead modelling sessions (called backlog grooming/refinement sessions in Scrum) with key stakeholders; work coordination sessions where they identify dependencies between requirements and match the work to the sub-teams; and impromptu sessions between a subset of the POs throughout an iteration to work through dependencies between work being performed by different sub-teams.
  • Management coordination between sub-teams.  The sub-teams will need to coordinate “management issues” with one another on a regular basis.  These management issues may include conflict resolution between people on different teams, enabling people to move between teams, financial tracking across teams, and many other concerns.  As a result the teams leads, and any appropriate team members involved with a given issue, will need to meet regularly to address any issues.  A common mechanism for this is for the team leads to hold their own daily coordination meeting after their team’s coordination meeting, a strategy that is often referred to as a “scrum of scrums”.
  • Sub-team cadences.  The Disciplined Agile framework, unlike other agile scaling strategies, does not insist that sub-teams follow the same iteration cadence (or even that sub-teams follow an iteration-based lifecycle).  For example, one sub-team may have a one-week iteration length, five sub teams have a two-week iteration length, and two sub-teams follow DAD’s continuous delivery lifecycle which doesn’t have iterations at all.  Or you may find a program where every sub-team has two-week iterations.  Or a strategy where all teams take a continuous delivery approach.  Each of these strategies make sense in certain situations, but none of them make sense in all situations.  There is no single “best practice“.
  • Release cadence.  There are two fundamental issues here.  First, how often will the overall program release into production?  Will it release monthly?  Quarterly?  Bi-annually?  Something else?  Second, how often will the sub-teams release their work internally to other sub-teams so that it may all be integrated and tested as a whole?  At the end of each iteration?  At the end of each day?  Several times a day?
  • Governance.  The program will be governed.  This governance is both inward facing, the program should govern itself, and be outward facing, the program is part of your organization’s portfolio and therefore will be governed as part of your organizations overall IT governance strategy.

 

Relationship with Other Process Blades

There is clearly overlap with some of the activities in the portfolio management, enterprise architecture, release management, product management, and IT governance process blades.  The issue is one of scope.  Where these process blades address activities across all of IT, the scope of the related activities within program management is the program itself.  For example, where enterprise architecture addresses architectural issues for the entire organization, the architecture activities encompassed by program management relate only to the architecture of the solution being produced by the program.

In future blog postings we will explore how to take a goal-driven approach to program management and what the program management workflow looks like.

 

Related Postings

 

 

 

New Article about Organizing Small, Medium, and Large Agile Teams

largeteam_1

We recently posted a new article in our Agility at Scale series, this time about how to organize Large Agile Teams.  The article covers the following topics:

  • Organizing a small agile team
  • Organizing a single, medium-sized agile team
  • Organizing a medium-sized “team of teams”
  • Organizing a large agile team
  • Supporting large agile teams
    • The Product Management team
    • The Product Owner team
    • The Architecture team
    • The Independent Testing/Integration team
    • Overall strategy for organizing a large agile team
  • How does team size affect the way you work?
  • What other resources exist?

Strategies for Organizing Large Agile Teams

When it comes to organizing large or geographically distributed agile teams many people will tell you that there are two strategies, taking what is called a component team approach or taking a feature team approach.  Many people will tell you to take a feature team approach over a component team approach, but the fact is that both strategies has advantages and disadvantages and neither is right for all situations.  Furthermore, those are the only two strategies as you will soon see, although to be fair they are the most common two.

This article explores the four basic strategies for organizing agile teams.  We compare and contrast these four strategies in Table 1 below, in accordance to the “it depends” philosophy of the Disciplined Agile Delivery (DAD) framework.  Our goal is to make it clear that you have choices when organizing agile teams, and that you should understand the trade-offs that you are making with each choice.  You will also find that you want to combine strategies, and in fact most large agile programs that we’ve seen do in fact do this.  The four strategies are:

  1. Component teams. With this approach each sub-team is responsible for one or more subsystems or modules, something that can be difficult if some of your team works alone from home, to reduce the amount of information sharing and collaboration required between disparate teams.  Because component teams are effectively organized around your architecture you will need to invest sufficient time up front to identify that architecture.
  2. Feature teams. A feature team is responsible for implementing a functional requirement, such as a user story or use case, from end-to-end.  This is often referred to as implementing a vertical slice of the solution.  Sometimes a given feature team will focus on the requirements for a single line of business (LoB), such as brokerage or life insurance within a financial institution, enabling them to gain expertise in that LoB. Other times a feature team will take on requirements specific to a given application or system within your organization.
  3. Functional teams. Some large teams will be organized by development function – there is an architecture team, a development team, a testing team, a deployment team, and so on.  Each team focuses on their specialized function and hands off their work to other functional teams.
  4. Internal open source teams. Sometimes a component or subsystem will be developed via an open source method, even though all of the work is private to your organization.  Developers from other teams voluntarily work on the component to evolve it over time.  When Scott was at IBM he saw this strategy work in practice for several important components reused within several IBM products.  For some detailed thoughts on strategy, read Reuse Through Internal Open Source.

 

Table 1. Comparing the team organization approaches.

Team Approach Advantages Disadvantages Considerations
Component
  • Reduces communication between sub-teams
  • Enables teams to build technical expertise specific to their component(s)
  • Requires a loosely coupled, highly cohesive architecture
  • Functional dependency management can be complex
  • Requirements need to be aggregated by component
  • Use for components or subsystems that are highly cohesive and loosely coupled
  • Use for technical-oriented components, such as a security framework or database encapsulation services, which require technical expertise
Feature
  • Enables teams to focus on a subset of the business
  • Potential to make it easier to assign features to teams
  • Requires common development conventions
  • Requires sophisticated configuration management
  • Technical dependency management can be complex
  • Requirements dependency management can be complex
  • Use for complex LoBs or applications which require developers to have deep understanding of the problem domain
Functional
  • Enables functional specialization of individuals
  • Comfortable approach for people with deep experience with traditional approaches
  • People motivated to be specialists, not generalizing specialists
  • Significant communication overhead between teams
  • Requires more documentation and reviews thereof
  • Requires greater management oversight
  • Increases overall project and organizational risk
  • It often makes sense to have an integration team responsible for integrating the entire solution and testing it end-to-end.
  • Support a “follow-the-sun” strategy where development is performed in one location and testing in another
Internal open source
  • Supports development of shared components or subsystems
  • Spreads the cost of building these components across several development teams
  • Requires other teams to provide developers, at least on a part time basis, to work on this effort
  • Requires management and governance structures which reflect open source development
  • Apply in organizations with developers with deep experience with “public” open source efforts