Manifesting Business Agility

The goal is semi-autonomous, self-organizing, cross-functional teams dedicated to a particular product or service. 

Most companies require a two-step process to get to this network/hierarchy structure. They should be done in parallel or sequentially as appropriate (discussed in subsequent posts).

One step is to identify the dependencies across the current teams. This will immediately increase the collaboration and efficiency of these teams. But this is mostly accommodating the real problem – having the dependencies and handoffs in the first place. Making these dependencies visible lays the foundation for the second step - improving team formation to reduce the dependencies and handoffs. This reduces multi-tasking and waste arising from delays in the workflow.

Ironically, teams can become more Agile not by teaching them how to work with each other but by having them not to need to work with each other.

Many experts are converging on what the future of an Agile organization looks like. Many are espousing a network of semi-autonomous, cross-functional teams aligned around products being supported by a business organized in a hierarchical structure. The network allows for innovation and effectiveness of value created while the hierarchy allows for efficiency of business operations.

Several companies have self-created this structure including Amazon, Barclays, Google, Riot Games, and Spotify. It is being espoused directly by Stephen Denning (Age of Agile) and John Cotter (XLR8) while several other esteemed authors are consistent with it.

The challenge is getting there. Some attempt to emulate the approaches of successful companies, such as Spotify. This ignores the fact that corporations are different and although objectives may be similar, any adopting company must necessarily tailor their approach. It also ignores the fact that Spotify’s approach was figuring out what they needed and doing that.

While keeping the end in mind can be useful, just attempting to jump there is fraught with risk. Where you’re jumping to may not be right, and your organization may not be able to take the leap.

One of DA's mantras is to be able to choose your own Way of Working (WoW) based on where you are and what you want to achieve. DA is a pragmatic approach based on the principles that choice is important & guided by the context you are in. 

Some Agile at scale approaches often work at first, starting well only to plateau or even go backwards. The reason for this is that most companies require two steps to get from where they are to where they want to go and most pre-defined approaches attempt to accomplish this in one step.

These are the upcoming posts:

1. What we want to achieve
2. The two steps required
3. Why the first step on its own often ends up being a step backwards
4. Implementing the DA-FLEX Two-Step Method 1 for small to medium size organizations with well-defined teams
5. Implementing the DA-FLEX Two-Step Method 2 for small to medium size organizations without well-defined teams
6. Implementing the DA-FLEX Two-Step Method 3 for large organizations

I will post at least one of these aday until the series is done. 

One of DA's mantras is to be able to choose your own Way of Working (WoW) based on where you are and what you want to achieve. DA is a pragmatic approach based on the principles that choice is important & guided by the context you are in. 

Some Agile at scale approaches often work at first, starting well only to plateau or even go backwards. The reason for this is that most companies require two steps to get from where they are to where they want to go and most pre-defined approaches attempt to accomplish this in one step.

These are the upcoming posts:

1. What we want to achieve
2. The two steps required
3. Why the first step on its own often ends up being a step backwards
4. Implementing the DA-FLEX Two-Step Method 1 for small to medium size organizations with well-defined teams
5. Implementing the DA-FLEX Two-Step Method 2 for small to medium size organizations without well-defined teams
6. Implementing the DA-FLEX Two-Step Method 3 for large organizations

I'll be posting these on a regular basis here. 

Creating and deploying functionality to existing products in large organizations requires multiple teams to coordinate with each other in order to minimize delays in workflows both within and across these teams. The backlog item used by these teams must be designed to accommodate this. These must:

• be the minimum size that can be deployed while providing value in a manner consistent with the needs of customers and the business
• describe the overall behavior desired
• identify the capabilities needed to build and deploy them
• represent the next increment of an initiative to be deployed (this enables step-wise manifestation of the organization’s strategy)
• be able to be sequenced according to the value delivered and the cost/time of creating it

DA calls this the Minimum Business Increment (MBI).

Whereas the MVP is about discovering what product would be of value, the MBI provides the next chunk of value for an initiative to be deployed. MVPs are discovered and created by a team. They start small and expand. MBIs are focus on the next incremental value to be built while being used to coordinate multiple parts of the organization to get it deployed quickly.