That is, while there is value in the items on the right, we value the items on the left more.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
We all felt privileged to work with a group of people who held a set of compatible values, a set of values based on trust and respect for each other and promoting organizational models based on people, collaboration, and building the types of organizational communities in which we would want to work.
The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as "hackers" are ignorant of both the methodologies and the original definition of the term hacker.
When you need to change to regain simplicity, you must find a way from where you are to where you want to be. When finding the answer to the question: “What is the simplest thing that could possible work?” Critics seem to miss the second half of the question, that is: We are not asking you to think about what is too simple to work, just to bias your thinking toward elimination wasted complexity.
No fixed directions remains valid for long; Whether we are talking about the details of software development, the requirements of the system, or the architecture of the system. Directions set in advance of experience have an especially short half-life. Change is inevitable, but change creates the need for feedback.
Somebody has to pay for all this. Software development that doesn’t acknowledge economic risks the hollow victory of a “technical success”. Make sure what you are doing has business value, meets business goals, and serves business needs. For example, solving the highest priority business need first maximizes the value of the project.
In software development, “perfect” is a verb, not an adjective. There is no perfect process. There is no perfect design. There is no prefect requirements. You can, however, continuously strive for a perfect process, design, and requirements.
Excellence in software development is achieved through improvements. The cycle is to do the best you can today, striving for awareness and understanding necessary to do better tomorrow.
Isn’t failure waste? No, not if it imparts knowledge. Knowledge is valuable and sometimes hard to come by. Failure may not be avoidable waste. If you knew the best way to implement the requirement you’d just implement it that way. Given that you don’t already know the best way, what’s the cheapest way to find out?
This is not intended to excuse failure when you really knew better. When you don’t know what to do though, risking failure can be the shortest, surest road to success.
Invest in the design of the system every day. Strive to make the design of the system an excellent fit for the needs of the system that day. When your understanding of the best possible design leaps forward, work gradually but persistently to bring the design back into alignment with your understanding. The automated tests, the continual practice of improving the design, and the explicit social process all contribute to keep the cost of changes low. But without daily attention to design, the cost of changes skyrocket. The result is poorly designed, brittle, hard-to-change systems.
The question is not whether or not to design, the question is when to design. Incremental design suggest that the most effective time to design is in the light of experience.