Agile — Customer Collaboration

This is part 3 of 4 of my series on the principles presented in the Agile Manifesto. If you are jumping into the middle of the series, these blog articles are intended to share my perspectives on the Agile Manifesto and what it means within the context of an organizational Agile Transformation. I will write other articles on more practical applications of Agile practices. This series is a bit more theoretical because I believe it is extremely important to establish the context for Agile before attempting to implement specific Agile practices.

For review, the first 2 principles discussed in my previous blogs were:

· Valuing individuals and interactions over processes and tools

· Valuing working software over comprehensive documentation

Today we will talk about valuing customer collaboration over contract negotiations. This one might seem like a very easy concept and not worth dedicating a whole article to, but sometimes, leadership principles that seem obvious can also be very difficult to apply. In this case, I’ll suggest that the argument for customer collaboration over contract negotiations is a principle of “together” versus “separated”. Collaboration is defined as working together. A contract is an agreement between 2 parties. The distinction is not hard to grasp. So why is it so hard to do in many organizations and called out in the Agile Manifesto?

If we think of traditional software development and Software Development Life Cycle (SDLC), the processes were serialized.

SDLC

A contract, established at the beginning of the process, defines what we were going to do and how we were going to do it. All major decisions are made at the beginning. Agile development, and the collaborative approach, suggests that decisions are made continuously throughout the process. We do some work, deliver working software, learn some things, reassess what we are doing and then do some more development work. With each iteration of working software there is an opportunity to work with the customer to make joint decisions about what we are doing and how we are doing it. Priorities can change, requirements can change, and new ideas (some good and some not so good) emerge as development progresses.

For me, the phrase “contract negotiations” suggests two sides with different interests trying to find common ground through compromise. I hate writing contracts because there’s always this sense of defensiveness. I’ve got to watch every term and condition to make sure I’m not getting screwed or signing up for something that will bite me later. Contracts are necessary and I’ve been involved in writing many of them, but I truly don’t enjoy that aspect of my business.

I enjoy tremendously sitting down with a customer and talking about what they want and why they want it. Customer collaboration is about an ongoing dialog. I also want to point out here that the term “customer” can have many interpretations. For me, in the context of the Agile Manifesto, “customers” generically refers to any or all stakeholders. The term “contract” can refer to any commitment between the development team and the stakeholders. A Sprint Plan is a necessary and important form of a contract used in Scrum. Not all contracts or commitments are bad. Remember that the Agile Manifesto states, “while there is value in the items on the right, we value the items on the left more.” The key is to not let the negotiation of agreements cause a sense of separation. We don’t want a contract between 2 parties (stakeholders separated from the development team). We want one team working together to achieve the desired results. That is the point of valuing customer collaboration over contract negotiations.

In conclusion, valuing customer collaboration over contract negotiations is about people. It is about getting people to work together, side by side, so that decisions can be made together as new information is available and discoveries are made. I’ve previously described Agile as chasing a moving target and advised you to use all your senses, including those of your customer, so you make the best decisions when the right information is available.

The next article in the series will tackle the forth principle from the Agile Manifesto: responding to change over following a plan. I look forward to your comments on this article and the others in the series.