The following are the Principles outlined by the Agile Manifesto in 2001. At the time, they were landmark practices. Today, many of them have become so commonplace that it's hard to believe that it was necessary to state them in the Manifesto at that time.
"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
Delivering quality software quickly will lead to high customer satisfaction.
"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."
We need to be able to change to meet the latest market demands. This doesn't mean that change comes without cost. But you always have to evaluate if the solution you are delivering meets the current needs of the market, and if it's worth the cost and effort to change the solution or even abandon it altogether.
"Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale."
Some organizations deliver many times per day now. The wording in this principle may be outdated, but the concept is sound. Deliver frequently in order to get feedback on the product being created and get value to market quickly.
"Business people and developers must work together daily throughout the project."
Seems like common sense that we have to work together, but in 2001 this was not always the case. Business people would write a requirements document, throw it over the wall to the development team, and come back in six months to a year to see if they liked was created. Now, we have business people involved daily in software development team activities and giving feedback on it.
"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
This is the opposite of micromanagement. Hire good people, train them well, give them an environment in which to be successful, and let them do their jobs. Engineers generally want to create great solutions; trust them to do so.
"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
This does not mean that every team needs to be collocated. It does mean that you should have your camera on when meeting online. Always make sure that all participants in a meeting can be seen. Body language, facial expressions, and other nonverbal behavior give away important cues to effective communication. Use the tools we have available today in order to achieve this principle even when working remotely.
"Working software is the primary measure of progress."
That is, we need requirements, design, and user documentation, but these are less important than creating working software. Refactoring is a good way to iteratively create very good solutions. The goal is always to release software that people can use and do all of the other work around it as support, not the other way around.
"Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."
Don't overwork people indefinitely. Anyone in software knows that sometimes extra effort is needed in order to get a release to market. But working overtime should be the exception, not the rule.
"Continuous attention to technical excellence and good design enhances agility."
If we use the latest technology and methods, we will create software that allows us to respond to customer needs the best. The methods of creating software are constantly being improved. Therefore, we will be able to respond to customer needs best by using the latest technology coupled with good design.
"Simplicity--the art of maximizing the amount of work not done--is essential."
If we can avoid developing solutions that will never be used, we can focus ones that will. A large percentage of all software created is never used. Use pre-development techniques to determine if a particular feature or component will be popular prior to creating it. Prototyping and other market research tools can be employed in this effort.
"The best architectures, requirements, and designs emerge from self-organizing teams."
Self-organizing teams give managers time to focus on strategy and other high-value activities, rather than creating gantt charts and tracking team progress. Using today's tools and techniques, self-organizing teams can show their progress without much extra effort. We will discuss some of these techniques in future sections.
"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
Hold retrospectives or post-mortems regularly. This is the single best way for an organization to improve. Each person should answer: what went well, what didn't go well, and what should we do differently moving forward. This leads to a continuously self-improving organization. Regular retrospectives are the key.