Harmonizing IT
Today's IT solutions are complex integrations of custom developed components, business products such as CRM and ERP systems, and technical products such as networks, databases, and messaging stacks.  Given this complexity, maximizing the responsiveness of application development is potentially futile if the rest of IT doesn't follow suit.  For example, if environments can't be rapidly instantiated, databases rapidly refactored, code integrated with commercial-off-the-shelf platforms, and testing parallelized, injecting Agile practices simply creates an application development capability that is hindered by, and potentially arrogant and demeaning toward, its IT peers.  In the worst case, it shifts the blame in a sub-optimal IT department from "the developers" to "the network people" or "the QA people."  Passing the buck isn't particularly helpful.

The same practices that engender responsiveness in application development are portable to other IT disciplines.  For example, Agile requirements, called "Stories," are simple, independent expressions of work that are testable, have business value, and can be estimated and prioritized.  Stories are a useful way of expressing and tracking activity anywhere in an IT organization.  The same is true for unit testing:  technical tasks such as server reconfiguration and database refactoring can be approached by writing tests that can be repeatedly executed and automated.  Other concepts, notably simplicity of design and Agile project management, can be brought to bear in most technical disciplines.

Consider the following:  Suppose that a retail brokerage operation had the following requirement:

As the director of non-commission retail trading, I want to reduce on-line transaction failures due to service interruptions by 98%.  I will know this is achieved by tracking failed transactions during unscheduled downtime events.  Every percentage reduction in transaction failure represents an annualized business value of $150,000.

The IT solution may be the implementation of improved load balancing and server failover.  In this example, an infrastructure project with no application development component can be delivered, managed, and tracked using practices that engender agility.

The business requirement can be decomposed into a collection of infrastructure tasks.  Progress can be tracked and reported with the same Agile project management practices common to application development.  Tests can be written and automated.  Business collaboration is facilitated by a clear business goal and success criteria.  Clearly, then, Agile practices can be applied to other parts of IT, and contribute to increased responsiveness.

Harmonizing Business Activity
Aligning IT for responsiveness is important, but it's less than half the battle. IT is only as effective as the organization that consumes it.  A highly responsive IT department working with an unresponsive business is an organization working at cross purposes: each will be frustrated, insisting the other fails to provide it with what it needs to succeed.  Having IT outpace its business partners is not an improvement, but an invitation to open hostility.  When adjusting IT practices to be more responsive, several characteristics of the business must be considered.

First, does the business have the time to work on IT solutions?  Agile practices require a high degree of collaboration with those who represent business needs.  Collaboration in an Agile process context is not an asynchronous channel for the business to dictate to IT what it wants done, but a fluid, active, and bi-directional relationship.  For every point where IT receives direct information from the business there is an equal point at which IT provides content for a business response.  For example, business users must not only express requirements in an engaged analysis process, but must also verify the definition of acceptance criteria for each.  IT must look for ways to maximize the availability of business partners and knowledge and adjust expectations for delivery to match the rate of requirements elicitation as needed.

Second, does the business have the expertise to develop IT solutions?  Business responsiveness is achieved with rapid delivery of functionality that is both important and complete.  This requires that the people representing the business needs can speak with authority and accuracy.  Business users who execute tasks in existing systems without fundamentally understanding why they perform those tasks are not likely to understand the overall business problems they face. As a result, they will probably not be able to provide business expertise.  This will undermine both the elicitation of requirements as well as the verification that delivered solutions solve actual business problems.  It is very risky for IT to assume the dual role of "solution provider" and "change agent."  IT must demand that business leaders to provide operational vision and take the necessary business decisions necessary to achieve that vision.

Third, can the business itself consume frequent change?  Even if iterative delivery reduces the size and impact of change events, a high frequency of incremental change can be disruptive. Will users have and make the time necessary to receive training on and master new features and functionality of delivered systems?  Will users in customer-facing roles be able to speak expertly on new functionality or will there be an inconsistency?  Can other operational changes keep pace?  Pacing production to match consumption is necessary if IT is to be a positive factor for responsiveness.

Harmonizing the Organization
Even with a fully aligned IT and the active buy-in and engaged participation of the business, there are organizational barriers that can impair the best of efforts to be responsive.

The bureaucracy in which many businesses have robed themselves in the name of "risk mitigation" or "compliance" can completely crush responsiveness.  Perhaps most commonly, bureaucracy slows business services such as procurement to a crawl.  This has a direct impact on IT, for example, by making multi-sourced IT solution fulfillment very difficult to orchestrate.  But business process inefficiency also has a broader effect on an organization.  Redundancy grafted into core operating processes is an indicator that the people in operations roles are not fluent in what is actually required to meet compliance requirements.  It is also an indicator of a lack of understanding and confidence by people in accounting and finance roles that core business processes can inherently minimize risk and be in compliance.  By way of example, a company with manual business processes to create a Notice of Invoice doesn't have them because of Sarbanes-Oxley requirements, it has them because nobody has figured out a less invasive way to provide transparency as it pertains to billing in the organization.  The net effect of excessive bureaucracy is that it can easily confuse people's fundamental understanding of core business processes, thus undermining their ability to express business needs and priorities.

In addition, a risk averse culture will stifle responsiveness.  Provided lessons are learned and internalized, making mistakes, even a lot of mistakes, is preferable to trying to avoid mistakes at all costs.  The Agile practice of retrospectives - looking back over a period of time to ask all participants to publicly state what went well, what went poorly, what has people confused, and they would like to change - is an exercise in continuous improvement, not an exercise in CYA.  If the retrospective becomes an opportunity for people to disguise organizational deficiencies (e.g., the inability to properly initiate a project or execute fundamental business best practices), the participants are gaming the retrospective, not engaging in an exercise of continuous improvement.

There Is No Shortcut to Organizational Responsiveness
These business and organizational factors are serious issues that inhibit responsiveness.  IT can compensate for business inadequacies by nominating proxies for the business knowledge and making deliveries to production which may or may not be used.  However, these compensations are not durable, and amount to quick fixes that put results at risk or game performance indicators.

The organizational factors are much more serious.  In the broader context, IT and its business partners risk serious penalty (including fines and termination) if they side-step corporate processes such as procurement or compliance.  Similarly, an organization in denial of the need to continuously improve is not going to deal with mistakes in a mature manner.

An IT department promoting greater responsiveness must look to patiently engage changes.  It can do this by:

• Insisting that business leaders commit to achieving IT results.

• Educating business partners how Agile processes work to deliver business value to the organization.

• Identifying knowledgeable business partners and gaps in business knowledge.

• Promoting compliance or regulation training for business participants.

• Identifying points and process of escalation to executive management who value responsiveness.

None of these are in the domain of the IT department. IT must expect to work in partnership with the business to resolve basic obstacles.

Agility is an Organizational State, Not an IT Characteristic
Either responsiveness is an organizational value, or it is not.  If it is not, it is beyond the reach of an IT department to bring it about.  But because IT only as effective as its solutions perform in the business environment, this issue cannot be ignored.  Recognizing points of actual and potential organizational disconnect allow IT departments to have constructive peer-level discussions with its partners to bring about change.

About the author
Ross Pettit has 15 years' experience as a developer, project manager, and program manager working on enterprise applications. A former COO, Managing Director, and CTO, he also brings extensive experience managing distributed development operations and global consulting companies. His industry background includes investment and retail banking, insurance, manufacturing, distribution, media, utilities, market research and government. He has most recently consulted to global financial services and media companies on Agile transformation programs, with an emphasis on metrics and measurement.  He is a frequent speaker and active blogger on topics of Agile management, governance and innovation.  He is currently a Client Principal with ThoughtWorks.