What's the best way to compare agile software development methodologies?

The Agile Manifesto is a set of principles designed to make software development more efficient and effective. Instead of sticking to a rigid plan, Agile encourages developers to adapt and make changes as they go along. The idea is to collaborate, adjust to new information, and deliver a functional product as quickly as possible. It's about being flexible and responsive, rather than being bogged down by too many rules or too much planning.

Agile is more a mindset than a methodology (that is common misconception, "We use agile methodology"). Grounded on 4 values, it sets a human interaction centered culture for team dynamics focused on quality, improvement and iterative delivery (reacting to change vs planning) : 1. Individuals and Interactions Over Processes and Tools 2. Working Software Over Comprehensive Documentation 3. Customer Collaboration Over Contract Negotiation 4. Responding to Change Over Following a Plan The 12 principles that follow theses values explicit the importance of continuous improvement, iteration, quality, co-construction, autonomy, co-localization, face-to-face communication, sustainable rhythm..

The most widely known framework is SCRUM. Although with the increased maturity of the team/company, SCRUM tends to be too constringent and is usually dropped in favor of other more flexible frameworks like Kanban, it is usually a good starting point as it set many artifacts and events that forces the team to: - iterate and focus on value (sprints and sprint objective) - communicate (daily stand ups) - collaboratively estimate (sprint planning and estimation) - prioritize (backlog grooming) - get feedback and collaborate with stakeholders (sprint review and demos) - continuously improve (retrospective) As the team evolves and gains Agile maturity, some rituals and artifacts might become a burden and SCRUM is usually adapted or dropped.

As long as we collectively agree on the values and goals, the most important ritual is by far the retrospective, ensuring the continuous improvement towards the goal. Peer programming will help make code more readable and qualitative, while distributing knowledge. But it might represent a perceived loss of efficiency in the short term, specially in small teams with limited resources and tight schedules... With Agile maturity and technical craftmanship, CI/CD and Test Driven Design will help reducing the iteration's length, Time To Market and integrate quality (testability) at the heart of the code itself.

The biggest challenge I have had to face is making Agile and Project mindset coexist. And that is particularly true when facing investors or making business plans. Traditional project management will fix the scope (ex: "I will deliver X,Y,Z") and the time frame (ex: "in 1 year"). To be able to do that, we will adjust the budget/resources (ex: "for that I will need 10 people"). Agile will usually fix the resources (the squad team), fix the time frame (ex: "2 weeks sprint, and 25 sprints = 1 year"), with the scope being the adjustment variable. That means that an Agile team will deliver iteratively the most value at each time, but the final result at the given timeframe is by nature unknown. That is hard to sell to investors or CFOs...

Quoting Cynefin's model, there are 4 types of contexts: - simple: easy tasks whose solution is known from past experience - complicated: can be divided into simple taks, the solution is known from past experience locally, so it can be planned and estimated - complex: the solution is unknown, hence the importance of short trying and learning cycles, iterative local optimizations lead to global optimum - chaotic: nothing is known and testing does not necessarily provide insights Agile does make sense in complex contexts, while traditional project management is more suited in simple and complicated contexts. (Chaotic contexts are luckily rare). Innovative sectors, rapidly changing environments and new markets will benefit most from Agile.