Tag Archives: product owner

Bounded Collaboration

Posted on by

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.

Contrived Collegiality

Posted on by

This is one of three patterns of collaboration that entrench status quo.

“The unpredictable nature of collaborative cultures can lead administrators towards forms of collegiality which they can control, regulate, and tame.” 1

Contrived Collegiality

People in leadership roles often resist honest and open exchange. They don’t want change. They want it done their way. They fear loss of influence or status. They dislike confrontation. They feel external pressure. They are proud, defensive, in denial, or simply insecure.

With a courteous, professional veneer and a stated goal of collaboration, they suppress equal participation by:

  • controlling the schedule, conversation, or process,
  • withholding or misrepresenting critical information,
  • defining the collaborative task or roles too narrowly,
  • overly constraining allowed responses or behaviors.

Within an agile context, a product owner can prescribe a solution then use the agile planning to solicit a limited range of responses:

“Is it feasible?” “How long will it take?” “How much will it cost?”

All Scrum guarantees is that these questions will consider a manageable chunk of the application. But whether it’s a user story, minimum marketable feature or a full specification these questions fail to engage the life experience and passions of the team to addressing the core problem or opportunity.

Go on to create an environment where contrary thinking is a problem, define “buy in” as a lack of visible dissent and you’ve placed the development team in a black box they cannot see out of and you cannot see into.

Contrived collegiality leaves the product owner out on a limb. You’ve limited the chances of anticipating risks, redefining the opportunity in some dynamic way, and invention at any but the tactical level. Despite agile processes and a surface of collaboration, you are relying almost solely on your own abilities to avoid, as Mike Cohn says, “the wrong thing, on time and on budget.”

1 Hargreaves A. and Fullan M., What’s Worth Fighting for in Your School?, Teacher’s College Press, New York, 1991.

Collegiality Versus Collaboration: Getting our Hands Dirty

Posted on by

Merriam-Webster Online defines:

collegiality as, “the cooperative relationship of colleagues.”

collaboration as, “to work jointly with others or together especially in an intellectual endeavor.”

In the article, Norms of Collegiality and Experimentation: Workplace Conditions of School Success, Judith Warren Little places true collaboration at the end of a continuum of collegial relations.

Starting from weakest to strongest:

Of these four, only joint work is “strong enough to contribute to a collaborative culture of enduring benefit.”

Joint work is the sharing of tacit knowledge. Tacit knowledge is acquired through experience but difficult for the holder to express in words. It is core to craftsmanship and mastery.

Tacit knowledge is transfered when we work in collaboration with another person. In The New Product Development Game, Nonaka and Takeuchi call this “osmotic” learning and consider it the first phase in the organization knowledge creation process.

Nonaka and Takeuchi describe how attempts to design the first bread maker failed miserably until an engineer apprenticed herself to a baker, learning by doing the movements required to kneed great bread. She took that learning back to Matsushita, devising a paddle system that became an essential innovation in a wildly successful, new class of home appliance.

The relationship between product owner and team in most agile projects is certainly collegial. We communicate by story telling. Participants make themselves available to help each other. We share explicit knowledge across business and technical domains as best we can. However, all of this falls short of true collaboration.

The lesson I take away is if we want to foster creativity and innovation we need to get past the barriers of status and roles, go beyond talk, roll up our sleeves and labor together — joint investment, joint consequences, and joint work.

If it ain’t this, it ain’t Scrum

Posted on by

Jeff Sutherland has an interview on InfoQ where he describes the Nokia Test for evaluating whether a team is practicing Scrum:

Iterative Development
A precursor to Scrum is practicing iterative development of any kind.

  1. Fixed iterations of not longer than six [weeks]1
  2. Working software at the end of each iteration
  3. Start iterations without requiring a “complete” specification
  4. Testing during rather than at the end of iterations

Jeff states, “this rules out about half of (self-identified) Scrum teams.”

Scrum
The minimum to foster self-directed development teams working to clear business priorities using the tracking mechanisms of Scrum.

  1. Got a product owner? A single, empowered person who works directly with the team to determine what to build.
  2. Does the product owner have a product feature backlog? Is that backlog prioritized by business value? Is it estimated by the team?
  3. Track work with a burndown? From that, can you derive a velocity?
  4. Hands off during an iteration? “Nokia has a rule that you can’t have a project manager interfering with the team in the middle of an iteration because that stops the self organization.”

Jeff’s been saying for years that if you don’t have a backlog, you don’t have Scrum.

The first thing we lost in the acquisition process was our product owner. From there the rest deteriorates. Without a strong, empowered product owner the backlog becomes arbitrary and so does planning work against that backlog. See what that does to talented developers used to fueling themselves on intrinsic motivation.

It will be at least as hard to re-build these practices as it was to build them in the first place. The work of the new year and perhaps many years to come…

1 corrected from six months to six weeks.

Collaboration and Product Ownership

Posted on by

I’m presenting a paper, Great Scrums Need Great Product Owners, at the Hawaii International Conference on System Sciences.

The presentation is part of the Agile mini-track co-chaired by Jeff Sutherland and Hubert Smits. I co-authored the paper with the senior member of my product team, Ilio Krumins-Beens.

We survey literature to describe pragmatic and collegial relationships which satisfy the definition of collaboration and honor roles while barely tapping or actually working against the potential of a project and its participants. These limited forms of collaboration are common not just in our industry but within agile projects.

A common interpretation of the call for a single Product Owner is that the development team itself should play little part in shaping the vision and value priorities of a product backlog, focusing instead on efficient delivery of those priorities.

One of our major sources are the What’s Worth Fighting for series by Andy Hargreaves and Michael Fullan on collaboration in education.

The disempowering climate faced by teachers is a direct parallel to that faced by software developers disengaged from the business vision and value priorities of their work.

“… [W]e have collectively 45 years of teaching experience and nobody has ever asked us our opinion about anything where it would actually be put into action. And yet I’ve got to have more experience with junior [children] than a lot of the people who are telling me what I should be doing with them. And I think that is very frustrating… I think I could help bring a lot to it and nobody ever asks, no one ever asks what we think. They just go ahead and proclaim and we have to follow.”

Its tragic how talented, experienced people are not allowed to bring their full selves to their work.

We contrast this with unbounded collaboration between a product owner and team. In unbounded collaboration an individual’s contribution is not constrained by their role or status.

It is a collaboration built upon high-performance, mutual respect and deep trust. The product owner walks a tight rope, engaging the team in an evolving product and business plan while guiding the project toward her vision and high-level goals. The team is passionate about the product they are building and feel personally accountable to the product’s success.

We argue that this kind of collaboration is at the heart of agile values and is a characteristic of the knowledge-creating companies upon which lean principles are based.

I’ll write more about unbounded collaboration, it’s opposites, practices we’ve used and what we’ve learned.