1. Share goals, work as a team to reach them:
   help the customer succeed, even in complex and changing environments, is the goal developers, consultants and customers must share.
2. Define roles, objective metrics and acceptance criteria:
   so each one knows what will be done, who must do it, when, and impediments and deviations can be early spotted and effectively dealt with
3. Accept reality is complex and unpredictable:
   Take shorter steps, verify often your results, prepare for change
4. Remember human beings have limited resources and complex feelings:
   Keep things simple, communicate, be kind and honest, grant people can express their opinions and understands and willingly accepts the goal and their responsibilities or can leave when desired

"done" is when the customer/users can install and use the application comfortably.

+ I require from the customer a product backlog of UserStories with acceptance criteria

+ I agree which UserStories will be "done" in the next 2 to 4 weeks (sprint and sprint backlog respectively)

+ After the 2 or 4 weeks of the sprint I deliver all the files needed to build and install the application and automated tests to confirm the acceptance criteria were satisfied and the application is free of defects. I show how this can be done in a demo.

I ensure the customer can continue development or maintain the application even without my help

+ using the fewer and broader known tools and programing patterns that can solve the problem

+ commenting source code and showing with automated tests how the application may be extended or modified

For most applications I suggest a combination of a scripting with a low level general purpose language, e.g. Python, Javascript, Ruby or Perl running on C or Java and extended as needed in these languages. I can consider many other options for complex cases, as explained in the Tech section.

As a coach for development teams

+ showing the principles and how they incarnate in what we do as developers

+ defining management goals as acceptance criteria for easy to compute software metrics
e.g. acceptance tests should cover 100% of the code

+ using the metrics to evaluate risks and decide next actions
e.g. should we add another tool? are some parts of the code only known to one developer? what if she leaves?

+ teaching and helping the team adopt best practices
(including figure out and give them the tools to do it in the given applications and environments)
Acceptance TDD or BDD, evolving architectures that start small and grow as needed, solving more problems with less tools and lines of code, work as a whole team ensuring backlog items are "done"

If given enough time (from two to three months) I use the same quality metrics and acceptance criteria to measure my contribution (shared goal)

(If you are looking for eXtreme Programming coach or a Scrum coach think of this as a most effective path to reach your goal, backed up by the skills and years of real-world experience we developers usually need to trust somebody)

As a consultant

+ I quickly build working prototypes and simulations to ensure all the stakeholders share the same view and can try and explain all the relevant cases and scenarios, be current or predictable.

+ I map as many needs as possible to already existing solutions, concepts and patterns and help everybody understand and speak the same language

+ I use this information to define implementation strategy, requirements and acceptance criteria

accessible - valid w3c/html4.01 - www.mauriciocap.com.ar