(fr)Agile Operations

Agile has certainly captured the corporate imagination and spread its tentacles beyond the realm of software development into mainstream project management. It is now touching on day-to-day operations across many organisations.

The benefits speak for themselves:

1. The focus on epics, customer stories and a clear mission is ensuring that the squads are delivering what customers value.
2. Establishing self-directed, multi-skilled and cross-skilled squads is helping build accountability and engagement among staff.
3. The inherent lean principles, a clear definition of done and a focus on planning, prioritisation and retrospectives is driving
   continuous learning, innovation and improvement.
4. Kanban, daily stand-ups, visual boards and the time-boxed sprint approach are accelerating the time to benefit by ensuring roadblocks are dealt with quickly and the pace and rhythm of delivery are maintained.

However, before you consider charging headfirst into Agile’s promised land, be clear about which aspect of your operation is missing the Agile spark. The point here is that most operational teams do a blend of core delivery work and improvement projects. Core delivery is concerned with fulfilling day-to-day service requests such as answering enquiries, processing claims and assessing loans. Applying an Agile approach to your improvement projects is obviously far easier given Agile’s project roots. As there is limited risk involved, run a “test and learn” pilot, comparing a team using your current CI approach with a team trialling Agile. No need to read further – just make sure you’re not using a sledgehammer to crack a nut.

If, on the other hand, you are looking at Agile for your core delivery work, then read on – it may save you a lot of heartache. There are three points that you need to consider:

• Agile’s Lean principles
• Capacity management strategy
• Process layout.

Agile’s Lean Principles

Agile has borrowed heavily from manufacturing – in particular Lean techniques – and many service operations have also been focussed on applying Lean techniques, hence, it should come as no surprise that many delivery teams are already applying Agile techniques, just using a different name e.g.

• Daily stand-ups v buzz meetings,
• Kanban v workflow,
• Production leads v scrum masters,
• Product owners v e2e process owners,
• Backlog v WIP/queues,
• Sprint planning v loading meetings,
• Showcases and retrospectives v variance meetings,
• Task boards v visual control,
• Burndown chart v control chart,
• Definition of done v SLAs,
• MVP v quality specifications and tracking.

So before you throw the baby out with the bathwater, check which aspects of Agile you’re really missing out on. It may be that you could progress far faster by improving on what you have. Better not to confuse the team by throwing out your current practices and replacing it with the latest shiny new consulting toy if your current practices just need some tweaks.

Capacity Management Strategy

One key difference is that Agile works on a fixed capacity basis i.e. if the resources are fully assigned and a new task comes in, it’s just added to the backlog for prioritisation in the next sprint. Core delivery is about fulfilling a continuous flow of service requests using a repeatable process that delivers consistent output at precisely the level of quality specified day in, day out.

Unfortunately the demand for services is rarely smooth, with each service type having a unique demand profile. Since you can’t build services to stock – e.g. draw down a home loan for a customer today just in case they might apply for one in a month’s time – delivery teams can’t operate on a fixed capacity basis and have to follow a “chase demand” approach. This requires the team to flex capacity (see The Alchemist’s Tale series). Even if tasks can be added to the backlog, they nearly always have to be cleared well before the next fortnight’s sprint starts.

Process Layout

Most high volume service operations have adopted an “assembly line” type layout. The process is broken into stages, laid out sequentially and every customer follows the same path through the process. The stages are typically clusters of tasks that require similar skills or logical steps in the process. The objective is to create continuous flow – with customer orders moving at a steady pace through the process. This layout typically delivers the lowest unit cost of all layout options. It does this by:

1. Division of labour across stages – simpler tasks in the process are performed by lesser skilled resources (ie lower cost resources) and higher skilled resources can focus on tasks that require their specialised skills.
2. In a service environment “balancing the line” i.e. achieving the same rate of flow through each stage of production is usually achieved through increasing or decreasing the number of resources working at a stage rather than splitting tasks into stages that take the same time. For example, in a 2-stage process, if stage 1 takes 10 mins and stage 2 takes 20 mins, you have twice as many resources on stage 2 to ensure throughput flows evenly.
3. By aggregating demand over a single process you tend to smooth out the peaks and troughs of both demand and capacity, making it far easier to balance the two. This also ensures higher resource utilisation.

Moving to an Agile approach of smaller teams is similar to a “cell based” approach in manufacturing. The aggregated demand is now allocated across multiple cells. So if you have a customer enquiry servicing team that handles all enquiries for the organisation, a cell based approach may see it split according to customer segments, geographic segments or, in large organisations, individual customers (not uncommon for large “platinum rated” institutional clients).

Within the cell there are multiple layout options available to create flow e.g. you can have a mini-assembly line layout or one based on product specialisation, if the variety is broad. The benefits tend to be oriented around better customer service – the team gets to know the customer base very well, takes greater accountability for delivery and, through deeper knowledge of the customer, they can both be proactive and more productive.

However, you have taken a large pool of common demand, requiring a common output that is now split across multiple teams, each empowered to change the process to deliver to their subset of customers. A few questions may help identify whether this is at an acceptable cost:

1. A squad of 10 is sub-scale for complex processing/servicing. The “Law of Large Numbers” smooths out most bumps in the road, making capacity management easier. With a smaller team this is far harder. If you only have 1 or 2 people capable of performing a task, what happens when they are sick or on leave? Losing 50-100% of capacity in an operation that measures delivery in minutes and hours, not fortnights and months, is catastrophic.
2. Multi-skilling and cross-skilling are typically called out as a benefit of Agile, but how realistic is it to cross-skill the team? For many large organisations with legacy platforms, fragmented processes and complex products, the time to competency for a single process can be measured in months, if not years (think of underwriting or trade finance accreditation). Are you prepared to invest in that amount of training, the higher labour rate demanded by suitably able candidates and do you want these high cost resources doing more menial tasks to ensure the squad gets through its work? What’s the impact on career path options? There is a further complication that smaller teams means that lower volume services become very infrequent in a small team, so how do you maintain knowledge?
3. The pathway to effectiveness and efficiency in operations is typically: consolidate->standardise->simplify->automate. Agile is going in the opposite direction. It is fragmenting operations and will make standardisation far harder when multiple squads effectively have to run the same process but are encouraged and empowered to change it for their pool of customers, even though the underlying output for a different pool is almost identical. So how will you maintain consistency and still stay true to the Agile principles? How will you lend and borrow resources across teams if each team has changed the base process to meet their needs and you need to train members from other squads on the differences?
4. What price lower utilisation? Given you no longer have scale, what do you do with a resource where there is no demand for their unique skill set on a particular day or what do you do if a squad only needs a fraction of an FTE e.g. 4-8 hours per week? Do you ask customers to wait for the day that particular resource is at work? Do you ask the resource to come to work 1.5 hours a day?

All of these questions can be answered. As with most things, the ultimate path you take will be a trade-off. The higher unit cost associated with moving to an Agile “cell” may be acceptable for an institutional client generating many hundreds of thousands, if not millions, of dollars of revenue, where client knowledge is paramount for client satisfaction. But for clients and customers at the other end of the revenue scale, it is far from being clear cut.

It takes time to build a well-managed operation, let alone a world class one. Think carefully about the nature of your team’s work before diving into an Agile transformation. A few poor design decisions can break even the best operation quickly.