In the software world, there are principles that can be applied to make an architecture more agile. One of these is “design for change”. Because change is inevitable, a robust design will anticipate change in a way that minimizes impact to the existing system. A related design practice is to encapsulate what might change behind an interface (API). And a good practice for software in general is to hide the implementation of whatever happens behind the API so that code that relies on the functionality does not have to change its messaging or expectations when the hidden functionality is changed.
Here is a simple example. An ecommerce system will need methods of payment. A rigid system will implement the payment types (credit card, bank transfer, PayPal, BitCoin) individually and leave it up to the calling software to know which payment method to call and what it needs to know. A more agile system will offer a payment function with a standardized interface that the calling software can talk to with minimal parameters and no concern for how the payment is accomplished. The calling software does not need to know anything about what goes on behind the API and, therefore, changes can be made in the details of any of the payment processing methods with no changes to the code on the calling side.
We may be able to mimic these agile architectural principles in a system comprised of people. Consider a small specialty department of experts who take in work from various internal clients in a one-by-one manner, each expert focusing on specific clients. Each expert then manages their work according to priorities set by themselves or by management. Client response time is dependent on the availability of the assigned expert and their workload. There is a risk of the expert being unavailable for some time with no one able to fill-in.
Organizational departments with this profile may include database administration, ERP configuration, content translation, pure research, analytics and data science.
An alternative, agile configuration is to create a self-organized team of experts that share the work from all clients. The group becomes a “service” providing the nominal specialty of the group. Work comes in and is accomplished in priority order. The results are delivered by the team. Internally (behind the service “API”) team members decide who does what work. Additionally, team members can work together, focused on the highest priority requests. Team members learn from each other. The team develops a regular cadence and tracks throughput to help in forecasting future delivery rates and to determine existing and needed capacity. Single-point failure risk is greatly reduced and aggregate throughput is increased through reduced context switching and shared knowledge.
This structure describes a Scrum Team where the product Backlog is the queue of mixed client requests rather than a coherent set of features for a single product. The Scrum framework provides a proven strategy for organizing, managing and sharing work in a manner much more efficient than in the original one-by-one expert scenario. In some cases, combining the Scrum framework with Kanban practices may provide more specific metrics and more focused identification of bottlenecks with opportunities for improvement. Team expansion and contraction, additional teams, different frameworks and process changes are all encapsulated behind the “API” at the Product Backlog. Client interactions are not impacted other than through improvements in response time.
