I am at the first Agile Software Development Conference this week. I am excited because I am really interested in agile development and I will be presenting a paper on remote agile development, a topic of particular interest to me (more on this in a future posting).

I am hoping to record and reflect as I attend the conference, so I apologize if these postings are a bit rough.

Agile Contracts

I started the morning with Agile Contracts, a workshop held by Mary Poppendieck and Christine Moore.

Keynote

Jerry Weinberg gave the keynote. He talked about what it takes to be a good professional.

Open Space

• How to be champion agile processes for the non technician
• Can agile remote development work for legacy code?

Agile Contracts

I started the morning with Agile Contracts, a workshop held by Mary Poppendieck and Christine Moore. It was a good workshop and the following is a summary of what

Different goals for the Contract

• protect against possible opportunistic behavior of the other party
• promote mutual benefit from the project

This was best demonstrated by a prisoner dilemma simulation. (For those not familiar with the prisoner dilemma, it is a sample problem in game theory. Search the net for more info.) In our exercise, some groups defected, while others cooperated, then a repeat game resulted in all defections. The take away lesson is that the defections represent a risk mitigation strategy to protect you from the opportunistic behavior of the other party. A contract based on this principle can signify a bad start to a relationship, as both sides are anticipating the need for protection mechanisms against the other right from the onset; it stages an adversarial relationship. (A comment made several times was that if you find your team referring back to the contract, it is smell of dysfunction and potential problems.)

The alternative is to formulate a contract who mechanisms seek to promote mutual benefit. The complication, as I see made evident by the prisoner's dilemma, is that people tend to gravitate to the risk coverage strategy and anticipate lowest cost rather than maximum gain.

We then discussed various types of contracts, mechanisms for negotiating and related experiences. For more info please see the website.

Keynote

Jerry Weinberg gave the keynote. He talked about what it takes to be a good professional. He remarked that most people look at the "self" perspective, but ignore the "context" perspective and "others" perspective.

Context

Observation

Jerry remarked how it is hard to for managers to observe how people are being effective in an agile process and this can make them uncomfortable. He noted an anecdote where a manager expressed that in an agile environment, with elements like pair programming, the lack of code ownership makes it hard to know who to blame. Jerry's response was a seemingly rhetorical question: Which would you rather have, a process that works but you don't know who to give the credit to or one that doesn't work but you know who to blame? The manager responded that he would prefer the one that doesn't work, but he knew who to blame. (The manager, who had so many failed software experiences, expected more failure and therefore wanted accountability.)

Service

We generally don't get paid to develop software for ourselves, but rather software that someone else will use. We are providing a service.

Self

Work Habits

Reflect on your work habits.

Learning

Try to make sure you learn something new everyday. Always try to improve.

Self Care

Make sure to get rest and play.

Attitude

Are your fearless? Committed? What is your attitude toward your work?

Others

Communication

Obviously (hopefully), real important.

Credit

Share the credit.

Open Space

How to be champion agile processes for the non technician

There was a lot of ideas, but the discussion seemed to center on a couple of key points:

• it helps (is necessary) to have experienced members (coaches, consultants) in a transition to agile development.

Can agile remote development work for legacy code?

There was a lot of experience stories and discussion. A few of the basic ideas were:

• pure virtual development, where there has never been face to face interaction at some point, doesn't work
• multiple forms of remote development
  • core is co-located, few remote developers
  • multiple, distinct distributed teams that each are co-located
  • complete distributed development where all members are remote

The convener of the discussion described his current context, which has four separate offices (the result of mergers and acquisitions), with some coupling and dependencies between offices, lots of legacy code and distributed management: project management in one place, senior technical executives in another.

My opinion is that he has three separate problems, with possibly related solutions:

• how do we introduce agile development into this organization
• how do we deal with legacy code
• how do handle remote development

My opinion is that the real problems lie with the organization, whether or not its ready for agile development and the legacy code. These issues would be a problem if all the teams were located in the same building. This is part of a bigger idea that I tend to rant on: that a remote configuration can be implemented rather easily; the real problems are independent of the remote configuration and are related to the normal dysfunctions groups face. I will talk more about this in a later posting, as it is part of my experience report on Saturday that I am presenting.