You’ve been redirected to SolutionsIQ.com. BigVisible and SolutionsIQ have joined forces, and–lucky you!–you still have access to all of that awesome content. Dig in.
Invariably, when presenting or teaching about applying Agile principles in organizations, someone always asks me, “are there places where you can’t be Agile?” or “how do you decide whether or not you want to be Agile?”. These questions trouble me, as it seems like we’re offering a false binary choice. Either you are “Agile” or you aren’t. This perspective fails to communicate the nuance that, when considering an organization, there is a spectrum of Agility and the question really becomes, “how Agile can we make our organization?”
Everyone Wants to be “Agile”
First, let’s agree on a definition. When talking about an agile enterprise or organization, we mean an entity that is capable of quickly sensing changes in an environment and responding to them so that it may continue to thrive. Agility, in this sense, isn’t so much the use of specific practices like Scrum, kanban, or XP, but rather the properties that they – hopefully – create for an organization. Let’s further consider Agile practices to be our organization’s ability to respond to change. As a measure of an organizations capabilities, we can refute the claim that some industries can’t be Agile. While an online retailer can be faster than a bank, they are not in direct competition. The goal is simply to be more agile than your competition rather than achieving some absolute measure of agility. From this perspective, all organizations want to be agile. They want to be able to respond to stimuli telling them to exploit new opportunities or respond to new threats. The question really is: how agile is your organization and how does that impact your organization’s ability to execute?
How Do You Measure Agility?
If we remain focused on Agility as being manifest in the capabilities of an organization, we can consider the Agile spectrum based on the level that an organization’s ability to respond impacts its overall execution. In this model, there is a simple spectrum with three distinct points worth considering.
Capabilities as a Liability
Beginning on the left are organizations that suffer from poor capabilities being a liability towards their execution. Fundamentally, this is when an organization must change it’s approach, compromise what it wants to do, or in other ways pursue sub-optimal strategies due to serious limitations in its ability to be responsively execute. This could be the organization trying for the “single, perfect” implementation of a project, because they lack the ability to do multiple releases or work iteratively. The situation that always comes to mind for me is the stakeholder that rarely gets the opportunity to be a part of a development project, and they see this next project as their only hope to get everything they ever want, thus they begin to ask for an inordinate number of features as they never know when they will get another chance. In an idea world, would they ask for stuff they think they may possibly need two year from now? No, but considering the apparent limitations of their current delivery model, they are asking now, because they have no faith that, should they actually need those features two years from now, the organization would be able to deliver them at that point in a timely manner. Organizations in this area frequently suffer from a lack of trust. Another common example would be business units expressing their requirements as solutions – ones they believe will make the delivery easier – without actually engaging with technology about the real problem they want to solve. Ironically, this anti-pattern frequently undermines the project. The technology team doesn’t see the real objectives and is simply trying to build a solution as conceived by the business, however impractical that solution may be.
In the second position along the spectrum, the organization has achieved a level of agility in its delivery such that it can consistently deliver what the business requests as they request it. While this position is in the middle of our spectrum, it is a major achievement and represents one of the major benefits of an agile transformation: namely the ability to align an organization’s operational capabilities with the goals and strategy of the organization. When talking about the value proposition of Agile, most people point to tactical improvements such as improved quality or time to market. These tactical improvements are not useful unless they are in the service of a business strategy. So if the first position represents an organization whose capabilities are so lacking that they undermine an organization’s strategy, the second position represents one of balance where the organization is capable of consistently delivering the tactical objectives of the organization. In our last example, we talked about the business conceiving of their own solutions that they believed would make delivery easy. In this case, business and technology would have a healthy enough relationship to discuss real objectives and jointly figure out the best solution.
Capabilities as an Asset
While the balanced position may seem to be an ideal, it still suffers from the systems anti-pattern known as “Garbage In, Garbage Out“. Namely, if an organization is able to deliver upon tactical objectives, but those objectives are poorly conceived, the organization will still fail. In good organizations, fast enough feedback may offer businesses with the opportunity to learn from their failures. In great organizations, the very operational capabilities are such that the organization learns by doing. Their ability to get rapid and constant feedback on many levels allows the organization to learn, improve, and ultimately produce a better strategy than what they originally conceived. If the balanced position is where the organization has sufficient capability to implement its desired work, this position represents an operational capability such that the delivery part of the organization is not only able to deliver the work, but learn and implement solutions that better serve the higher purposes and long term goals of the organization than what people initially imagined.
Agile projects are fundamentally learning endeavors, and this position represents the ideal point where empirical feedback is used to improve not only operational capabilities, but also the strategic plans of the organization. A truly agile organization is not only able to build things right, but capable to learn and adapt in order to build the right thing. Going back to our earlier example of business sharing requirements with technology, in this domain, not only would the business share their objectives with technology to figure out the best solution, but the technology group may implement incremental solutions and other demonstrations to help validate assumptions and improve everyone’s understanding of how best to solve the problem so that the final solution they implement is significantly better than either group could have conceived at the beginning of the project.
Beyond A Spectrum and Towards a Map
Before going further, I must confess an apprehension. Until sitting down to think about this blog I would have described agility as a spectrum implying a single dimension as the last diagram outlined. The more I think about this, the more I can’t help but see that successfully responding to changes in an environment actual requires two distinct capabilities: the ability to detect that change and the ability for the organization to respond. Considering that my last blog post just looked at the role of a product owner along two dimensions and mapped out different points, I’m feeling like I have only one trick that I am continuing to use, but I can’t help but escape that these two dimensions must be looked at individually. I promise to my readers that my next few posts will steer clear of charting a problem along two dimensions and thank you for your patience. With that out of the way, let’s dig a little deeper into this and turn our spectrum into a map. At first we said that organizations have this simple measure of agility, but let’s tease apart ability to change from ability to sense.
Ability to Change
This is probably the more obvious of the two capabilities, and it really is a measure of how quickly, once we have decided to do something, can we go about executing it. Lean processes offer the powerful measure “concept to cash“, which represents how long it takes an organization to get from the point it has an idea to the point it can be capitalized. It implies not only overall speed for delivering large things, but also an ability to change directions mid course in case circumstances change. This measure is more rooted in the operations of an organization as it really looks at the entity’s capacity for accelerating and overcoming its own inertia once a new direction is set. The most common model I see is for organizations to implement some level of work in process limits – either by establishing Scrum-like time boxes for delivery or using a lean-centric general WIP limit – to provide better visibility into the delivery process, force prioritization, and increase cycle time of delivery. By focusing on minimizing inventory – generally in the form of work in process – and focusing on high technical quality , we retain the ability to change and take advantage of new learning.
Ability to Sense
If the ability to change measures an organization’s capability for adjusting what it is working on quickly based on feedback, then the ability to sense is the organizations capability to rapidly get that feedback. It represents an organization’s capacity for identifying new trends, getting feedback on what it’s doing and in general sensing changes within its overall domain. This feedback can be gained from a number of agile practices including going to market rapidly, extensive customer engagement in the development process, and front-loading risk early in an iterative development process.
Mapping Along Both Dimensions
Using these two dimensions, we find five areas that represent different sets of emergent behavior for an organization based on how well it can respond to change and how well it can sense what’s going on. This diagram over simplifies as it visually seems to indicate that there are only five points where a given organization can exist. My experience certainly indicates that this is still on a scale, where an organization may have caring degrees of capacity in sensing and responding and that it is not a binary switch. However, for our purposes, these areas offer a way to look at distinct characteristics of each area.
In this model we see the original three points we’ve already discussed: capabilities as an asset, balanced capabilities, and capabilities as a liability. The characteristics of these points would remain the same, but by extending into two dimensions we see that an organization must balance both abilities or fall into a place of imbalance where they may have capacity in one dimension but lack it in the other. These imbalances can lead to common anti-patterns.
A common challenge we see with many organizations is that they first perceive agile as being exclusively in the domain of operations, or even just development. This may be because agile was sold as a silver bullet, it may be because change is threatening so many people are quick to try and label it merely as tactical improvements in the delivery of software. They present agile as merely working in small cycles and improving through put. Organizations with this mindset very well may experience some success, improving their ability to deliver. However, if they don’t grow their definition of agile, engage their business and other organizational leaders, they risk moving into the top left area, which I’ve simply dubbed “chaos”. In this realm, the organization is able to move swiftly, but it does not have high quality channels for feedback to direct that activity. Teams may find themselves jumping from item to item based on whims or other apparently arbitrary reasons. In such an environment, an organization’s ability to deliver is undermined by the fact that they are unable to get feedback and validate assumptions quickly. Thus, even if they can rapidly iterate, they may find that the iterative nature of their work is entirely encapsulated in a more traditional release process. Some organizations may invest in their technical development to the point where they can build new features every two weeks, but this benefit is seriously limited by the fact that they are unable to get meaningful feedback on these features prior to being launched, and launches are quite infrequent. Thus, the organization may tactically operate in an Agile way, but they are unable to really take advantage of those abilities. If they are adapting and moving quickly it is merely to the whims of powerful stakeholders or to address fire drills that are most likely not truly valuable. Hopefully, champions of this process will then advocate and educate their business partners about the benefit of agile projects so that they can jointly invest in increased ability to sense and get feedback.
The confined organization faces a similar challenge to the chaotic one, but from a different direction. Rather than being unable to get feedback quickly, this organization can not reduce the cost of change to the point where they can implement changes at the rate that they are learning. They find themselves in this area when they start in the lower left area lacking both an ability to get feedback and an ability to change. They invest in a practice like Scrum and begin to put working product in front of internal users, stakeholders and maybe even customers. Ideas begin to flow incredibly fast and the team becomes lost in a never ending backlog that overwhelms their ability to deliver work. Or they learn important things about the system, but lack the technical capability to do anything about it. In either case, they now face a situation where they are able to get new ideas and better understanding of the problem domain, but unable to properly exploit it. Frequently this happens if organizations begin to embrace agile practices, but are not quite so aggressive in removing impediments and improving engineering practices. As the old saying goes, knowing but not doing is no better than not knowing. In this situation, hopefully organizations see the case for investing in their ability to change such that they have the technical capability to match their every changing list of requirements.
Implications of this Model
The single most important implication of this model – for better and worse – is the very transitional nature of an organization’s position on the map. The chaotic and confined positions offer prime examples of an inherently unstable position. They expose a major gap in an organizations capabilities and cause problems. In the optimistic situation, this apparent gap is correct and the organization continues to move to the top right part of the map. However, it’s quite possible that the organization decides the best way to deal with the uncomfortable exposure of their shortcomings is to simply stop doing whatever it is that’s exposing those shortcomings.
Additionally, if we consider this map a broad landscape upon which organizations may spend years moving, than we appreciate that the journey is profoundly important and it is not simply defining an ideal state to achieve. In fact, the changing nature of the marketplace as well as most companies indicates that even if you occupied the top right position a decade ago, the standard has changed. That which was once state of the art very well may no longer be so. Thus, the most important thing is continuing to move in the direction of increased capability to sense and respond. Right now several luminaries within the agile software development field are having a big discussion about two lean concepts: kanban and one-piece flow. The discussion brings up many good points in arguing the superiority of one-piece flow over kaban – indeed, the Toyota philosophy is to flow if possible, then pull (kanban) and only push as a last resort. However, the more important thing is the continued path towards improvement. A team embracing Kanban practices very well may be improving from their current state without getting into a discussion of whether or not this is the ideal longer term end state. Indeed most of the research on change management and learning shows that moving too quickly towards some perfect goal may very well undermine the change if it is too ambitious in the short term. Going back to the beginning of this article, the goal isn’t some absolute measure of agility, but rather one’s organization’s ability to continue to improve those capabilities such that it can out maneuver its competition.
I hope you find this model useful in conceptualizing that task and communicating it to others, and would welcome other’s perspectives.