Leveraging Agile Principles in IT Operations:3 of 4

Customer collaboration over contract negotiation

Agile Overview

The last post in this series outlined how you can get your arms around creating meaningful documentation using the Agile concept of maintaining working systems over comprehensive documentation, starting with identifying how you will be using the documentation.

This week we’ll look at the third precept of the Agile Manifesto: Customer collaboration over contract negotiation.

Identifying the Customer

Identifying the customer can be more complex than it seems, particularly when your customers are internal, as they are for many IT operations teams. Numerous articles have approached the topic of the business as the IT customer. Basically, your customers include anyone who comes to you for help with any of the services you provide. They are looking for you to add value to their request. They have come to you with an understanding that you are the subject matter expert.

There may be dissention from the lean camp regarding who the customer is, but the customer in this case is the group that provides us with capital based on the value received. This article will focus on operations departments that only support internal customers.

Most companies have a set process by which internal customers may approach the operations team for services, often filtered through the helpdesk. Others have a more informal approach that relies on various types of shoulder tapping or other uses of informal methods. Another approach is to embed operations resources within project or product teams.

Whatever engagement model your organization uses, it’s important for your team to know how customers might contact IT operations and exactly what services you can provide them. Additionally, if your process requires more formalized methods it’s beneficial to ensure all participants of the process follow that process consistently.

The Contract Approach

IT service contracts are used extensively by consultants and 3^rd-party service providers for various business-to-business needs. They’re valuable for defining factors such as time, cost and scope. They also set expectations relative to those factors. The common reason why this contract exists is because a contract is a legal binding between two independent and separate organizations. Without a contract there’s not a legally binding method of recourse should a disagreement occur. Furthermore, a contract will help two firms define the roadmap of their relationship and can provide details on the formalized components of the agreement.

Similar contracts are cropping up increasingly often between IT operations teams and their internal customers. A low-level type of internal contract is the Service Level Agreement (SLA). While I fully support the idea of establishing SLAs, I believe that following more elaborate contracts internally takes the concept too far for an agile and/or lean organization. Internal contracts are a bad idea for several reasons.

Contract Drawbacks

First, internal contracts cause division between IT and the business. When one group within a company can stonewall another by refusing help because a service isn’t listed in the contract, or because the service doesn’t fit the defined role of the IT operations person to whom it was assigned, it damages both the business (because of delays) and the relationship between operations and other parts of the business.

Second, internal contracts can’t be enforced. If a breach of the contract occurs, neither party has legal recourse for the violation. A process that includes portions that lack power is wasteful, particularly if those portions also limit the work that can be done to support the business. If an organization lacks discipline to the point that it requires an internal contract to get work done, then there are deeper issues that need to be addressed. A contract is almost never the right answer.

Third, a contract limits collaboration and the spirit of teams. A team structure and hierarchy are less important then most firms believe. What’s important is to realize that a team needs to have the right skills and relationships focused on value delivery, not the right contract. When the disparate divisions in a company realize that there is only one team and we’re all part of it, the productivity of the organization can increase dramatically.

Focus on Value Delivery

Agile thinkers and most Lean fundamentalists tend to have very effective relationships with their customers because of their focus on process for value delivery. Focusing a team on the most efficient way to deliver value should take precedence over writing binding contracts. Often this can only be done when there’s trust between all members of the teams. Trust is the outcome that emerges when efficient teams focus on value delivery rather than roles and responsibilities.

Communication

If the information a communication practitioner receives is flawed in any way – be it false, misrepresented, misinformed, or inapplicable to specific goals – then the remainder of the process is irrelevant: the disseminated message will be flawed.

When you concentrate on efficiency, your organization’s methods of communication should be prioritized as the number one focus for delivering value between two teams. Start by determining the most efficient process for your teams and then decide how your organizational culture can support a communication process which is empowering and value driven.

Looking Ahead

In part 4 of this series we will examine how the fourth precept of the Agile Manifesto, responding to change over following a plan, supports an IT operations environment.

Jen Browne and Patrick Phillips