Scott Ambler gave the keynote at Agile Tour Toronto this past Fall. As a conference organizer I only caught part of it, but still there were some useful perspectives that I wanted to share. Scott’s presentation is here.

Scaling Factors are about the kinds of things that make software projects more difficult (whether using Agile or not). Each of these factors require additional considerations that are outside of basic Agile practice. I find this a nice way of thinking about project complexity since this directly maps to the challenge with adopting Agile.

There are no repeatable projects.

There are no repeatable projects. I thought that was worth repeating since a lot of organizations still don’t understand that each project has a distinct signature and may require a different approach: Standardization is a good recipe for failure. Reading between the lines this seems to be a shot at PMO’s that are mandated to standardize software delivery.

Mike Cohn placed a challenge on his blog for people to describe a Waterfallacy – “A waterfallacy is a mistaken belief about agile that has been caused by prolonged exposure to the waterfall process.”  This is to promote his new book – Succeeding with Agile.  I have found it very useful in my Agile work and would like you to consider ordering it now to succeed with Agile

I have run up against this waterfallacy many times. Here are some of the things I have heard:

• “Agile is all about coding, not about documenting.”
• “The Agile manifesto says documentation is not important.”
• “How can you deliver software without a requirements document?”

The assertion is that there is little or no documentation in Agile and the implication is that Agile cannot possibly work.

How to overcome these statements?  I talk about 4 things:

1. Agile manifesto – what it actually says
2. Why Agile values face to face communication
3. How Agile documentation works and how Agile teams document a lot
4. If you are using Scrum, it’s up to the organization to define what is right.

Agile Values: Working software over comprehensive documentation

In the Agile Manifesto we talk about valuing working software over comprehensive documentation. So, working software comes first since that is what will make our businesses succeed. The manifesto does not say to avoid documentation entirely – that’s a mis-read!

Agile Principle: Use face to face communication

One of the key Agile Principles is:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

This signals that people should talk to each other rather than communicating through documents.  Does it say not to document?  No!

Agile Documentation – just the right amount

Agile teams tend to use wikis as a lightweight and searchable knowledge base. They document things that they think are important or useful. It may be text, photos, diagrams. For more info on how to make this work, check out this article on Agile Modeling.

Most of the Agile teams I work with produce a lot more useful documentation than more traditional teams I have worked on.

Scrum lets the organization decide how much to document

If you use Scrum, let me remind you that Scrum is completely silent on documentation. It’s up to the organization to decide how much and what types of documentation need to be completed every Sprint.

Usually people are convinced at this point and say – “Wow!  I didn’t know that.”

Yves started the Agile Retroflection of the day project for 2010. Today’s question is “When would you choose to value process and tools over individuals and interactions?”

Strangely, I find myself in a situation where I need to place a very high value on process to provide shock therapy to a client that is in the whirlpool at the end of the waterfall.

It’s the usual software story of an over-full release with a fixed release date required by not one but two external customers. Add to this a chaotic process and broken telephone between functional groups. The interesting question posed by the client is this: “Is there anything you can do to help us?” (What would you say?)

Given the timelines and pressure, there is no way I know how to do Agile in a conventional way. So tomorrow, I am launching what Gerry Kirk and I called Guerrilla Agile – something light and tactical. To make this work, I will need to very directive in what needs to happen. The main goal of this phase is to get shippable software. A later phase is planned for a sustainable transition to Agile.

In terms of my training budget, I figure I have at most 3 hours. Here the emphasis will be on cross-functional teams and working together. So in this sense I am valuing people and interactions over process  - not the other way around. Perhaps the title of this post is backwards: maybe all the command and control around  process is just a smoke-screen so I can focus people on what’s important: teamwork.

P.S. Given all the passion and energy around Kanban and Scrum these days, I think it apropos to mention that we’ll get started with Kanban since even 1 week long sprints would be to big  a challenge in the current environment.