BT

Successful Collaboration Doesn't Happen by Accident

by Deborah Hartmann Preuss on Jan 02, 2008 |
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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Excellent Article 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.

Re: Excellent Article 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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT