Monday, April 2, 2007

Agile Publishing

I've been invited to speak at George Washington University on the subject of Agile Publishing. This is a new application of Agile programming principles applied to content rather than to code. So I'm starting to explore the relationship and applicability.

The basic tenets of Agile Software Development (taken from are:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
And Agile at work in software development usually means following these principles (
  • Customer satisfaction by rapid, continuous delivery of useful software
  • Working software is delivered frequently (weeks rather than months)
  • Working software is the principal measure of progress
  • Even late changes in requirements are welcomed
  • Close, daily, cooperation between business people and developers
  • Face-to-face conversation is the best form of communication
  • Projects are built around motivated individuals, who should be trusted
  • Continuous attention to technical excellence and good design
  • Simplicity
  • Self-organizing teams
  • Regular adaptation to changing circumstances
So, how does this apply to publishing? Well, there are both philosophical and practical answers. Michael Fitzgerald published an article on XML.COM on this at In it, he examines the basic tenets of Agile in a publishing context and makes some specific suggestions on how to become agile. I'd like to extend his work. In the next several blog entries, I'll take a look at each of the principles in a publishing context. But first, let's look at what makes for a successful Agile project:
  • The culture of the organization must be supportive of negotiation
  • People must be trusted
  • Fewer but more competent people are needed
  • Organizations must live with the decisions developers make
  • Organizations need to have an environment that facilitates rapid communication between team members
I believe this holds true for an Agile publishing effort as much as for an Agile software development effort. These key elements center around trust and communication. Find good people, empower them to success, trust them to get there and communicate regularly. It may mean compromising certain aspects of traditional publishing, such as corporate style oversight, high-overhead decision-making, and trusting decisions to workers.


Anonymous said...

The tenet that "organizations must be willing to accept decisions that developers make" seems risky for a successful project in the eys of the end-user stakeholders. Perhaps it can be mitigated by making sure that development team members include, where possible, individuals with significant end-user requirement awareness.

Steve Carton said...

It could be seen that way, but a tenet of an Agile team is that it includes a client stakeholder. This is partly to ensure that the needs of the client are being met.