Exclusive updates on:

The "Consulting" Contract

Posted by Michael K. Spayd on Dec 30, 2007 |

10 Key Guide Points for Continuous Delivery

How do you Develop a Shared Understanding on an Agile project?

Continuous Delivery: A Maturity Assessment Model

How do you estimate on an Agile project?

Agile Executive Primer: Partnering Across the Organization

Related Sponsor

Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.

Related Editorial

Hello stranger!

You need to Register an InfoQ account or 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

Community comments

Excellent Article by Javid Jamae Posted

Re: Excellent Article by Michael Spayd Posted

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.