On today's walk, I listened to an interview with Alistair Cockburn, whose concepts of Agile Development, designed for creating software, are perfectly applicable to Instructional Design.

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Development is a cooperative game

"Software development is a series of resource-limited, goal-directed cooperative games of invention and communication. The primary goal of each game is the production and deployment of a software system; the residue of the game is a set of markers to assist the players of the next game. People use markers and props to remind, inspire and inform each other in getting to the next move in the game. The next game is an alteration of the system or the creation of a neighboring system. Each game therefore has as a secondary goal to create an advantageous position for the next game. Since each game is resource-limited, the primary and secondary goals compete for resources.

The software development game is played in a milieu of many other games, personal and organizational, simultaneous and criss-crossing in time and purpose. One of the other games being played is to be able to play the next round of this game, i.e. the next game. That is, having once deployed a software system, to set up for changing, replacing, augmenting or complementing it.

Therefore, there is a residue to the game: a set of markers that will inform and remind the players of the next game. The players of the next game will know a different amount from the players of this game, and so what counts as "sufficient" for the next team is different from what counted as "sufficient" for this team."

A move isn't right or wrong; it's better or worse.

People trump process (and in a small group, seven or less, the process is nearly automatic). Politics trump people. (Power corrupts....)

The archive on Cockburn's website contains a wonderful article entitled Process: the Fourth Dimension (Tricking the Iron Triangle)

Cockburn writes that the "iron triangle" of project constraints (time, resources, and scope) is missing an important component: Processes.

"The three outdated and inefficient process conventions I tend to watch and replace are

• Get the requirements right before starting design and get the design right before starting coding.
• Writing things down in detail is better than sketching them and then talking about them.
• People work better in private offices.

Replace those with:

1. Overlap activities in concurrent development. Get just enough requirements to get started on the design (where just enough varies from project to project), use early coding to get valuable feedback on the properties of the design.
2. Capture documentation mostly in quick and rough form and support the documentation with good conversation.
3. Get the people out of their offices into a shared work space."

Cockburn has a lot more where these came from. Take a look in the Agile Toolbox.