Contrived Collegiality

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

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.

The Scrum Master’s Dilemma

My daughter Miya and dog friend Sophie 2002 by kjudy

A metaphor for the Scrum Master is a vigilant sheepdog protecting their flock.

At the Fall Scrum Gathering, I met practitioners facing different challenges in their agile practice.

Some faced profound impediments that their organizations were unable or unwilling to address. The effect on the project and team was dire and the Scrum Master had exhausted all avenues to raise alarm.

It’s human nature, unfortunately, to associate an unpleasant message with the messenger. A vocal Scrum Master can be seen as the problem.

In those fraught circumstances a Scrum Master has to balance the interests of the team, the company and themselves. Can the project deliver in spite of the obstacles? Should the Scrum Master accept the dysfunction or not? At what cost?

As Ken Schwaber says in Agile Project Management with Scrum, “A dead sheepdog is a useless sheepdog.” Still, a useless sheepdog is also a useless sheepdog.

As JP Boodhoo says, “develop with passion.” As my friend Luke Melia says, “live with passion.”

Our Team Room

XP Team Room by kjudy

Things we did right:

  • laptops
  • table with two tier top so laptops can sit under the surface
  • dual monitor setups
  • build bunny
  • video projector at center of table
  • room for product owner and scrum master at ends
  • big whiteboards
  • big corkboard
  • wall space for bulletin board sized post its
  • team picked colors
  • space invaders
  • poster board sign for ript
  • webcam
  • purell, handwipes, tissues, and hand lotion

Things we could have done better:

  • private space in the corners
  • better way to leave phone messages for team
  • more webcams/better video conferencing
  • kept killing plants
  • needed a cleaning person
  • better HVAC

XP Team Room by kjudy

Leadership, Circumstances, Styles of Play

John Maeda has another post on leadership.

“In movies we often see two scenarios: 1) the leader is surrounded by her soldiers as a wall of protection; or 2) the leader is the one that is the first to rush into battle.”

I have trouble with war metaphors in a time of war but I get that success is built upon both protecting potential and creating it.

This sentiment reminds me of Garry Kasparov’s description of his chess play, attacking, aggressive, “where the player who makes the first mistake loses” versus a maneuvering, defensive style that “accumulates small advantages over time.”

I have played the latter, quiet game, advancing through various roles and towards an agile organization over years.

Still more chess pieces by andrew_mrt1976'sMy game was winning over peers, demonstrating success, removing many obstacles and flowing past others, educating executives as they became receptive to it, and, above all, showing by doing — proving value on our terms by delivering value.

But as Mr. Kasparov points out, circumstances may require us to adopt alternative styles and I am clearly in that situation now.

My company may soon be integrated into a larger one. In that larger organization, I have met conscientious, competent people. If the acquisition goes through, they will work to realize as much benefit as possible while managing risks and minimizing harm.

However, drastic change will need to happen in a short time and there are three very different cultures at play: that of our team, our current employer and our prospective new one.

Time is a factor in another way as well. My team cannot endure setting the clock back on our product and software development practices. Agile development means little unless it is in partnership with an agile business. We don’t want to just build things well. We need to invent, serve users and win in the marketplace. We need it all.

If circumstances call for a more pressing style of play. So be it.