Scaling Factors

The Software Development Context Framework (SDCF) defines how to select and tailor a situation-dependent strategy for software development. The SDCF is used to provide context for organizing your people, process, and tools for a software-based solution delivery team. Figure 1 below depicts how several selection factors drive the choice and tailoring of your team organization (people), delivery process, and tooling configuration. Of course initial selection is just the first step, you will also need to tailor these choices to reflect the situation that you face – hence the scaling factors.  The focus of this page is on the scaling factors, not the selection factors.

Figure 1. Strategy selection and tailoring.

SDCF Overview

Scaling Your Strategy for People, Process, and Tools

Figure 2 summarizes the six scaling factors, indicating the range of each factor. On the left-hand side is the simple extreme and on the right-hand side the challenging extreme. In our various IT surveys over the years we have found evidence that organizations are applying agile at all levels of scale, most recently in the 2012 Agility at Scale survey.

Figure 2. Scaling factors.

SDCF Scaling Factors

Let’s examine each scaling factor one at a time:

  1. Team size. Teams can range in size from two people to twenty to two hundred or more. Larger teams are typically formed to address more complex problems, and as a result large teams take on the challenges of greater domain complexity and/or greater technical complexity as described below. Team size tends to directly affect how you organize the team and how you coordinate within the team. For example, a team of 200 will be organized into subteams and a leadership team will be required for coordination. A team of 50 will also be organized into subteams, although coordination will likely be simpler and possibly handled by a daily coordination meeting of representatives from each subteam (a techniques referred to as a Scrum of Scrums). It is fairly straightforward to coordinate the activities of a team of 10 people.  Please read Large Agile Teams for a more detailed discussion.
  2. Geographic distribution. Agile teams may be co-located, with the team members and key stakeholders in the same room, they may be on the same floor in a single building, on multiple floors, some may work in different buildings, some may work from home, and some may even work in different countries. A popular misconception is that agile teams need to be co-located, a misconception that we have shown via several surveys over the years to be false. Granted, it’s a very good idea to get people working as closely as possible, but it doesn’t happen as often as we’d like. Similar to large teams, coordination of team members throughout the project become more difficult and as a result more sophisticated coordination is required. A greater investment in initial modeling and planning, but not much more, is required during Inception to mitigate the communication risks associated with distribution. To increase chance of project success you will need to fly people around at key points in the project, something many organizations are loathe to do because it’s easy to measure travel costs but difficult to quantify the benefit of face-to-face collaboration.  Please read Geographically Distributed Agile Teams for a more detailed discussion.
  3. Organizational distribution. This refers to the concept of involving people from several organizations on the project. The easiest situation to be in is to have all of your team members from the same group/division within a single organization. It’s a little harder when people from several groups are involved. Hiring contractors adds to the complexity. Outsourcing a portion of the work to an external service provider is harder yet. Outsourcing to several vendors harder yet. Outsourcing to one or more service providers with a very different culture than your own harder yet. Organizationally distributed projects tend to take on the challenges associated with large teams and geographically distributed teams. When outsourcing is involved they take on the risks associated with procurement and then the governance of the outsourced effort.
  4. Compliance. There are two forms of compliance. Generally the simpler form of compliance is self-imposed, perhaps your organization chooses to be CMMI or ISO compliant. The second, and potentially harder, form of compliance is regulatory compliance.  A team may need to conform to financial regulations, privacy regulations, or even life-critical regulations. Although every regulation has different requirements, from a process point of view they typically require extra documentation (but keep it light), reviews (keep them streamlined), and sometimes a documented process (as we suggest DAD).
  5. Domain complexity. The complexity of the domain, or the problem space, being tackled by a team can vary widely. An informational website site, such as this one, is fairly straightforward. An e-commerce site is more difficult. An air traffic control system even more difficult. The greater the domain complexity that you face the more you want to invest in up-front modeling and planning. Not much more, mind you, but still more. Similarly as domain complexity rises it motivates greater sophistication in your agile testing strategy. As domain complexity increases it puts a greater burden on your Product Owner, requiring more sophsticated agile modeling skills and potentially the support of agile business analysts.
  6. Technical complexity. Disicplined agile teams will face varying levels of technical complexity. On the simple end of the spectrum you’ll have the development of a brand-new, stand-alone application built with new technologies. Things get more difficult if you need to take advantage of existing services or data sources. Things get more difficult if you need to support several technology platforms. Things get more difficult if you need to implement using several languages. Things are more difficult yet if you need to refactor existing infrastructure (including legacy data sources). As with domain complexity, the greater the technical complexity the greater the need for a bit more up-front modeling and more sophisticated testing throughout the lifecycle. Greater techncial complexity puts a burden on your Architecture Owner, requiring great agile architecture and agile design skills of them.

7 thoughts on “Scaling Factors

  1. Joanna

    If I understood it correctly, the earlier Agility@Scale model had 2 additional scaling factors: Organizational Complexity and Enterprise Discipline. Is it fair to say that they have moved to (spread across) the various “Selection Factors” in this SDCF model?

  2. scottwambler

    Yes, in the years since we first developed the Agile Scaling Model, which the SDCF derives from, we realized that those two issues didn’t have as much of an affect on process tailoring decisions as we thought. They did however affect process selection a fair bit.

  3. Jean

    In my opinion, Organizational Complexity and Enterprise Discipline are the intangible factors that if not handled properly, will directly impact whether or not your scaling efforts are successful. They can’t be ignored and need to be handled through an effective Change Management plan. So, while they don’t affect process directly, they do most certainly impact whether you succeed or fail.

  4. Pingback: What Makes a Good Disciplined Agile Delivery Coach? | Disciplined Agile Delivery

  5. Pingback: What Makes a Good Disciplined Agile Delivery Coach? | Toocan

  6. Pingback: Put Practices in Context: #NoBestPractices | Disciplined Agile Delivery

  7. Pingback: Disciplined Agile Delivery » What Makes a Good Disciplined Agile Delivery Coach?

Leave a Reply

Your email address will not be published. Required fields are marked *