We believe in the following principles:

1. Agile success is delivered by combining superior productivity enabled by innovation and measurable risk taking, with informed validation of the outcome by the stakeholders. 
2. The role of culture change through Agile vocabulary and rituals like stand-up meetings, pig’s ears worn by Scrum “pigs”, specific names, specific templates etc, is overrated.
3. The real culture change comes from the necessity to frequently demonstrate progress to the Stakeholders in a way that allows them to validate it.
4. No quality of the final product comes from the fact the team is using something called Agile. Every feature associated with Agile, like business agility, supportability, reuse of functionality by other systems etc., is merely a promise to be fulfilled. 
5. For every promise an Agile project has given, there should be validation of progress towards delivering on that promise at the end of each Iteration. That means that there should be a Stakeholder for for every promise. While some Stakeholders can preside over several promises, such allocation should be explicit.  
6. Validation requires the Stakeholder’s ability to assess the progress and the outcomes of the decisions made. Therefore, the progress towards the specific goals and promises must be made visible, even if that requires additional effort. The scaffolding tasks like establishing of development environment etc that no Stakeholder asked for cannot be deliverables.   
7. It is humanly impossible to work on the basis of tacit knowledge and informed guesses for 2-3 weeks, without doing anything wrong. An agile project that hasn’t received any correction from any of the Stakeholders for one iteration most likely does not practice adequate validation by Stakeholders. A project that received no constructive criticism for two Iteration is definitely keeping the Stakeholders in the dark. 
8. Agile requirements specifications - User Stories and other, higher levels statements - are not contract clauses, but the statements of initial understanding of the problem at hand. They have to be validated through work and delivery. The only “specification” that matters is the solution delivered to the Stakeholders’ satisfaction. 
9. The specifications in traditional sense, those that provide adequate representation of the solution, can only be produced as a result of development rather than in advance.

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.