A sign that says

Contracts Define Who Is Authorized!

We complete our tour of the reputed places agile fears to tread with a brief stop in the land of contractual relationships. Outsourced work is the primary denizen of the land of contracts. In all but the simplest scenarios, asking another firm to do work for you generates a contractual relationship. In most cases, the contract is a proxy for intimacy and trust that occurs inside a single organization. Fences make good neighbors to keep relationships orderly; in the business world contracts take the place of fences to establish boundaries. Boundaries constrain the free flow of information and ideas, which is antithetical to agile principles. There are four core reasons organizations and practitioners see issues fitting agile into an environment of contracts and outsourcing. None of these issues is insurmountable, but they must be fully addressed in the contract. They are: Transparency – Contracts establish boundaries and obligations between the parties. Obligations are often tied to payments and in some cases performance incentives and penalties. All of the parties in the contractual arrangement a variety of goals beginning with the delivery of an output, maximization of profit by the outsourcer and minimization of expense by the outsourcee. All goals in a contract, taken together, generate a behavioral equilibrium so that everyone gets what they need. Unfortunately, not all behaviors are useful which makes sharing information less likely. A classic example is a scenario where someone is over budget or behind schedule but thinks they can fix the problem. In this case, they feel incented to avoid the pain of exposure until they know they can’t fix the problem. Contracts exacerbate this issue.
Solution: Before the contract is signed: build participation required by agile for all parties into the contract. The product owner must be from the outsourcer, the outsourcer needs to take part in all planning activities, involve the product owner (or proxy) in the daily stand-ups, and they should have access to backlog management tool. After the contract is signed: involve the outsourcer in the demonstration and the team is adhering to their definition of done.

  1. Access – Interactions between team members and the business are often constrained. In many cases, point people are identified for each part.  These people act as a funnel for all conversations and decisions. This is often done as a configuration management technique.  Only the identified point people can accept inputs or changes to the scope of work or tweaks to the requirements. Access is a specialized form of transparency. Agile principles and techniques explicitly assume that the team(s) have access and interact with the business daily (sometimes stated as continuously). Also, agile expects the product owner (from the business) to manage and prioritize the backlog.
    Solution: Before the contract is signed: explicitly build agile roles into the contract. For example, build the product owner role (part of the business) into a contract as part of the team. Identify the need for intimate, daily (or close) communication with the team. In the contract make it OK for team members to talk with the business without a chaperone. If at all possible, embed the product owner and/or subject matter experts with the team (full time if at all possible). After the contract is signed: this issue is more difficult to solve post-contract. One possible solution to generate the conversation between the team and the business is to embed the product owner and/or point persons with the team at least on a part-time basis. This fix generates conversation by forcing access. In the longer-term embedding helps to foster trust.
  2. Delivery Cadence – Agile techniques expect that the team will deliver “potentially” implementable functionality on a periodic basis. The periodic delivery gets value to the client sooner and provides a feedback mechanism. Many contracts only recognize value by the final outcome. The contact views anything else as a distraction that might take the focus away from the real payout.
    Solution: Before the contract is signed: build delivery on cadence into the contract. After the contract is signed: deliver on cadence and map the stories (or work units) delivered to the ultimate goal of the contract. By linking each delivery to the ultimate goal in the contract everyone involved will stay focused on the contractual obligations.
  3. Trust – Contracts are tools to explicitly define the obligations of all parties in lieu of trust or a handshake.  A contract is a form of enforced trust because the penalties for breaking the contract are painful. Agile assumes that the parties have a common goal. The common goal creates an environment in which everyone involved has a clear understanding of how the team and business will behave.
    Solution: Before and After the Contract is signed: establish a common goal. Recognize that each party might have other goals that conflict. State the conflicting goals and made them subservient to the common goal. If team members believe that there are ulterior motives, trust will be elusive. Use embedding, joint planning, and retrospectives to make a contractual relationship more agile.

Contracts are tools to create fences. Most agile principles and techniques get rid of fences between the business and the team or between the oursourcee and the outsourcer. Contracts can explicitly prohibit interaction or they can create scenarios where participants are afraid to interact. When a contract has been signed it is difficult to renegotiate the contract and embed agile techniques. Adopt techniques such as joint planning, attending demonstrations and stand-up and sitting with the team (even if it is just occasionally) to help build trust and inculcate agile principles.