There's a really good Harvard Business Review article from about 2 years ago here:
https://hbr.org/2018/05/agile-at-scaleIt talks about (surprise!) adopting agile at scale. It avoids mentioning specific methodologies, such as Scaled Agile Framework (SAFe), Large Scale Scrum, Spotify Model, etc. It caught my interest when I first read it because it talked about the need for a "taxonomy of teams":
"Just as agile teams compile a backlog of work to be accomplished in the future, companies that successfully scale up agile usually begin by creating a full taxonomy of opportunities. Following agile's modular approach, they may break the taxonomy into three components-customer experience teams, business process teams, and technology systems teams-and then integrate them."
What I'd like to consider, and hear from those of you adopting agile-at-scale and TBM, is whether or not the TBM taxonomy can help serve this purpose ("a taxonomy of teams")?
With the TBM Taxonomy (especially v4.0), we have elements that could serve this purpose. Our top layer is often used to describe portfolios for products or services owned by customer experience and business process teams. For example, a business may have portfolios setup by Business Units (e.g., an Insurer might have portfolios for its various divisions: Life Insurance; Property & Casualty; Supplemental; Reinsurance; etc.). And/or it may have portfolios by business capabilities (e.g., Product; Policy Servicing; Investments; Underwriting; Claims; Sales & Marketing). And/or it may have portfolios by Products Lines or Digital Platforms (e.g., MyInsuranceApp platform). With these, you can see where you have customer experience or business process teams would fit.
Similarly, we have Solutions for the various "technology systems teams" that exist. These fall into our technical solution types called Delivery, Platform and Infrastructure. Agile organizations typically employ public cloud-based services for the latter two types (IaaS and PaaS) where possible. However, public cloud often isn't an option, especially early in the "journey to the cloud." You probably have many legacy or traditional platforms and infrastructures in place that cannot easily (or cost-effectively) be migrated to public cloud, at least in the near term. So your technical solutions likely include a mix of public cloud-based services and a combination of assets, internally-delivered services and non-cloud external services.
Having your solutions (and therefore solution teams) clearly defined in the context of the TBM taxonomy helps in several ways:
- The taxonomy clarifies how technical solutions are used to support the business solutions teams. In other words, the business solutions teams are internal "customers" of the technical solutions teams, regardless of how those technical solutions are sourced (cloud, MSP, on-prem, etc.).
- Solution owners see the context of their solutions vis-à-vis the other solutions in the portfolio. And this helps solutions and portfolio owners see gaps and duplication within the portfolio.
- The taxonomy shows how solutions support business units, business processes, business capabilities, product lines and digital platforms (systems of engagement). In other words, solution teams begin to see how they support business outcomes.
- The taxonomy differentiates between "functions" (such as the service desk or PMO) and solutions, especially services. Functions are often found in what we call towers and subtowers, and solutions are built from those functions. For example, an application-based solution might be comprised of licensed software, software development, servers and storage, security and compliance, service desk support, and other components. These components represent various functions or towers/subtowers in the taxonomy.
- Solution owners better understand the options they have for building, enhancing, maintaining and running their solutions. For example, they may see that they have both on-prem and public cloud options for storage or different tiers of service desk support. This helps them make the necessary trade-offs between cost, performance, risk and other factors.
I'd like to hear from others.
Can the taxonomy serve an elevated role in agile-at-scale organizations where having a shared understanding of roles and relationships in the bigger picture are so important?
------------------------------
Todd Tucker
VP, Standards and Education
TBM Council
------------------------------