Alistair Cockburn has a new book on running Agile projects. This chapter describes seven properties set up by the best teams. Crystal Clear requires the first three. Better teams use the other four properties to get farther into the safety zone. All of the properties aside from osmotic communication apply to projects of all sizes.

The Seven Properties

- Frequent delivery/integration using time-boxed iterations

- Reflect and improve, criticise and fix

- Osmotic (passive) knowledge acquisition and communication through office organisation and open channels

- Personal Safety, safe to be honest, confidence to court criticism

- Stay focused, clear tasks, priorities on work, limit the workload

- Access to expert users, fast, quality feedback

- The usual agile stuff: automated testing, CM, continuous integration

What are your properties?

Crystal Clear Applied: The Seven Properties of Running an Agile Project

Dion if you cut and paste from someone else's blog then at least have the decency to link to it.

Dion if you cut and paste from someone else's blog then at least have the decency to link to it.

http://youarenumber6.blogspot.com/

The first paragraphs may be different, obviously reflecting the author's own personal style and opinion, but the meat of the posting - the 7 points - is a straight copy.

At least there is a link now, but this one would be better:
http://youarenumber6.blogspot.com/2004/11/7-signs-of-agility.html

I particularly like point 2 - reflect and improve. Here's how the author describes this in practice:

At the end of the first iteration . . . They released twenty-three of the twenty-four client-side programmers to go back to their old jobs, hired twenty-three new people, changed the team and management structures, paid for several weeks of programmer training, and started over

OK, so "reflect and improve" means dump the entire development team and start again.

Now, I've worked on many projects where I wished we could do that but is it really "agile"?

Now, I've worked on many projects where I wished we could do that but is it really "agile"?

It is a bit like the 'Jump Program' from a well known film. If you make it then you are obviously the agile one, but more than likely you have just thrown your project off a tall building.

What I think Alistair is saying is that an agile project is not afraid to do this. With short iterations and small teams companies can just about afford to do this. My personal opinion is that first iterations should under most circumstances be treated as prototypes and thown away. If you identify a release as a prototype or a 'bubble-gum' version then you should be inviting that project to take the leap, for its own good. Just threatening to do what the 'Ingrid' project did should be enough to prompt active reflection and improvement in the team; and it is that activity that is a property of the agile project.

If you are thinking of starting again, here is some advice:
Time the hit so it does not show up on the company results and learn to play golf.

Viewing a project from a property perspective was an interesting tweak. Usually folks are talking about process methodologies but here we have 7 properties that should be present in every successful project. I think that some of them rely on culture rather than process. If an organization is used to work in a certain way, it will continue to do so despite any specific process. My experience is that you must work on both process improvements and change the culture in the organization to succeed. The ones I think has to do with culture are Reflect and improve, Osmotic knowledge acquisition and Personal safety.

Best regards,

Erik Kayser

You forgot property #8: Act like you're part of a cult (because you are) and be pretentious about it.