Scrum, XP, Management and the Ethics of Agile Software Development

Collaboration and Competition: Balkanization vs. Bounded Cohabitation

Small collaborative groups often exist in isolation or in competition with other groups within an organization.

Unhealthy Competition: Balkanization1

This is the second pattern of collaboration that entrenches status quo (see Contrived Collegiality).

balkanize:

  1. : to break up (as a region or group) into smaller and often hostile units
  2. : divide, compartmentalize <now pop culture has been balkanized; it is full of niches, with different groups watching and playing their own things — Richard Corliss>

Balkanization

In a Balkanized environment, one team’s win is another team’s loss or, at least, one team’s loss is not every team’s loss.

A company that organizes itself by specialty and doesn’t matrix well to projects lends itself to balkanization but leadership can encourage politics under any structure if they distribute rewards based on unclear, unfair or arbitrary criteria.

Valuable learning in one group is not communicated or is disputed and not widely adopted. Managers drive to surface shows of success. Individuals are not encouraged to true joint work across organizational boundaries.

Agile is often introduced bottom up without executive sponsors in less than optimal cultures. In this context, development teams have dependencies on teams that do not buy into agile values. Developers are separated from decisions about opportunities, product portfolios, potential revenues, and product features. This is both a fragile place for agile teams and also diminishes opportunity for the company.

Healthy Competition: Bounded Cohabitation

Internal competition can be used to spur original thinking and organizational change.

Nonaka and Takeuchi describe a concept of “bounded cohabitation” where teams are set in productive competition with each team pursuing a different set of premises and value propositions all geared toward the same outcome.2

The example they use is detective work. One approach is to form autonomous teams around different premises: premeditated murder, crime of passion, accident, natural causes, etc. Let the teams self-organize assembling the appropriate numbers with relevant skills and experience for their specific premise.

The teams investigate independent of each other. Under their premise, each team may look past evidence others find relevant but also follow leads other teams wouldn’t think to pursue. Eventually, one team establishes the most plausible course of events. The shared outcome is met and the teams re-organize around the next investigation.

Japanese manufactures often form multiple engineering teams around the same design challenge; e.g., an engine meeting novel requirements of size, efficiency and performance. They adopt the best solution incorporating other good ideas into the current or future products.

In one case, Sony merged two teams pursuing different product strategies: (1) an evolution in video tape players and (2) a revolutionary digital non-linear editor.

Synthesizing those world views resulted in the digital video editor with engineer-friendly analog controls that broadcast centers could rack into their existing facilities. This new technology with a familiar form factor created a new market that Sony decks dominated.

An executive sponsoring agile adoption must strive for healthy internal competition. Carve out self-organizing teams. Encourage them to follow their own paths to a clear, common goal. Mutually agree upon performance measures. Retrospect across teams to determine what’s working and why. Allow for wrong paths, allow for variation and embrace the unexpected.

The concepts and examples in this post are drawn from:

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

2 Nonaka, I. and Takeuchi, H., Hitotsubashi on Knowledge Management, John Wiley and Sons, Asia, 2004.

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.

Design Levers in Collaborative Systems

Bronze Roughneck by takomabibelot on flickrAt HICSS-41, I heard a talk by Dr. Yochai Benkler on cooperation in human systems.

One aspect of his talk was design levers that influence how well a group of people cooperate.

As intrinsic motivators, Dr. Benkler listed: humanization, trust, fairness and solidarity. Extrinsic motivators were punishment, reward and transparency.

  • Humanization occurs when participants see others as real people with feelings, strengths and weaknesses, connection to others and history.
  • People are more likely to trust when they are themselves trusted prior to earning it. Trust requires risk. If nothing is at stake there is no need for trust. Dr. Benkler pointed to sociology studies that show when you reduce the need for trust you actually reduce trust.
  • A perception of fairness is closely tied to our reading of others intentions as much as outcomes.
  • Solidarity is cohesion and a sense of belonging. It’s bolstered when a group is self-governing and can be strengthened or weakened by an external threat.
  • Reward, punishment and transparency have complex and unpredictable effects on intrinsic motivators. Even correctly applied within a given cultural and group context, they may crowd out trust and solidarity as well as having mixed effects on human connection and perceived fairness of the system.

Managing collaborative groups requires iteratively inspecting and adapting.

Ruining it for the rest of us

A December episode of This American Life starts with an interview with Will Felps.

He placed college students on teams with an actor alternately playing a “jerk, slacker, and depressive”.

The “bad apple” not only wrecked the team’s performance, the other members began to think and act like him.

Here’s a Google book preview of Will Felps’ paper, How, When and Why Bad Apples Spoil the Barrel: Negative Group Members and Dysfunctional Groups

The existential joy of retrospection (agile practice)

Spiral JettyEvery two weeks as part of our Scrum practice my team holds a retrospective to ask:

  • what were our goals in the last two weeks,
  • what did we do that helped us achieve those goals,
  • what did we do that got in our way, and
  • what essential set of things we should we keep doing or do differently.

Retrospection is a process focused way of doing more and more of the things that are important and a less and less of the things that are not important.

And our efforts at inspecting and adapting are themselves a work in progress.

We need to rely on each others’ strengths to work past our own weaknesses.

We need to expect more of each other and to demand more of ourselves for each others’ sake.

We thread this path to trust and loyalty, to collaboration and self-knowledge, to craft and achievement.

ken h. judyI am an executive manager, software developer, father and husband trying to do more good than harm.
Working to spend each day doing a little less crap and a little more not crap than the day before. Without delegating my crap to others.
Aspiring to pride in my accom- plishments and pride in who I become as I attain them.
IEEE CSDP
CSP
I'm speaking at Agile 2012

Papers

Presentations

 

Site menu:


Meta

Creative Commons License

Post text is licensed under a Creative Commons Attribution - Noncommercial - Share Alike 3.0 United States License.

Unless otherwise indicated, Images in posts are not cleared for redistribution under creative commons.

Copyright © 2006-2012
Ken H. Judy.

This is a personal weblog. Views expressed are my own and not those of my employer.