More than XP. More than one day.

Abstract
A good domain model defines terms and concepts that make sense to both the business and developer, allowing them to communicate. Eric Evans claims that "with a conscious effort by the team, the domain model can provide the backbone for [a ubiquitous] language". Meanwhile the open source Naked Objects framework automatically renders the domain model objects directly in a generic UI (rich client, web and others). In this session we’ll explore how Naked Objects’ ability to animate the domain model allows the ubiquitous language to be developed rapidly, and without any particularly conscious effort on behalf of the team members.

An initial 40 minute presentation will highlight the principal drivers behind the need for businesses to reconfigure ever faster to meet changing market demand. On the supply side this will include a brief survey of:
- how increased competition accelerates commoditisation and places increasing emphasis on the customer experience
- how customers’ switching costs and are reducing
- how this impacts the product lifecycle and producer margins

On the demand side it will review the causes of ever increasing market clock rate and rapidly changing customer expectation, including:

The yellow brick road is the difficult path Dorothy takes towards the Emerald City to find the mysterious Wizard of Oz to help her get home. In this session, we will help you to tap into the resources you’ve always had but never realised to complete your quest for a more Agile organisation. Here’s a chance to swap your bit part for a major role in the Agile re-telling of ‘The Wizard of Oz’ for your organisation.

Starring:

• You as Dorothy
• Agile as the Emerald City
• Agile adoption path as the Yellow Brick Road

Agile projects fail. All the semantic manouvering around the definition of “failure” still can’t hide the fact that some Agile projects do “crash & burn”. Why does this happen, how can we recognize it, and what can we do to prevent this from happening? The more popular Agile methods become, the more we as a community will have to address, and find answers for, these problems.

This talk will present a taxonomy of Agile project failure modes and causes, and will present a forum for attendees to share their experiences, be they failure, or success.

Following on from demonstration and exploration and of the idea that TDD and non-TDD codebases seem to have different statistical properties (XPDay 06, Spa 07, Agile 07) , this session explores how to make use of that as a guide to refactoring in practice.

Teams improve their chances of success when they demonstrate agility - the ability to deliver value to customers repeatedly, maximising ROI for the business while dealing with change in a rational and empirical way.

Many organisations, despite trying to be agile, still see their projects fail. Is it because ‘Corporate Agile’ is a compromise too far? Adaptations undermining the values and principles are often made to agile methods so they fit into the corporate culture, are more acceptable to management or to make them easier for people to perform. Do these compromises degrade a team’s agility and lead to an accepted mediocrity that increases the chances of failure?

Are we “crossing the chasm” or being driven out of our own movement by parvenues – or are they the same thing? Are the pioneers of the movement burning out from having to repeat themselves so often, or is it just time for new blood? Is there anything we can, or should, do to address Cargo Cult Agile? What is Agile anyway?