The Agile Manifesto is a set of rules defined by 17 experts to improve the development quality.

The 4 values :

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

More information about Agile : Agile on Wikipedia.org



Simple Agile Methodology (SAM Programming) is an Agile methodology inspired by Scrum and Extreme programing but with a simpler and more flexible implementation, here are the principles.


Responding to Change

A principle in S.A.M. is the dual recognition that customers will change their minds about what they want or need and that there will be unpredictable challenges - for which a predictive or planned approach is not suited.
As such, S.A.M. adopts an evidence-based empirical approach - accepting that the problem cannot be fully understood or defined up front, and instead focusing on how to maximize the team's ability to deliver quickly, to respond to emerging requirements, and to adapt to evolving technologies and changes in market conditions.


Simplicity

Programmers should take a "simple is best" approach to software design. A simple application will be easier to evolve. Always ask yourself: will my code be easily understood by another person?


Continuous Tasks prioritization

Manage all tasks and bugs in one place and organize continuously the priority according to customer needs and technical dependencies.
If your project has too many tasks/issues (more than 20 per dev in project) stop delivery and clean the urgent tasks.


Self assignation tasks

Each developer is free to choose the tasks they want to do. This allows each developer to maintain a global vision of the project and to choose tasks for which he/she will be most effective to work on.


Communication and respect

Use frequent verbal communication, favor a constructive approach to talk about a problem: "Your code could be faster with this logic" rather than "Your code is bad and slow".


Collective code ownership

Collective code ownership (also known as "team code ownership" and "shared code") means that everyone is responsible for the entire code; therefore, everybody is allowed to change any part of the code.


Coding standard

As all developers are involved in the entire code, it is essential to establish and respect naming standards for variables, methods, objects, classes, files, etc.


Continuous integration

Frequently integrate one's new or changed code with the existing code repository.


Continuous delivery

Deliveries should be as frequent as possible, allowing the customer to see the evolution of the product and modify some aspects if necessary.





In Simple Agile Methodology the project manager does not exist directly instead there is a shared role between the technical lead and the Customer Relationship Lead (Tech Lead + C.R.L.)

Tech Lead: The Tech Lead works with the CRL to define the task prioritization. He/she develops the sensitive code parts, maintains the coherence of the project's architecture, and facilitates dialogue in the dev team.

C.R.L. (Customer Relationship Lead): The CRL works with the Tech Lead to define the task prioritization. He communicates with the client and organizes the tests.




1 - Define coding standard and project organization, these rules should not be too strict but should just make it easier to understand the code between developers.

2 - Create an initial task list with the main features, do not add too much detail, just focus on the feature. Ex: as a first step for a registration feature, focus only on the mandatory fields. Return later to add enhancements.

3 - Define the priorities, this is an important step, as there are continuous tests and customer feedback, it’s important to redefine the priorities, here is our suggestion:

Emergency : Stop everything and do this task immediately
Urgent : To be done in priority and must absolutely be included in the next release to the customer
High : To do and include for the next release to the customer
Normal : To do during the project cycle
Low : To do when there is nothing left to do

4 - Once the tasks are prioritized, each developer selects the tasks to assign to themselves.

5 - When a task is completed it’s tested by another team that closes or reopens it.

6 - A release is sent to the client as often as possible.

7 - Get feedback from the customer to create new tasks or bugs and go back to step 3.