“Doc” List and I proposed an ethics open space for Agile 2008.

We all experience pressure to compromise our work and our reasonable care for others. As software becomes more beneficial, more pervasive, and inter-connected, our potential to harm grows.

Agile practices are making a contribution to ethical practice in our field, but we can and should be doing more to help each other navigate the ethical dilemmas we face.

This session will attempt to frame professional ethics in the context of agile values, make the community aware of the regulatory environment we may face from both state governments and standards bodies, and engage the participants in a conversation about how our day-to-day actions affect our employers, customers, peers, end users, and society.

Here’s the proposal http://submissions.agile2008.org/node/1573. Please rate and comment!

Posted: January 28th, 2008 under Uncategorized.
Comments: 3

Team managers should till the soil with their teams.

Anything else is waste and waste must be rooted out.

Still it is hard.

Luke Melia wrote about how he performed as functional manager and dedicated 75% of his time pairing.

There are two tremendous challenges with this.

The first is limiting distractions in order to remain a reliable contributor.

Luke has tremendous reserves of focus and enthusiasm. As his manager, I did everything I could with our scrum master, Salim Divakaran, to support him, remove distractions and share workload.

The second challenge is being both the boss and a peer.

Luke recruited most of the team, he held weekly one on ones with each person, he insisted on unvarnished feedback, and is worthy of respect as both a peer and a manager.

So, here is the pattern: An experienced coach with people skills and authority over development practices pairing in with the developers. An experienced scrum master. Functional management residing in one or the other or divided up in some sensible and easily described way among the two of them.

This enables direct participation in the work, management attention to the team, and strategic contribution to the rest of the company.

Posted: January 28th, 2008 under Uncategorized.
Comments: none

My colleague, Wendy, posted a quote from our former CEO describing the benefit she gained from collaborating in an Agile environment.

The way to win over an entrepreneur is to out-perform expectations set from painful, past experience.

Before Scrum/XP

…six months later, they deliver what the assignment was. And you look at it and say, “Oh no, that’s not what I wanted.”

With Scrum/XP

…you work on a two-week cycle… You agree on what the priorities are in the meeting. You review the priorities. You evaluate where you are, and you move to the next step…

Posted: January 25th, 2008 under Uncategorized.
Comments: none

Jeff Sutherland said he was finding more developers who will only work in agile software development teams.

He also said that to his estimation about 10% of shops that claim to be practicing Scrum pass the Nokia test and have self-organized teams, product backlogs prioritized by a product owner and estimated by developers.

And that doesn’t even speak to refactoring, test driven development, pairing, continuous integration, built in quality, acceptance testing, etc.

And that doesn’t speak to knowledge creation and sharing practices across the entire organization, clarity of vision, understanding competitors, collaborating with customers, continuous improvement, and embrace of change.

I’ve come to understand that agile values place demands on development, management and business practices.

Two questions arise from this:

• Would you only work in an [agile] shop?
• What do you mean by [agile]?

for [agile] feel free to substitute: Lean, XP, Scrum, XP/Scrum, Crystal, Adaptive, etc. etc.

Posted: January 19th, 2008 under Uncategorized.
Comments: 1

• Small is better than big
• Great teams are better than star individuals
• Courage and heroism are different
• Earning reputation is better than acquiring status
• Agilists in a non-agile business are not agile enough
• Your career is more important than your job
• We crave human contact with the people who use our software
• We can earn wages and be fair, honest, and worthy of trust
• Robbing people of joy is evil
• There are worse fates than being a dead sheepdog

Posted: January 11th, 2008 under Uncategorized.
Comments: 2

I just presented Ilio Krumins-Beens’ [and my paper] on unbounded collaboration between the product owner and development team at the 41st Hawaii International Conference on System Sciences. (I’ll link off to the paper when the transaction is published on the IEEE site.)

HICSS is an interesting mix of academics and practitioners. On the list of presenters in the agile mini-track were Jeff Sutherland, Stephen Cohen from Microsoft, and Gabrielle Benefield from Yahoo as well as researchers Ann Fruhling from the University of Nebraska at Omaha, Kevin Kwiat from the Air Force Research Laboratory, and David F. Rico.

HICSS is an instance where the academy has invited us developers into their living room to discuss what we do, the way we actually do it.

There’s a huge disconnect between what I practice as a software developer and what many institutions of higher learning teach.

Theoretical exercises in waterfall practices are not helpful precursors to TDD, pairing, continuous integration, refactoring, interdisciplinary collaboration, self-organizing teams, etc. etc.

Arguably, they are not even helpful precursors to waterfall as it’s actually practiced. If you think XP requires experienced developers what the heck do you get when you make someone with little experience architect a market trading system in UML!

We need the academy to understand us. They not only train our workforce, their research informs policies, standards and business management practices that shape government and industry expectations.

We need business schools that train prospective CXO’s to build lean businesses that will in turn build out agile/lean IT and product development organizations.

Another big barrier to agile adoption is lack of empirical support for the benefits of specific Lean, Scrum and XP practices. We need original research that correlates to the obvious things: quality, risk mitigation, market performance, productivity and cost reduction.

I’d also really love to see original research on how agile, highly collaborative practices correlate to ethical behavior on the part of individuals and organizations, gender and ethnic diversity, and sustained innovation.

Posted: January 10th, 2008 under scrum.
Comments: none

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.

A 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.

Posted: January 2nd, 2008 under scrum.
Comments: none

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

Unhealthy Competition: Balkanization¹

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>

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.²

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:

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

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

Posted: December 23rd, 2007 under scrum.
Comments: none

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.” ¹

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.”

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

Posted: December 21st, 2007 under scrum.
Comments: 3

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:

• Storytelling: Learning flows in one direction communicated as anecdotes not directly connected to the hearer’s experience.
• Help and assistance: Assistance provided only on when asked for. Again, learning flows in one direction. It’s applied to a relevant problem but tactical and limited.
• Sharing: Learning flows in two directions but is not applied and adapted into new learning. We simply express our own experiences with each other.
• Joint work: True collaboration in the form of teaming, planning, observation, action research, sustained peer coaching, mentoring, etc. A relationship that induces a sense of mutual obligation, exposes each participant’s thoughts and behavior to the scrutiny and evaluation of the other participant, and promotes an interdependence that previously was not part of the relationship.

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.

Posted: December 20th, 2007 under scrum.
Comments: none