Agile methodology: Few Key Points

Following are the some key features of agile development:

·         Collective code ownership and freedom to change.

·         Incremental approach (e.g. user stories are incrementally implemented)

·         Automation (e.g. TDD -- Test Driven Development).

·    Customer focused (for e.g.  internal and external users and business analysts are your immediate customers)

·       Design must be simple. Designing is an ongoing activity with constant re-factoring to achieve the rules of code simplicity like no duplication, verified by automated tests, separation of responsibilities, and minimum number of classes, methods, and lines.  

In Agile development practice,

·         You have daily stand-up meetings.

Each day, at same time and same place (in front of the task board) the team meets to bring everyone up-to date. This meeting addresses SCRUM's three questions listed below

1.    What have you completed since the last meeting?

2.    What do you plan to complete by the next meeting?

3.    What is getting in your way?

·         You use CRC (Class Responsibilities and Collaborators) cards.

CRC stands for Class, Responsibilities, and Collaborators. It is used for rapidly sketching an Object Oriented design and playing out the roles and responsibilities to validate the design. The role play dialog will be something like 

A trader class is responsible for placing and cancelling buy and sell orders on behalf of customers. Before placing a trade, trader class must know the trader details like number, name and address etc. It needs to collaborate with order to fill in the relevant order details.

·         You use timeboxed task boards.

A timebox is a previously agreed period for a particular task to be completed by an individual or team. The key aspect of the timebox approach is that stopping of work when the time limit is reached and evaluating what was accomplished instead of allowing the work to continue until the goal is reached, and evaluating the time taken.

·         Every member of a team is owner i.e. Collective Ownership.

Collective ownership, as the name suggests, every team member is not only allowed to change other team member's code, but in fact has a responsibility to make changes to any code artifact as necessary. This means every developer will review code written by others when integrating others' changes from the code repository into their code to familiarize themselves and to identify any potential issues and mistakes.

·         Continuous Integration, regular code reviews, pair programming, automated builds,

Every developer will be motivated to check in the code progressively and incrementally with proper automated unit and integration test cases as part of the continuous code integration. Every developer will review code written by his/her team-mates and is allowed to change other member’s code. This approach is very useful when one team member is absent due to any reason (such as sickness), other team members could continue the task without suffering the project.

·         BDD (Behavior Driven Development), TDD (Test Driven Development), ATDD (Acceptance                  Test Driven Development) continuous deployment and delivery, etc.

Behaviour-Driven Development (BDD) is an evolution in the thinking behind Test Driven Development (TDD -- Writing tests before writing code) and Acceptance Test Driven Development (ATDD -- write acceptance tests, and for many agile teams, acceptance tests are the main form of functional specification and the formal expression of the business requirements). The BDD basically combines TDD and Domain Driven Design. It aims to provide common vocabulary that can be used between business and technology. 

The acceptance tests are generally written using the "Given-When-Then" approach. For a given story/context, when some action is carried out,  then a set of observable consequences should be obtained. For example, Given that you have enough available cash, when you place a trade within your available cash, then placing of  your trades should succeed without any errors.  

·         Iteration planning meetings and carry out iterative development. 

The purpose of the iteration planning meeting is for the team to commit to the completion of a set of the highest-ranked product backlog items (a list of all the work yet to be done). This commitment defines the iteration backlog (a list of work planning to do in the current iteration) and is based on the team's velocity or capacity and the length of the iteration timebox. Iteration planning is a collaborative effort involving these roles:

1. Scrum Master: Facilitates the meeting
2. Product Owner: Represents the detail of the product backlog items and their acceptance criteria
3. Delivery team: Define the tasks and effort necessary to fulfill the commitment

The capacity for the team is derived from three simple measures for each team member:

1. Number of ideal hours in the work day
2. Days in the iteration that the person will be available
3. Percentage of time the person will dedicate to this team

For example, let's look at a team of five individuals, all committed to the team full-time. Each has about six ideal hours per day to work on tasks, and no one is taking vacation. For a week-long iteration:

5 team members X 6 ideal hours X 5 working days = 150 hours of task capacity