Key Features of Agile

Looking through the Agile Manifesto and, in particular, the twelve principles, we can identify some key features that define the process and mindset. Let�s explore these at a deeper level.
� Embracing change by understanding the needs of the business: Being agile is a realization that change is inevitable; nobody gets it right the first time, business priorities change, and people get things wrong. Agility comes about by embracing change, and learning from and with the business. With this in mind agile defines the ability to adapt and be flexible, to embrace change rather than resist it or sit around and moan that the goalposts have moved. Agile teams embrace change and actively identify changes in applications that will increase business value.

� Focusing on the business value and return on investment (ROI): Agile development is a development mind shift and a refocusing of efforts and priorities. There are a number of techniques that will help you become a more agile developer. However, becoming truly agile is so much more than the sum of its parts. The tools, project methodologies, and programming methods can certainly go some way to help one become agile, but it is the ability to apply these techniques to an ever-changing business that will truly reap the rewards. Fundamentally you must understand the business domain you are working within and align your efforts, practices, and process to realize its value.

� Continuous delivery via incremental and iterative development: Being agile is all about delivering working software of value as often as possible. Success of software development is not measured in the amount of design work. Businesses measure success in working software; this should be your measure of progress as well.

� Continuous improvement by learning from and with the business: As part of the software development team, it�s our job to turn the language and processes of the business into software systems. In order to do this it is vital that we work closely with the domain experts themselves, that is, the people that will use the software. The users aren�t always domain experts. They have experience using the existing process, but do not necessarily understand why it is that way. That is where the domain experts come in. The more you as a developer understand about the business you are writing software for, the better the software will be.

� Eric Evans in his book Domain-Driven Design: Tackling Complexity in the Heart of Software (Addison-Wesley Professional, 2003) picks up on this point when he mentions the �ubiquitous language.� This is a language that is shared between the developers and the business to describe the business domain being modelled.

� Keeping the process lean by continuous reflection on process and the removal of waste: Keeping process and practices lean is all about eliminating waste. Don�t bother with lots of documentation before developing systems. Create the documentation when it is needed. You should be able to cope with a few architectural diagrams that any member of the team can reproduce on a white board. Instead of masses of requirements documentation, use story or tasks cards and write features that can act as reminders for conversations when it is time to build the feature. Lots of upfront documentation is no good to the business� there is simply no value in it. The amount of documentation that is produced in an agile project is defined as a requirement. It is not true that agile equals no documentation. Agile equals the removal of useless information. The code and the user stories with their corresponding acceptance criteria become the documentation of the project. Not a 400-page, stagnant requirements document.
? Keeping lean is also achieved with regular retrospectives on work carried out and meetings on what�s working and not working with the current processes. Continuously refining how we work and concentrating on the work at hand will contribute towards a leaner and more effective working practice.

� Strong focus on team effort that spans more than developers in order to reduce risk and find better ways of working: Agile is about working together with a strong focus on the team in an effort to improve your working practices and ultimately deliver more value for your business. Domain experts, product managers, business analysts, security and IT infrastructure stakeholders, and testers should be first-class citizens along with developers during the project. Including nondevelopers in the team helps to increase knowledge and shared ownership and decreases the �them and us� gap between developers and everyone else in more traditional methods.
? Agile development can be the proverbial silver bullet. The problem that occurs has to do with changing the people around you. That being said, an agile project methodology can be very valuable to any organization with a need to be flexible when prioritizing application development.

Source of Information : Pro Agile .NET Development with SCRUM