Live by the principles of the agile manifesto and raise the bar by using your craftsmanship!

The agile manifesto states: “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.”

When applying agility in a project and starting with the items on the left on this scale, the question is, how little processes and tools, documentation, contract negotiation and planning is needed to successfully deliver. Project approach influencers like the technical complexity, the amount of stakeholders involved or the functional complexity of the project may force teams to use some level of process, contract negotiation, documentation or planning. Different agile methods focus on influencers or try to avoid risks differently.
Several Agile methods exists… Hey! Is this not a “contradiction in terminus”, the agile manifesto states “Individuals and interactions over processes and tools”. Apparently some amount of process is required…And if one looks at the several agile methods that have seen the light, as with any process, they try to solve a specific problem or are good at handling a specific risk: the scrum method for instance has its focus on project management and requirements management … XP focuses on continuous integration and coding practices. As with most things in the world once successful they have the tendency to grow and unfortunately sometimes in wrong directions… some methods however stay on their home ground, concentrate on specific risk and can therefore be combined easily to complement each other. An often used combination for instance is Scrum for project management and requirements management, XP for the more technical aspects using pair programming, test driven development, refactoring and continuous integration. I personally favour the combination of Scrum, XP and augmented with Smart Use-Cases for requirements definition and estimation. The strange thing is: while there is quite some process involved, still we call these agile approaches, how come? The answer on this question you can find in the principles underlying the agile approaches:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity--the art of maximizing the amount of work not done--is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Following these principles is what makes your team become agile, it is not in applying a specific method or technique. Writing Scrum Storyboards or creating XP-Unit Tests don’t make your approach agile, and while some techniques don’t work together well with an agile approach, many can be adjusted to do so: Writing a full functional design won’t contribute to the agility of your approach, but using functional decomposition to break down functionality in more manageable blocks may. Also detailing a 12 page Use-Case to describe functionality will not contribute, but describing functionality in the form of a dialog between the user and the system makes a good format to investigate the users interaction with the system.
So my advice: Live by the principles of the agile manifesto, but raise the bar applying your craftsmanship!
http://manifesto.softwarecraftsmanship.org/