Successful Collaboration Doesn't Happen by Accident

Posted by Deborah Hartmann on Jan 02, 2008 06:00 AM

Community

Agile

Topics

Leadership ,

Stories & Case Studies ,

Collaboration ,

Customers & Requirements

Tags

Complementary Practices ,

Management

Partnership Coach Michael Spayd has written an article for InfoQ suggesting that both contractors and permanent employees can find themselves playing a "consultant" role when working on projects, and should consider developing consulting-type contracts with their clients. This is different from the way the term "contract" is commonly used: as a legal device between a provider of services and a client. While Agile teams engaging contractors still need such agreements, Spayd's article takes contracting in a whole different direction: his "Designed Partnership Contract" is not about the exchange of money, but is used to create a good climate for collaboration with a client, while allowing the "consultant" to communicate and honor their own values and preferences.

Spayd combines Peter Block's "consulting contract" with the concept of "conscious intentional relationship" which is part of the Center for Right Relationship's "Relationship System Coaching" program. Block's idea isn't new - his book,  Flawless Consulting,  was first published in 1980 and revised in 1999. And yet, the idea seems to be new to many in the world of software. Perhaps the shift from IT as "cost center" to Agile's value-delivery model, wherein IT is seen as an partner for achieving business ROI, is allowing us to rethink these relationships so critical to our ability to deliver that value.

Block's consulting contract is, first and foremost, meant to be a social contract, providing “explicit agreement of what the consultant and client expect from each other and how they are going to work together.” Still, it seems odd to focus on the idea of contracts, when the Agile Manifesto clearly prefers "Customer collaboration over contract negotiation."

I asked Michael Spayd about this negotiation/collaboration dichotomy:

The idea of a consulting contract, as Peter Block originally wrote about it, is entirely based on the premise of collaboration between client and consultant. I wanted to go with Block's original term, despite the fact that within the Agile community it can be a loaded term, even a negative one. I'm counting on a bit of charity from my readers - I think they, and others, will find the ideas quite consistent with Agile values.

Spayd's article tells the story of how one internal team developed a contract, and lays out the key activities and benefits of this approach for both consultants and employees. Read the InfoQ article: The "Consulting" Contract - A Primer for Consultants Knowledge Workers.

---

Other resources: at Agile2006 Michael Spayd and his colleague Joseph Little spoke to InfoQ in an interview about the challenges of Agile Teams in Traditional Organisations: Time for Change.

1. Back to top

   Excellent Article

   Dec 31, 2007 12:38 PM by Javid Jamae

   Michael, this is an excellent article. It lays out a great strategy for forming a team and initiating collaboration with business stakeholders and customers. As a precursor to the conversations you've described, I've found some advice in "Teamwork is an Individual Skill", by Christopher Avery, that I found very useful. Avery recommends that the very first conversation that a team should have is to "establish shared clarity about what the team was formed to do". He recommends that "each member should be able to explain simply and clearly what the team is accountable for [collectively]". In addition to talking about much of what you have in your article, he pushes this as an important first step.

   Reply

2. Back to top

   Re: Excellent Article

   Jan 2, 2008 1:58 PM by Michael Spayd

   Hi Javid, Thank you for your comments. I agree with you and Christopher. You point out that the article joins the timeline after the team has already (presumably) created its own designed partnership alliance (DPA), where they made agreements about how to work with each other and with clients. Now, they are acting on this DPA in how they go about creating the Designed Partnership Contract with their client. I would suggest, in addition to the "do" question that teams also prioritize the "be" question: "what the team was formed to do" coupled with "how the team wants to be with each other" are both essential to high performance team functioning. The later may look like fluff to some, but in my experience it is at least implicit within great teams. Making it explicit pushes teams up the performance curve more quickly.

   Reply

• Older >