The Agile Development movement has had a lot of momentum over the last few years. And it’s deservedly so, the movement began as a reaction to unsustainable practices in the software development industry. In turn Agile has led to significant improvements to how software is being delivered. With that success, it’s only natural to look to broaden those same Agile practices at every level of an enterprise. That approach would certainly simplify things but runs into some fundamental challenges when considering that purposes at different levels of organizations are significantly different. Let’s consider agility from the perspective of three levels of abstraction within organizations: Enterprise, Service(Product) & Team.
Enterprise Agility — Survivability
You can go back several millennia to observe businesses and draw a conclusion: their chief purpose is not actually to have the best possible product or service for their customers, but simply to survive. Enterprises look to perform activities that will result in some form of payoff, usually expressed as profits, while avoiding negative consequences, usually expressed as losses. Because the payoffs and consequences can’t be guaranteed, the activities that enterprises take are essentially risks. And an Enterprise continues to survive as long as the differences between payoffs and consequences allow them the ability (access to resources) to continue to take future risks. Enterprises who reach a point where they can no longer effectively take future risks are at the “absorbing barrier”, or in more familiar and frequent terms: bankruptcy.
Given that enterprises are in the business to take risks within a zone of survivability, business strategy can now be looked at as an expression of what are the acceptable risks an enterprise could take to maintain survival. Good strategies expose the risks to greater degrees of payoffs while at the same time limit their exposure to negative outcomes.
Knowing this, enterprises can take actions to expand exposure to the positive risk dimensions and limit exposure to the negative ones — this is business strategy.
But how do you do this? It starts by understanding your customers better — do you understand your customer’s purposes well enough? And what are the fitness criteria that would make them select your offering vs that of another business. Knowing what can affect your customer’s selection behaviour goes a long way to selecting strategies that expose the organization to positive payoffs. This helps to define and determine your services better: what business should we be in, what functional and non-functional features are needed and which of these affect which parts of our market?
Part of limiting exposure to negative consequences, also means your strategy is only viable if it matches your enterprises’ capabilities. So, by extension, enterprises with limited capabilities have limited options for what strategies they can bring to bear. And so, expanding an organization’s capabilities widens the range of possible strategies they can choose from. And conversely a lack of capabilities can narrow it; possibly even to the degree that no available strategies are fit enough for the company to maintain survival.
Enterprise Agility means the ability to have your strategy continuously congruent to your market with the capabilities to match.
It can be expressed as a form of liquidity: can we convert ideas into viable options at the rate that meets our strategy and how quickly can we then convert these options into committed market deliveries. My colleagues Fernando Cuenca and Alexei Zheglov, have some great thoughts on this topic in the article How Agile Are We?
Product & Service Agility — Service Orientation
An outcome of a company identifying the right strategies, is the execution of the strategy through a set of products and or services. Services are simply the act of providing something of value to another party, and so it is helpful to think of all things as services. Products can be seen as a construct for a set of services that have been packaged in a certain way.
For an enterprise to be competitive, their services need to be fit enough for their purpose. E.g. a coffee shop needs to provide coffees that are within an acceptable threshold of taste, hot and wait time. These criteria of fitness of the service need to be managed and this is the service orientation agenda at this level of the organization.
Customer Recognizability
Aspects of this service agenda can include ensuring that the customer purposes are understood throughout the organization. Does every group/department/team know the intended purpose of what they are working on? Is work being expressed in terms of the customer’s purpose or as something completely unrecognizable by the customer? Without this knowledge, decisions and resulting activities can be highly divergent leading to unacceptable delivery times or failure to meet other fitness criteria.
Flow
Services in most complex organizations require a significant amount of collaboration across teams and departments. Given that most teams aren’t sitting idle in anticipation of requests from other groups, requests between groups are sources of queuing and waiting. Through paying attention to overly high utilization rates (and many other sources of delays) services can significantly improve their flow that improves their service delivery in areas of time, quality and predictability.
Customer Heterogeneity
Services also understand that customers have multiple purposes, and so the criteria of what is acceptable can vary between customer categories. Services can then achieve balance by not over serving in some areas so that they can divert resources to prevent under serving in others. You can see everyday examples of these Classes of Service at your local fast food chain, simply by noting the differences in speed one is serviced once at a drive-thru vs within the restaurant.
Agility at this level is about a services agenda: understanding the customer’s purpose and achieving flow to meet it.
Team Agility — Sustainable Practices
As we start to understand teams and individuals, this gets back to the original Agile agenda. This is where sustainability is expressed through both human and technical practices. Whether a team is using Scrum, Team Kanban, XP or something else entirely — they attempt to arrive at sustainable ways of working. Teams avoid being overburdened by achieving the right balance of work while limiting how much work they are committing to, transparency is promoted to improve feedback loops and allow for decentralized decision making. Common delays and sources of failure are also addressed through modern technical practices. I’m not going to get too far into this, as there are plenty of great resources on Agile and teams out there; I have my preferences but that isn’t within the scope of this article.
Agile at all levels, but not scaled
Business Agility is about achieving the right kind of agility at all levels of an organization. At the level of the enterprise, it needs to promote survivability. At the level of services, it needs to promote service orientation. And at the level of teams, it needs to promote sustainability. Businesses require all three, but given the differing needs at each level it won’t be able to achieve them by attempting to replicate and expand Agile Development approaches across the company.
Here are some resources on Survivability & Service Orientation:
Enterprise Services Planning Workshop — Lean Kanban Univeristy
The Black Swan — Taleb
Antifragile — Taleb
Fit for Purpose — Anderson, Zheglov
Kanban Maturity Model — Anderson, Bozheva
留言