Agile Ecosystem
You are part of a tightly connected ecosystem of teams focused on a common cause.
Problem
You are trying to deliver value to the market however there is more work to be done than could be accomplished by one single team. As you take on extra work required to scale, you spin up extra teams. Invariably teams run into challenges as teams start duplicating each others work, mis-aligning on outcomes, and in some cases causing conflict with each other.
Solution
Group all Edge Teams, Traveler Pools, and/or Enablers that focused on a common overarching outcome into a single context boundary, named for the purpose trying to be achieved. Enable people withing the Agile Ecosystem to focus on a common purpose, one that is more fined grained than the overall purpose of the organization.
Discussion
All members of the Agile Ecosystem share a dedicated market that is a distinct subset of the market of the larger organization you belong to. Teams will typically share a common, higher level backlog of demand made up of coarser increments of demand (eg: Epics / Features / MVPs/MBIs etc) and will collaborate as required to deliver on that backlog.
Teams within an Agile Ecosystem should also be given responsibility to truly own an outcome and achieve an enduring purpose. This includes maximizing ownership of operational activities, customer interactions, marketing, and support. Where cross team dependencies exist, we want them to be contained within a purpose boundary. For this reason we want Agile Ecosystem to have their own core, with their own leadership, and dedicated enablers.
This will not always be feasible, but it is a design principle worth keeping front and center. One way to do this is to ensure that all dependencies between a Purpose Boundary and the rest of the organization are exposed through platforms, one that enables self service and usage that is fit for purpose.
We need to be careful to not let Agile Ecosystems become to large, or it will be challenging for people to collaborative in any meaningful way on any kind of tangible purpose. While there are no hard and fast rules, my experience is that people in a Purpose Boundary can align to a common outcomes with between 12 and 50 people. As we increase the size of a Purpose Boundary, we run the risk of fragmentation and churn, consider breaking up the purpose boundary into multiple, smaller purpose boundaries.
Options
The Micro- Enterprise
Micro-enterprises can be thought of as miniature organizations within the larger enterprise. They are the idea of independent teams taken to their fullest extent.
I can't remember the first time I heard of the Term Micro enterprise, but I am very fond of the overview and description provided by Joost Minnaar and Pim de Morree in their excellent book Corporate Rebels
"Micro - Enterprise are expected to engage their users throughout the entire business process: from R&D to product design to production and delivery. Users can offer feedback at any time in the process. In this way, Haier wants to turn the one-time customer into a lifetime user."
According to the authors of Corporate Rebels, one of the keys to the success of Micro-Enterprises is setting them up as Open Platforms. In this way, teams can connect both employees and users directly to each other via the Internet and digital tools.
The Micro - Organization is the pinnacle of business agility. Successful Micro - Enterprises grow within the overall enterprise, potentially spawning new Micro - Organizations, unsuccessful ones are allowed to die.
Purposeful Team
Another north-star in terms of agility is the idea that a Purpose Boundary is no bigger than a single team. Each team has an independent purpose, and is effectively operating independently from other teams. The team operates with complete autonomy and requires little to no coordination with other teams in order to deliver value.
Sadly, I have rarely encountered this in my experience of traditional enterprises making the agile journey. Departmental protectionism, dysfunctional back offices, arcane technology, shambling architecture, and a maze of bureaucracy and dependencies all acts as barriers to the truly autonomous team with an independent market purpose. But this an ideal worth striving for, there are numerous examples of organizations who have teams that have achieved this, why can't yours?
The Program / Portfolio
For organizations who are following a more conservative path to agility, a more diluted form of Purpose Boundary may be appropriate. In this case we can take the more traditional concepts of a large scale program, or a portfolio of initiatives and supplement them with an agile mindset. Many discrete enterprise programs and portfolios have more control over how they delivery value than your traditional organizational department. They tend to be staffed by a diverse mix of people from all across the various departments including IT, product, and operations, in a way that subverts the traditional organizational structure. Programs and portfolios often have common budgets, with a funding model that is based on achieving larger outcomes, rather than on a project by project basis. There is a healthy backlog of work, and a real challenge coordinating demand to the people needing to do the work.
For these reasons, a program or portfolio of projects serve as a prime candidate for organizations with less familiarity with the concepts designing and operating a cohesive ecosystem of agile teams, enablers, and travelers.
