Agile software development

These agile-based practices, sometimes called Agile (with a capital A)[4] include requirements, discovery and solutions improvement through the collaborative effort of self-organizing and cross-functional teams with their customer(s)/end user(s).

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.The values are based on these principles:[25] Most agile development methods break product development work into small increments that minimize the amount of up-front planning and design.

Smaller increments are typically released to market, reducing the time and cost risks of engineering a product that doesn't meet user requirements.

[32] This enables face-to-face interaction, ideally in front of a whiteboard, that reduces the cycle time typically taken when questions and answers are mediated through phone, persistent chat, wiki, or email.

The importance of stakeholder satisfaction, detailed by frequent interaction and review at the end of each phase, is why the approach is often denoted as a customer-centered methodology.

[45] Barry Boehm and Richard Turner suggest that each side of the continuum has its own home ground, as follows:[46] One of the differences between agile software development methods and waterfall is the approach to quality and testing.

This follows a pattern similar to the plan-do-check-act (PDCA) cycle, as the work is planned, done, checked (in the review and retrospective), and any changes agreed are acted upon.

This provides greater flexibility throughout the development process; whereas on projects the requirements are defined and locked down from the very beginning, making it difficult to change them later.

[76] Agile software development has been widely seen as highly suited to certain types of environments, including small teams of experts working on greenfield projects,[46][77] and the challenges and limitations encountered in the adoption of agile software development methods in a large organization with legacy infrastructure are well-documented and understood.

There are many conflicting viewpoints on whether all of these are effective or indeed fit the definition of agile development, and this remains an active and ongoing area of research.

A number of key concerns are of particular importance in regulated domains:[89] Although agile software development methods can be used with any programming paradigm or language in practice, they were originally closely associated with object-oriented environments such as Smalltalk, Lisp and later Java, C#.

[95] One of the early studies reporting gains in quality, productivity, and business satisfaction by using agile software developments methods was a survey conducted by Shine Technologies from November 2002 to January 2003.

[96] A similar survey, the State of Agile, is conducted every year starting in 2006 with thousands of participants from around the software development community.

[97] Surveys have also consistently shown better results with agile product development methods compared to classical project management.

[98][99] In balance, there are reports that some feel that agile development methods are still too young to enable extensive academic research of their success.

This is in contrast to waterfall models where the process is often highly controlled and minor changes to the system require significant revision of supporting documentation.

Failure to pay attention to design can cause a team to proceed rapidly at first, but then to require significant rework as they attempt to scale up the system.

[102] In agile software development, stories (similar to use case descriptions) are typically used to define requirements and an iteration is a short period of time during which the team commits to specific goals.

Allowing a developer to quickly run tests to confirm refactoring has not modified the functionality of the application may reduce the workload and increase confidence that cleanup efforts have not introduced new defects.

Technical debt hinders planning abilities by increasing the amount of unscheduled work as production defects distract the team from further progress.

[121] Due to the focused pace and continuous nature of agile practices, there is a heightened risk of burnout among members of the delivery team.

[123] The term agile management is applied to an iterative, incremental method of managing the design and build activities of engineering, information technology and other business areas that aim to provide new product or service development in a highly flexible and interactive manner, based on the principles expressed in the Manifesto for Agile Software Development.

[124] Agile project management metrics help reduce confusion, identify weak points, and measure team's performance throughout the development cycle.

For example, as technology projects grow in complexity, end users tend to have difficulty defining the long-term requirements without being able to view progressive prototypes.

The result is a product or project that best meets current customer needs and is delivered with minimal costs, waste, and time, enabling companies to achieve bottom line gains earlier than via traditional approaches.

In a TED Talk, Bruce Feiler shared how he applied basic agile paradigms to household management and raising children.

[140] Alistair Cockburn organized a celebration of the 10th anniversary of the Manifesto for Agile Software Development in Snowbird, Utah on 12 February 2011, gathering some 30+ people who had been involved at the original meeting and since.

A list of about 20 elephants in the room ('undiscussable' agile topics/issues) were collected, including aspects: the alliances, failures and limitations of agile software development practices and context (possible causes: commercial interests, decontextualization, no obvious way to make progress based on failure, limited objective evidence, cognitive biases and reasoning fallacies), politics and culture.

But I have no doubts that it will mature further, become more open to the outside world, more reflective, and therefore, more effective.The "Manifesto" may have had a negative impact on higher education management and leadership, where it suggested to administrators that slower traditional and deliberative processes should be replaced with more "nimble" ones.

Issues like unequal results across the organization, too much change for employees' ability to handle, or a lack of guarantees at the end of the transformation are just a few examples.