Wouldn’t it be easier if you could just select the people you needed to deliver a particular project or ongoing series of product changes, put them in the same room, and let them get on with it, in line with Agile practice? What’s stopping you?
Often, it’s the fifteen other projects which also need an arm or a leg of a critical resource, or system, data or governance dependencies. The reality is that almost every business is a complex mesh of systems, skilled people and priorities, and ringfencing for one particular product creates issues elsewhere. This is especially true when it comes to shared service teams such as architects, and with shared systems such as ERP and billing.
The answer is to apply pragmatism. Create autonomous delivery functions wherever you can, and focus on managing the dependencies, recognising autonomy won’t work for everything. For example, eCommerce front ends, ongoing small enhancements to legacy systems of record, configuration changes to your CRM system – all perfect for an Agile approach of ringfencing a multi-disciplinary team and allowing it to self-manage the delivery of the backlog of change for an agreed area (with appropriate controls).
How do you deal with the inevitable cross-team dependencies? The answer is to treat your shared functions as cross-portfolio “services”. This applies both to systems and to teams. Ringfenced teams will inevitably be dependent on cross-delivery shared functions – whether for oversight/direction (eg architecture teams), for consistency/reuse (eg middleware) or for service operations and management. It’s important to set out how these functions will manage their multiple customers, by setting out a service model – with a clearly defined set of services, a simple engagement / work initiation approach, and a pragmatic way of managing demand and supply.
I’d be interested to hear your experiences of multidisciplinary teams, and how you’ve addressed these challenges.