Agile Software Development Methodology

An Agile Software Development Methodology is an agile project management methodology that is a software development methodology, where system requirements and system design solutions evolve through collaboration between self-organizing cross-functional teams.

• Context:
  • It can (typically) make use of Iteration Sprints.
  • It can (typically) make use of Agile Stories (and possible Agile epics).
  • It can make use of an Agile Model.
  • …
• Example(s):
  • XP Software Development.
  • Scrum Software Development.
  • Kanban Software Development.
  • Behavior-Driven Development (BDD).
  • …
• Counter-Example(s):
  • Waterfall-style Software Development.
  • Business Rules-based Software Development.
  • Agile Project Management.
• See: Kanban, Scheduling System, Test-Driven Software Development, Just In-Time, Timeboxing, Software Engineering, Project Management Methodology.

---

---

References

2021

• (Wikipedia, 2021) ⇒ https://en.wikipedia.org/wiki/Agile_software_development Retrieved:2021-12-3.
  • In software development, agile (sometimes written Agile) practices include requirements discovery and solutions improvement through the collaborative effort of self-organizing and cross-functional teams with their customer(s)/end user(s), adaptive planning, evolutionary development, early delivery, continual improvement, and flexible responses to changes in requirements, capacity, and understanding of the problems to be solved. Popularized in the 2001 Manifesto for Agile Software Development, these values and principles were derived from and underpin a broad range of software development frameworks, including Scrum and Kanban. While there is much anecdotal evidence that adopting agile practices and values improves the effectiveness of software professionals, teams and organizations, the empirical evidence is mixed and hard to find.

2016

• (HBR, 2016) ⇒ https://hbr.org/2016/05/embracing-agile
  • QUOTE:

The Right Conditions for Agile
Source Bain & Company
From “Embracing Agile,” May 2016

CONDITIONS	FAVORABLE	UNFAVORABLE
Market Environment	Customer preferences and solution options change frequently.	Market conditions are stable and predictable.
Customer Involvement	Close collaboration and rapid feedback are feasible. Customers know better what they want as the process progresses.	Requirements are clear at the outset and will remain stable. Customers are unavailable for constant collaboration.
Innovation Type	Problems are complex, solutions are unknown, and the scope isn’t clearly defined. Product specifications may change. Creative breakthroughs and time to market are important. Cross-functional collaboration is vital.	Similar work has been done before, and innovators believe the solutions are clear. Detailed specifications and work plans can be forecast with confidence and should be adhered to. Problems can be solved sequentially in functional silos.
Modularity of Work	Incremental developments have value, and customers can use them. Work can be broken into parts and conducted in rapid, iterative cycles. Late changes are manageable.	Customers cannot start testing parts of the product until everything is complete. Late changes are expensive or impossible.
Impact of Interim Mistakes	They provide valuable learning.	They may be catastrophic.

2013

• (Gandomaniavdani et al., 2013) ⇒ Taghi J. Gandomaniavdani, Hazura Zulzalil, Abdul Azim Abdul Ghani, Abu Bakar Md Sultan, and Mina Ziaei Nafchi. (2013). “Obstacles in Moving to Agile Software Development Methods; at a Glance.” Journal of Computer Science 9, no. 5
  • ABSTRACT: It is only less than a decade that agile SD methods were introduced and got popular steadily. The defined values in these methods and their outcomes have motivated many software producers to use these methods. Since migration from traditional software development methods to agile methods is growing highly, managers of the companies should be aware of problems, hindrances and challenges they may face with during the agile transformation process. This study focused on challenges which companies may face with and it is necessary that managers think about solving them. Classifying them into four main categories; organization and management, people, process and tools are the areas that challenges have been seen in recent studies.

2012

• (Balaji & Murugaiyan, 2012) ⇒ S. Balaji, and M. Sundararajan Murugaiyan. (2012). “Waterfall Vs. V-Model Vs. Agile: A Comparative Study on SDLC.” International Journal of Information Technology and Business Management 2, no. 1
  • ABSTRACT: Organizations that are developing software solutions are faced with the difficult choice of picking the right software development life cycle (SDLC). The waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases. The V-model represents a software development process which may be considered an extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. Agile Modeling is a practice-based methodology for modelling and documentation of software-based systems. It is intended to be a collection of values, principles, and practices for modelling software that can be applied on a software development project in a more flexible manner than traditional Modelling methods. This comparative summarizes the steps an organization would have to go through in order to make the best possible choice.

2001

• (Agile Manifesto, 2001) ⇒ "Manifesto for Agile Software Development."
  • We are uncovering better ways of developing software by doing it and helping others do it.

    Through this work we have come to value:

    • Individuals and interactions over processes and tools.
    • Working software over comprehensive documentation.
    • Customer collaboration over contract negotiation.
    • Responding to change over following a plan.
  • That is, while there is value in the items on the right, we value the items on the left more.

1986

• (Takeuchi & Nonaka, 1986) ⇒ Hirotaka Takeuchi, and Ikujiro Nonaka. (1986). “The New New Product Development Game.” Harvard business review 64, no. 1
  • QUOTE: In today’s fast-paced, fiercely competitive world of commercial new product development, speed and flexibility are essential. Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done. Instead, companies in Japan and the United States are using a holistic method — as in rugby, the ball gets passed within the team as it moves as a unit up the field.

    This holistic approach has six characteristics: built in instability, self-organizing project teams, overlapping development phases, “multilearning,” subtle control, and organizational transfer of learning. …

    …

    … A project team takes on a self-organizing character as it is driven to a state of “zero information” — where prior knowledge does not apply. Ambiguity and fluctuation abound in this state. Left to stew, the process begins to create its own dynamic order. The project team begins to operate like a start-up company — it takes initiatives and risks, and develops an independent agenda. At some point, the team begins to create its own concept. A group possesses a self-organizing capability when it exhibits three conditions: autonomy, self-transcendence, and cross-fertilization. In our study of the various new product development teams, we found all three conditions.

1950

• (Ohno, 1950) ⇒ Taiichi Ohno. (1950s). Toyota Production System.

---