Breaking down the business agility problem

There's more to business agility than agile frameworks

I spent a good 15 years with product organisations before walking into financial services and other businesses. So, I had a predominantly engineering mindset at that time and hence I went through my own initial phase of difficulty to understand the challenges that banks and financial institutions had with agility. What actually followed was an intentional immersion to understand these specific challenges.

I realised that there are three key areas or aspects within an organisation that contributed significantly to the ability to be agile. These are:

1. how businesses fund and prioritise work
2. how capability is managed, and finally
3. how work is orchestrated.

Let's now get into a little bit more detail.

The funding model and prioritisation

The funding model is about how money is forecasted and allocated to get work done. It is important because it determines the lifecyle, stability and maturity of teams that are actually required to deliver work.

What happens with traditional project funding?

Organisations that have traditional program and project-based funding create fluctuating demand on the organisational value chain. This is because projects of varying sizes and durations start and finish at different times. This can play out in a few different ways:

1. Projects wait for delivery capacity
Projects wait for teams to have capacity to start working on them. A team, once committed to a project, usually stays focused and delivers it. Some teams, depending on their available capacity, even pick up multiple projects working on them in parallel.

Within most organisations, internal teams own project delivery. The teams scale up and down to meeting rising and falling project demand.

However, I've seen several strategic projects that were stalled because one or more of required teams were busy and refused to engage. Interestingly, team priorities were overruling organisational priorities thereby jeapordising critical projects and the benefits they would bring to the business.

2. Temporary and external project teams
When in-house teams are fully busy, critical projects rely on partners and contractors who are brought in specifically for the purpose. These temporary teams often lack organisational context and knowledge. Riddled with constraints, they struggle to deliver project outcomes. Such teams also face early delays before they enter into a performing phase. The mad scramble of delivery finally begins.

To meet the pressure of original deadlines and funding, a "risk-based" approach is used for quality assurance. Planned operationalisation of changes is often ignored and there is very minimal knowledge management or transfer to operational teams. Support teams ultimately end up picking up and fixing the broken pieces. Sure it doesn't paint a pretty picture, but I have observed almost all of these behaviours with every external project team.

Internal teams are seen to work better than fully external project teams because of their superior knowledge and level of ownership. They are already in a performing state and don't need time to form, storm and norm.

Once a project gets into the delivery pipeline, it is usually allowed to complete and the project is closed-off.

Transitional and agile models

Projects are used for business funding even within agile organisations. However, projects are broken down into smaller independent business features. These business features would compete, with features from other projects, for priority. Thus, projects are seen as contributing funded features to the organisational pipeline of work. This contrasts significantly from traditional waterfall project models where prioritisation is usually done at the project level.

Many organisations that have embraced business agility as a strategic differentiator use a quarterly review and planning cycle for funding and backlog prioritisation. Usually called program increment (PI) planning, this establishes goals for the next three months. The planning event also brings people together with energy and enthusiasm to celebrate ownership, achievement and excellence.

Most organisations that have embraced business agility as a strategic differentiator have established a quarterly review and planning cycle for funding and backlog prioritisation.

However, when organisations use the 3-month PI planning cycle, I've observed that urgent critical work is also made to wait until the next planning cycle. Even then, they sometimes don't get through to delivery due to lack of delivery capability or relative priority. Would that mean that quarterly planning doesn't work in favour of business agility?

The Capability Model

Funding is the biggest enabler for delivery capability. Because without money there are no people, teams or skills.

There are several popular models for capability. The Spotify model which organises people as squads, tribes, chapters and guilds is a popular one. Many organisations build asset-based teams formed around knowledge and ownership of a group of systems or components. At an organisational level, chapters or Communities of Practices then bring together people based on skills or disciplines.

There are three key success factors for having a successful delivery capability:

1. Understanding and managing skills and competence: Knowledge work requires specialised skills and knowledge from different domains and disciplines. Sustainable fast-paced delivery requires a thorough understanding of these skills. The set of skills could vary between projects and even features, hence it is importance to have a clear upfront understanding of competencies that are needed.

2. Cross-functional teams: The cross-functional approach brings together all required skills and knowledge as a tightly-knit team. Such teams are faster and efficient with better quality. This is because of the ability to have a single focus as a team enabling faster progress. Frequent collaboration as a team also enables feedback loops that improves quality and value assurance. Cross-functional teams, when planned well, also help minimise external dependencies.

3. Ability to size-shift: If the key benefit of agility is to respond to changing business needs, the ability to scale or ramp-down rapidly to balance demand and supply is a key enabler for business agility. With large strategic programs, teams often get a bit of time to adapt. However, a flurry of regulatory response situations or market-innovation opportunities could test the ability of the team to flex capability. So, while stable teams may be a best practise in most organisations, the ability to rapidly reshape your delivery capability would definitely give organisations an edge to deal with changing business needs.

If the key benefit of agility is to respond to changing business needs, the ability to scale or ramp-down rapidly to balance demand and supply is a key enabler for business agility.

The Value Orchestration Model

The next logical thing is to actually make use of the teams to deliver features! Agile frameworks purpose to solve this problem. You could use Kanban, Scrum, SAFe, LeSS, Nexus, DSDM or any other hybrid delivery framework to do this.

But having a few different options can cause more questions than answers. For example,

• Is Kanban the best for business agility because you could potentially re-prioritise the backlog anytime?
• How does a 3-month program increment planning cycle along with Scrum or similar frameworks impact your agility?

Is there a clear conclusion?

It does appear that funding, capability and work orchestration models all contribute significantly to business agility. My key premise is that they need to be seen as distinct with their own possible approaches. For example, I don't see the Spotify model as an agile framework - I see it as a capability model. I see agile frameworks as work orchestration models.

What has worked for me is a careful combination of these models to suit every organisation's aptitude as well as business agility requirements. What is important is that all three of them are aligned to support each other for the best agility.

The most common model combines the following:

• A three month funding cycle using the quarterly PI planning.
• Capability as stable agile teams. Prioritisation is used to limit the work done by the teams.
• Agile frames like SAFe or LeSS or Nexus for work orchestration.

For organisations or value chains that love extreme business agility, I often start with the following combination:

• A feature-based funding model
• Pym-teams for managing fluctuating capability.
• Scrum or scrum-like frameworks for work orchestration, however, allowing business to use every new sprint as an opportunity to re-prioritise the backlog.

What I would emphasise as the key success factor for business agility is value-based breakdown. Breaking down a project into business features bring several benefits including reduced complexity for development, integration, deployment and change management. Value-based breakdown also enables better granularity for prioritisation. Regular prioritisation allows to pivot the whole organisation to adapt to changing business needs. So putting in the extra effort to do the breakdown early, consistently and thoughtfully sets the tone and pace for true agile delivery.

I've seen many organisations that fail to provision that 20% extra effort from architects, analysts and SMEs to do the upfront project or solution breakdown. Sadly, it is often due to ignorance at the executive and senior leadership levels about how (and why) agile works. And such organisations end up trying to squeeze waterfall sized pieces of work through agile delivery pipelines.

Image credit: https://unsplash.com/photos/Ua-agENjmI4

Posted under: Business Agility, Agile Maturity, Agile Thought Leadership