Agile is a framework that was designed to originally to use for software development. However, now it is used in other areas where there is a need to complete huge tasks including project management tasks. It works as an alternative to waterfall model which follows a linear approach.

Agile Design Practices

Let us learn about few Agile Designing Practices. They are shown in the below level as a hierarchy from high level programming practices to Low level Practices. Each of these designs would be important in order to do an effective agile designing.

Agile Design Philosophies

• Agile designs are keep evolving. They are not defined so prior. Your overall system design will evolve over time, growing to fulfill new requirements and take advantage of new technologies as appropriate. Although you would often do some initial architectural modeling at the very beginning of a project during "iteration 0" this would be enough to progress your team. Agilists don't need to get a fully documented set of models in place before you may begin coding (although sometimes, just sometimes, you may need to perform look-ahead modeling).
• Unit tests form much of your detailed design documentation. By using test-driven development (TDD) approach to development you would write a test and then you would write just enough domain code to fulfill that test. An important side effect of this approach is that your unit tests not only validate your code, they also form the majority of your design documentation in the form of executable specifications.
• Design models need to be good enough. We need not model every single detail in our models. The models need not be perfect, and they do not need to be complete.
• Multiple models. Efficient developers do realize that each type of model has its strengths and weaknesses, So, therefore they need to apply the right model(s) for the job at hand. Because software development is complex that you quickly realize that you need to know about a variety of models in order to be effective.
• Only need a subset of the models.Although there are many modeling techniques available, the fact is that any given project team will only needs a few. Different jobs, different tools. You would never need all your tools at once, but over time you would use them in a variety of ways.
• Every model would serve for different purpose. A UML class diagram would be used to depict a high-level domain model or a low-level design. Use cases would be used to model the essential purpose of a process or the detailed system usage description which would take the architectural decisions into account. Usage of the models cannot be underestimated.
• Designers should also code. Whenever a model is given to someone else to code there would be danger that the programmer would not understand the model or may even ignore the model completely in favor of their own approach. Furthermore, even when hand-offs are successful you would get to know that you would need far more details in your model than if you had simply coded it yourself. In short, separating design from programming is a risky and expensive. It would be far more effective to have generalizing specialists on your team that could both design and code.
• Prove it with code. Never assume your design works; instead, get concrete feedback by writing code to determine if it really works.
• Feedback is your friend. Feedback would help everyone to incorporate the changes that are suggested by the customer. Expect to receive feedback about your work and be prepared to accept it and act accordingly. Not only will your system be the better for it, you will likely learn something in the process.
• Document complicated things. If something is complicated, then document them. Better yet, invest the time to design it so it is simple. Remember the AM practice. Simple content must be created.
• Do not over document. Design should be documented, but it should not be over document either. Users pay for building the product but not for the documentation work. There is a fine line between under documenting and over documenting, and that can be found out only through. Be as agile as possible when it comes to documentation.
• Do not get side tracked by the data community. Evolutionary database design techniques such as agile data modeling, database refactoring, and database regression testing would be best suited.