Bounded Collaboration

This is the third pattern of collaboration that entrenches status quo.

Contrived collegiality” and “balkanization” suggest a certain amount of bad faith. Bounded collaboration is a subtler dysfunction.

A pragmatic and collegial relationship between a product owner and team can honor roles and feel like collaboration while barely tapping or actually working against the potential of a project and its participants.

We may simply define our contribution too narrowly.

Bounded CollaborationA development team may communicate to a product owner only during formal inspection points. They limit co-work to the immediate needs of the project and not range to larger questions and concerns. Under the pretext of “single, wringable neck” they shield themselves from the struggle to shape a business outcome and stand at a distance from the product owner.

“Bounded collaboration rarely reaches deep down to the grounds, the principles or the ethics of practice. It can get stuck with the more comfortable business of advice giving, trick trading and material sharing of a more immediate, specific and technical nature. Such collaboration does not extend beyond particular units of work or subjects of study to the wider purpose and value of what is taught and how. It is collaboration, which focuses on the immediate, the short-term and the practical to the exclusion of longer term planning concern.” — A. Hargreaves and M. Fullan

Seeming collaboration limits business opportunity and works against sustained invention and true innovation. “Contrived collegiality” and “balkanization” are forced upon us but what boundaries do we ourselves create? To what degree do we champion agile practices while surrendering the values that inspire them.

Jeff Sutherland cites the exceptional Borland Quattro Pro development team as a significant inspiration for what became Scrum practice. He also points out that Quattro Pro didn’t win in the marketplace.

Superior technical execution and transparency to a single, empowered product owner is not, unfortunately, enough. We developers need to move beyond how and when to engage a broader set of questions over what, for whom and why.

We need to work jointly with our product owners to understand the opportunity, the end users and the value our software brings to them.

This entry was posted in scrum and tagged , , , , , , by Ken Judy. Bookmark the permalink.

About Ken Judy

I am an executive manager, software developer, father and husband trying to do more good than harm. I am an agile practitioner. I say this fully aware I say nothing. Sold as a tool to solve problems, agile is more a set of principles that encourage us to confront problems. Broad adoption of the jargon has not resulted in wide embrace of these principles. I strive to create material and human good by respecting co-workers, telling truth to employers, improving my skills, and caring for the people affected by the software I help build.