This is the sixth article in a multi-part series:
Part one | Part two: | Step 1 | Step 2 | Step 3 | Step 4 | Steps 5 & 6 | Step 7
Step four: design the flow of work
Informed by the goal of the system, the principles and constraints, we use an iterative and collaborative Design Studio to model the teams that we will need to deliver value to our customers. There’s a bit of magic in this process that’s beyond a blog but in essence we are looking at a range of things:
- The starting point(s) for design - the nine primes referenced in anti-patterns in Operating Model Design
- The source of demand and the destination (e.g. to the customer, an external stakeholder, or to another internal process)
- Whether we are testing what happens when we relax certain constraints
- The team archetypes that we need to deliver value to customers (mission, product and operations)
- The interactions between teams as value flows through the organisation:
- How they handle communication and priority of impediments to flow of value (within the team, within the organisation, and with 3rd parties)
- The six C’s that Tony Ponton developed building on work done on Australia’s first major financial services agile transformation back in 2008: Customer, Clarity of purpose, required Capabilities, rough Cost, approximate Capacity (for existing operating models), and relevant Codified processes, policies and procedures.
- Any platforms which are critical to the flow of value.
- Any formal communities (e.g. guilds / proto-guilds / communities of practice) that are required for consistency of practice or development pathways are important.
The remote:af Operating Model Design pattern uses hexagons to represent teams as they both cover the six Cs and also constrain the design somewhat. I’m fond of hexagons because they play such an interesting role in nature, they feature a lot in Cynefin’s library of complex facilitation methods and also because of Ben Gracewood’s marvellous Agile Australia presentation: Scaling without Rules. They naturally map to the six Cs and they create a natural affordance to control the number of dependencies between teams.
However, you could equally use patterns like those in Matthew Skelton and Manuel Pais’s book Team Topologies which provides an excellent reference for interaction design that focuses on reducing the cognitive load between teams and on deliberate design interventions for target architecture, or something more free-form in nature.
We review and iterate our designs until we land on a model to take into detailed design:
- Does it enable us to effectively deliver our strategic objectives?
- Does it meet our design principles?
- Does it break any constraints? (and is that really a problem?)
Importantly the model should be recognisable, it ideally shouldn’t be radically different from your existing operating model unless there is a specific driver for seismic change.
Continue to:
